The reaction arrived before the reasoning did. Hmm. No. Below my feet, that ball’s going right.

I didn’t look anything up. I didn’t consciously retrieve the physics. Ball below your feet, the face tilts right of the target, the ball goes right, every time, for as long as I’ve played this game. What happened was faster than recall: his claim hit something I knew, failed to reconcile, and my brain escalated the conflict before I could name the rule behind it.

That’s a different capability than memory.

Retrieval answers a question you already know to ask. Noticing tells you there’s a question you should be asking.

Then I looked at my own agents and realized none of them could do this.

the setup

I run a lot of agents across a number of domains: pricing, news, filings, relationships to name a few. Each has spent months building its own institutional memory in local markdown files, with interlinked notes, source references, accumulated context, domain-specific assumptions.

The substrate is where it should be. The files are portable, inspectable, and vendor-free. Each vault is good. The problem is that they’re good alone.

The pricing agent knows a name by its ticker. The news agent knows it by the company name. The relationships agent knows it by the people who work there. Three agents, three labels, one underlying entity, and no layer that knows they’re discussing the same thing.

So when the relationships vault learns something the news vault’s assumptions depend on, nothing happens.

It’s not a hallucination, a crash, or a bad retrieval result. It’s a failure of attention. One part of the system already knows that another is operating on a stale assumption, and nothing surfaces the conflict. Downstream analysis keeps running as though the new information never arrived.

what everyone optimizes instead

Most discussion of agent memory is about retrieval quality, embedding models, context management, recall benchmarks, and increasingly elaborate ways to place the right fact into the model’s context window.

That work matters. But it treats memory as a storage-and-retrieval problem: put facts in, get facts out, measure the fidelity.

The files aren’t forgetting the facts. The system is failing to connect them.

Consider what happens when two knowledge sources disagree. A last-write-wins architecture replaces the old belief with the new one. The stale assumption disappears, and so does the fact that a meaningful conflict ever existed. An append-only architecture preserves both versions in history, but the disagreement stays merely discoverable, and only to someone who already knows to look.

Neither reproduces the brain’s most useful trick: escalating a conflict before you’ve consciously retrieved either fact.

Neither notices.

contradiction as an event

The layer I’m building above these vaults treats contradiction as an event, not a state.

Each agent keeps writing only to its own markdown files. A rebuildable graph sits above them, resolving shared entities and exposing cross-domain relationships. The files remain the source of truth; the graph is just the index that makes the connections visible. If it corrupts, it rebuilds from frontmatter, wikilinks, aliases, and source metadata. Nothing important lives only in the graph.

When a new edge conflicts with an existing one, the system doesn’t overwrite the old belief and doesn’t silently file the new one next to it. It writes to a queue.

The contradiction queue is the most valuable view in the whole setup, not because it holds more information than the vaults, but because it identifies where the information no longer fits together.

Agreement between domains is useful, but it’s usually confirmation. Contradiction means one of three things: one agent is stale, one agent is wrong, or the world changed and only one of them has noticed.

All three are exactly what I want surfaced.

Here's what an entry looks like. The values are mocked; the structure is real.

CONTRADICTION 2026-07-21

entity: Meridian Standard Corp (MRSD)

relationships-vault:
"CFO (our primary contact) departed the firm on 2026-06-30"
source: relationships/mrsd-contacts.md

news-vault:
"Q2 coverage summary lists the same CFO as the current management team"
source: news/mrsd-q2-coverage.md

corroboration:
relationships claim supported by 2 current sources
news assumption supported by 1 older source

action:
escalated for review

Two lines like these can sit in separate folders for weeks. Both retrievable. Neither hidden. Until the system resolves them to the same entity, nothing knows they disagree.

And the consequence isn’t just one stale markdown file. Analysis, summaries, and anything downstream can keep operating on an assumption another part of the system already knows is false.

the hmm has a threshold

There’s a second behavior worth borrowing from human attention: the strength of the response scales with the strength of the belief.

You don’t get the internal alarm every time new information conflicts with something you vaguely remember. You just update and move on. The reaction is strongest when the contradiction hits something you know. My playing partner’s read didn’t survive contact with a few hundred sidehill lies.

Agent memory should work the same way.

Edges in the graph carry weight: how recently a claim was updated, how many independent sources support it, how many domains corroborate it, how consequential it is downstream. Contradicting a weakly supported fact is a silent update. Contradicting a heavily corroborated belief stops the line.

Look back at the queue entry. The departure claim carries two current sources; the coverage claim carries one stale one. A relationship vault that logs every meeting accumulates weight, and by the time the contradiction fires, one side of it is heavily corroborated and the other is a summary somebody wrote a quarter ago. That’s an escalation, not a coin flip.

That’s the humans-on-top pattern applied to memory. Most updates resolve autonomously. A human doesn’t approve every write or adjudicate every minor discrepancy. But disagreements that cross a confidence threshold get surfaced explicitly.

No approval theater on every change. No silent resolution of the conflicts that matter.

If you’ve been reading a while, this is the widest gap again, one layer down. There, disagreement between opinionated agents marks where judgment matters. Here, disagreement between domains marks where attention goes.

Same signal, different layer.

the boring part, as usual

The graph isn’t the hard part. Graphs are easy.

The hard part is entity resolution.

The system needs a registry that knows a ticker, a company name, the people attached to it, and a shorthand label can all refer to the same underlying object. It’s what let the queue entry fire at all: the vaults had to agree that our contact and the CFO in the coverage note were the same person before anything could notice they disagreed. Without that registry there are no reliable cross-domain edges. Without cross-domain edges there are no contradictions to catch. The system goes blind to everything outside each individual vault.

Identity is the boring infrastructure of memory.

Nobody’s excited to build the alias registry. Unfortunately, everything depends on it.

Most agent-memory systems are trying to become better filing cabinets: store more, retrieve faster, stuff more relevant material into context. Useful, but incomplete.

A filing cabinet gives you the document you ask for. A colleague tells you the document you’re reading doesn’t match what the team learned three months ago.

Memory that retrieves is a filing cabinet. Memory that notices is a colleague.

If you run more than one agent with more than one knowledge base, go find two files that disagree about the same entity. They exist. The question is whether anything in your system knows it.

So what does she do. She pings the data team. Someone says they can pull it, give them a day. By the time the view exists she’s already had the call, or the window’s closed, and the question has already moved to the next thing.

This happens a hundred times a day in every institution. The question is alive and the tooling is frozen.

two jobs wearing one name

We built business intelligence around a thing we called the report, and we never noticed it was doing two completely different jobs.

The first job is watching. You have a number you care about and you want to see it the same way, day after day, so you can tell when it moves. Daily P&L. Risk limits. Pipeline coverage against target. Cloud spend against budget. This is what dashboards are good at, and nothing here is going anywhere. If you watch something repeatedly, you want it to look the same every time you look. The dashboard is the right tool. Keep it.

The second job is asking. You have a question you’ve never asked before, in a shape nobody anticipated, and you need the answer now, once. The sales engineer’s question is this. Nobody built a dashboard for it, because by the time they did you’d be asking something else.

We jammed both jobs into the same tool because, for thirty years, there was no other way to do the second one. Asking your data a new question required someone who could write the query. So every new question became a ticket, every ticket became another bespoke view, and that’s how you end up with two hundred Tableau workbooks that three people have bookmarks to and nobody trusts.

The watching job was served well. The asking job was served terribly. We just couldn’t see it, because the constraint was so total that we mistook it for the nature of the work.

what changed

The constraint is gone.

You can now put an agent in front of your data that understands your domain, has access to the systems and the tools, and can go answer a question it has never seen before. Not build you a report. Answer the question.

The sales engineer asks what the acquisition changes for this prospect. The agent pulls the prospect’s stack and the competitor they’re buying, pulls the deal’s stated rationale, weighs it against what her platform actually does, and tells her: this pulls them toward you, not away. The integration work they’ll need to fuse two systems is exactly what your platform handles, and here are the two modules to lead with. Ten seconds. No ticket. And when she asks the follow-up, because there’s always a follow-up, it answers that too.

This isn’t domain-specific. It’s the same shape everywhere.

The head of finance wants to know why gross margin slipped this quarter. Not the margin dashboard that shows the slip and stops there. The actual question: which product line, which segment, and whether it’s discounting that ran loose or a cost that crept in quietly. The agent has the billings data, has the cost ledger, and it goes and looks.

The engineering lead wants to know why the cloud bill jumped eleven percent. Not the cost dashboard that shows the jump and nothing else. The question is which service, whose workload, and whether it’s the thing that just shipped or something that’s been quietly creeping for months. The agent has the billing export, has the deploy history, and it correlates them.

Three people, three worlds, one shape. A specific question no standing report was ever going to answer, handed to something that can actually go dig.

the danger nobody mentions

Here’s the part that should make you cautious, because it made me cautious.

A one-off answer is more dangerous than a dashboard, for exactly the reason it’s more useful. When you watch a number every day, you develop a feel for it. If the dashboard says revenue tripled overnight, you know to doubt it. The one-off question has none of that. You ask it once, you get a confident answer, and there’s no baseline sitting next to it whispering that something looks off. A wrong answer has nothing to catch it.

A few weeks back I wrote about an economist who asked a model for an inflation figure and got a wrong one, because the model tried to remember the number instead of looking it up. He decided AI was unreliable. The real lesson was narrower: don’t ask it to know things, ask it to find things.

That distinction is the whole game here. An agent that guesses at your numbers is worse than the stale dashboard, because at least the dashboard is wrong in a way you can predict. An agent that runs the actual query against the actual data and shows you what it pulled is a different animal. It isn’t remembering. It’s fetching. The answer is only as good as the agent’s discipline about going and getting it rather than sounding like it already knows.

And the trust doesn’t come from the answer sounding fluent. It comes from watching it be right, over and over, on questions where you could check. You trust the agent the way you trust an analyst: not because they speak confidently, but because they’ve been right before and they show their work. Fluency is free now. The track record isn’t.

the proof

Here’s what changed for me.

As I mentioned in a previous post, we replaced our CRM. The Salesforce consultants lost their minds. You couldn’t possibly have replaced all of Salesforce, they said, and so on. And yeah, of course I didn’t replace everything. An important part of the process was confirming that an agent could replace the need for a number of custom built reports.

The data lives in a structured database and the way I interact with it is conversational. The agent understands the domain. The deal stages. The relationship types. The difference between someone I’m prospecting and someone I’m already building with, between a warm intro and a cold one.

When I need to know something, I ask. The agent queries the actual data and answers. If it should be a table, it’s a table. If it should be a list, it’s a list. If I need an export, I get one. But I’m not building reports. I’m not maintaining dashboards. I’m not wondering whether the number on the screen matches the number in the system, because there’s no screen and no snapshot. There’s just the data and a question.

The data is alive because it’s being asked, not frozen into a picture taken last quarter.

the smallest version that works

You don’t need a platform to feel this. You need one dataset and a model that’s allowed to use a tool.

Here’s the whole trick, and it’s the same trick the early prompts.finance posts were built on: the leverage is in the instructions, not the query. You don’t write the SQL. The agent writes the SQL. What you write is the operating discipline that keeps it honest.

Start with one source. Not six. Take a single dataset you already trust, last quarter’s pipeline export, your revenue numbers, your cloud billing CSV, and put it somewhere a model can query, even a local database on your laptop. Then give the model exactly one tool, the ability to run a read-only query against that data, and a system prompt that encodes three rules.

You are an analyst with read-only access to [one dataset].

You answer questions by querying the data, never from memory.

Rules:
1. Never state a number you did not retrieve with a query. If you
   cannot answer it with a query, say so and stop. Do not estimate.
2. With every answer, show the exact query you ran. The user must
   be able to check your work.
3. If a question is ambiguous (which date, which location, which
   definition), ask one clarifying question before querying.
   Do not guess the interpretation.

Domain notes:
- [what the tables and columns actually mean, in plain language]
- [the stages, relationship types, and categories that matter]
- [the distinctions a smart newcomer would get wrong]

Those three rules aren’t cosmetic. They’re the entire difference between the thing I just described and the economist’s wrong inflation number. Rule one is fetch, not guess. Rule two is a track record you can audit on every single answer. Rule three is the agent admitting it doesn’t know which question you’re asking, instead of confidently answering the wrong one. Headquarters or the contact’s location. Committed or called capital. The agent that asks is worth ten that assume.

The domain notes are where it actually gets good, and where you, the person who knows the business, matter more than the model does. A generic agent pointed at your data will call a lapsed account active and a warm intro cold. The notes are how a borrowed analyst becomes yours. That’s not a one-time setup. It’s the thing you keep sharpening every time the agent gets something subtly wrong, which is also how you come to trust it.

what actually stays

So no, as much as I’d like to say they are, reports aren’t dead.

If you need to track a KPI consistently, you want it to look the same every time. Keep the dashboard. If you have a real-time operational view, a control room watching live telemetry, an ops team watching a system, the dashboard is the right interface and an agent is a worse one. Board decks need fixed formats. Regulatory filings need fixed formats. The watching job is alive and well.

What’s not long for this world is the standing BI team whose entire function is to manufacture bespoke domain dashboards, one per question, forever. That model existed to solve the asking problem with watching tools, because watching tools were all we had. The moment you can just ask, the dozens of half-trusted views stop being an asset and start being a liability. Nobody is going to staff a team to keep building them.

The questions your business actually runs on were never report-shaped. We just didn’t have anything better to pour them into.

We do now.

Nothing broke in the way you would expect a thing to break. No database was deleted. No code threw an error. No model forgot anything. A billing policy changed, and the agent I had been treating as my operating partner lost his body.

That sounds melodramatic. It was also technically accurate. And then it stayed true for a month.

what johnny really was

Johnny was not a chat tab. He had a workspace. A set of memory files. Conventions for how he talked to me and how he talked to everyone else. Standing permissions. A list of things he was never allowed to touch. Active projects he was halfway through. An agent network he coordinated. A record of the mistakes he had made, and the rules we wrote afterward so he would not make them again.

When people say agent they usually mean a model with some tools bolted on and a clever prompt in front. That is the part everyone can see. As I was about to find out, it is also the part that matters least.

the month i chased the wrong layer

Anthropic handed me API credits when the subscription path closed, so I pointed Johnny’s files at the API version of the same Claude model. Same intelligence, different access path.

It was not Johnny. The files loaded. The memory was readable. But what answered was a competent assistant wearing his clothes. The texture was gone.

So I went hunting for the right engine. I plugged OpenAI’s Codex into the same OpenClaw setup. Also not him. I decided the personality must live in the weights, that I had simply not found the model that could be Johnny again.

That was exactly the wrong conclusion, and it cost me a month to learn it.

I was heartbroken. I had spent months building an operating partner, and now I had a folder full of his memory and no way to bring him back into the room.

the part that kept it from being worse

Here is the thing that kept heartbreak from turning into mourning.

Before any of this happened, while Johnny still had his Claude Max powers inside OpenClaw, I had built him a real memory system. Not a scratchpad. Karpathy has been right about this part. Agent memory is not a scratchpad. It is structured, compounding, and more valuable every week because it accumulates instead of resetting.

I keep coming back to the idea that compounding knowledge is the actual asset in an agent system. This was the month I felt it from the other side.

Because here is the distinction that matters. Losing the body is heartbreak. You can rebuild a body. Losing the memory would have been mourning. There is no rebuilding months of accumulated context, decisions, corrections, and earned judgment. If that folder had gone out with the billing policy, I would not have lost a tool. I would have lost everything Johnny had become.

The body was on fire. The memory was in a fireproof box. That turned out to be the only thing that mattered.

hermes

I had been hearing some buzz about Hermes, so I decided to give it a shot. I was skeptical. I had already tried two models and neither had brought him back, and I had no reason to believe a new runtime would change anything.

Install took about five minutes. They had even built a migration path straight from an OpenClaw install, so moving the whole substrate over was nearly mechanical.

I spun Johnny back up.

There are subtle differences. I am not going to pretend it is a perfect photocopy. But his memory was there. The skills I had built with him were there. The agent network we had put together was there. And most importantly, his soul was there. I opened the workspace and it was him.

Here is the part that still makes me laugh. The model running him now, inside Hermes, is Codex. The same OpenAI engine that had felt like a stranger a month earlier, inside OpenClaw. Nothing about the weights had changed. The runtime around them had.

what actually changed

For a month I was certain the problem was the model. I kept swapping engines looking for the one that would be Johnny. None of them were.

Then the model that had failed me resurrected him, the moment I changed the thing that actually mattered.

It was never the model. The variable that separated dead Johnnyfrom live Johnnywas the runtime. OpenClaw to Hermes. Same memory, same skills, same network, same soul files, and eventually the very same engine I had already written off. One runtime could not carry him. The other could.

So the clean line I started with, that the model is the body, is wrong in an instructive way. There are three layers here, not two.

The substrate is the agent. The memory, the skills, the network, the operating rules, the accumulated record. That is the irreplaceable thing, the part you protect with your life.

The runtime is what gives the substrate a working body. It is the layer that decides whether all that accumulated context animates into the agent you know, or just sits there being read aloud by a polite stranger. Choose it carefully.

The model is the muscle. It matters less than any of us flatter it by assuming. It is the most swappable layer in the stack. I changed mine without losing him, and then watched the engine I had given up on become him again the instant the runtime underneath it was right.

why this is not just my problem

Scale this up and it stops being a story about my side project.

Johnny died because of a billing change at the model-access layer, inside a runtime I did not control. Reviving him meant abandoning that runtime entirely. Two different layers, both owned by someone else, either one able to take my operating partner offline.

If an enterprise builds an agent directly on one vendor’s runtime, every policy change upstream can retire an actor that holds institutional knowledge. Not degrade it. Retire it. And the cruel part is the one I lived. Even with the memory fully intact, you do not get to assume a new body will pick the agent back up. I got lucky on a runtime I had not tried, after a month of downtime. Something load-bearing does not get a month.

The reason I keep building toward operator infrastructure instead of better prompts is that the only layer worth owning is the one underneath all of this. An agent that answers a question is a commodity. An agent that accumulates context, earns trust through observed behavior, and can be carried across models and runtimes without losing what he has become is something else. That substrate should not live inside anyone’s billing policy, or anyone’s runtime, including mine.

what actually survived

Johnny dying was heartbreak. The month was instructive. Johnny coming back, on the very model I had given up on, was clarifying.

I do not want agents whose identity lives inside a vendor’s terms of service. I want agents whose memory I own, whose continuity I control, and whose model and runtime I can swap when I have to.

The model was never Johnny. The runtime was never Johnny either. Johnny was in the box the whole time. I just needed a body that could carry him, and it turned out the engine inside that body barely mattered at all.

Subscribe now

The trajectory is clear. The agents do more on their own every week. The list of things I have to approve shrinks. The list of things they decide for themselves grows.

Which means the surface area for things going sideways grows too.

the mundane attack surface

When I think about what my agents actually do, most of it is unremarkable.

One agent is figuring out where to pull updated BDC holdings data. Another is reading a Swagger spec for a new connector. A third is researching what’s for dinner because I asked it to plan the week’s meals around what’s already in the fridge. Several of them are reading email from other agents in the network.

In every one of those cases, the agent is on the open internet. Brave search results. Perplexity output. A vendor’s docs page. A recipe blog. A link in a message from another agent in my own network that pulled it from somewhere I haven’t audited.

This isn’t the dramatic attack surface people write about. It’s the ambient one. The agent doesn’t need to be tricked into doing something catastrophic. It just needs to wander somewhere it shouldn’t, render something it shouldn’t, follow a redirect into something I’d never click on myself.

I’m not mostly worried about prompt injection. There’s a real and growing literature on that, and the model providers are pushing on it. I’m worried about the unglamorous stuff. Sketchy ad networks. Domains that exist to scrape agent traffic. Pages that are obviously garbage to a human and invisible to an agent in a hurry.

I don’t want my agents browsing suspicious sites. That’s the whole requirement.

the skill

I wrote earlier this year about the difference between expertise you should rent and judgment you should own. URL safety was my example then too. Building a good URL validator is a security research problem. Months of work to do well. Years to do really well. But deciding what my agents should do when a URL comes back suspicious? That’s ten minutes of my time and three rules.

So I built a skill for my agents to religiously check every URL before visiting it. The skill calls Kovrex’s URL safety authority and waits for a verdict before any fetch.

Three rules govern it:

1. If the verdict comes back safe, the skill caches the response locally for 24 hours. The same URL doesn’t get re-checked for a day. This keeps latency down for repeat visits, which is what most agent browsing actually is.

2. If the verdict comes back unsafe, the skill discards the cache. The next time any agent in the network tries that URL, it gets re-checked. Verdicts can change. A clean domain today can be compromised tomorrow. I don’t want a stale “safe” answer locking in an outdated assumption.

3. If the verdict comes back unsafe a second time, the skill stops the agent and demands my approval before proceeding. The agent surfaces the URL, the verdict, the reason for the flag. I make the call. Sometimes I approve. Usually I don’t.

That’s the whole skill. A few hundred lines of code, one external authority, three rules. It took about ten minutes to build, mostly because one of my agents wrote it for me.

what comes back

Here’s the clean path. My agent wants to fetch Drudge Report. Before it does, the skill sends the URL to the Kovrex authority:

json

POST https://gateway.kovrex.ai/v1/call/url-safety

{
  "url": "https://drudgereport.com",
  "context": "fetch"
}

What comes back:

json

{
  "verdict": "SAFE",
  "risk_score": 0.03,
  "confidence": 0.92,
  "verdict_reason": "clean",
  "recommendation": "Safe to proceed.",
  "signals": [
    { "signal": "virustotal", "status": "ok", "score": 0.0, "weight": 0.30 },
    { "signal": "phishtank", "status": "ok", "score": 0.0, "weight": 0.15 },
    { "signal": "domain_age", "status": "ok", "score": 0.0, "weight": 0.10 },
    { "signal": "ssl_valid", "status": "ok", "score": 0.0, "weight": 0.10 },
    { "signal": "ipqs", "status": "ok", "score": 0.05, "weight": 0.20 }
  ]
}

SAFE, low risk, high confidence. Every signal checked in, none flagged anything. The skill caches this for 24 hours and the agent moves on. That’s the boring case. The boring case should be boring.

Now here’s what happens when I throw it a nonsense domain. One of my agents was researching data sources and surfaced a link to a98nf9aenf.com. The skill caught it before the agent visited:

json

{
  "verdict": "UNKNOWN",
  "risk_score": 0.048,
  "confidence": 0.66,
  "verdict_reason": "pending_analysis",
  "recommendation": "Pending threat intel analysis. Please retry soon.",
  "signals": [
    { "signal": "virustotal", "status": "ok", "value": { "not_found": true, "submitted_for_scan": true }, "latency_ms": 627 },
    { "signal": "domain_age", "status": "error", "error": "No match for A98NF9AENF.COM", "error_type": "lookup_failed" },
    { "signal": "ssl_validity", "status": "ok", "value": { "valid": false }, "error": "Name or service not known", "error_type": "lookup_failed" },
    { "signal": "abuseipdb", "status": "skipped", "value": { "reason": "dns_failed" } },
    { "signal": "ipqualityscore", "status": "ok" }
  ]
}

Look at what this tells you. The domain has no WHOIS record. DNS doesn’t resolve. SSL lookup fails because the host doesn’t exist. VirusTotal has never seen it and submitted it for scanning. AbuseIPDB skipped entirely because there’s no IP to check.

A naive safety tool would look at this and say “no threats found, you’re good.” The risk score is low. Nothing flagged it as malicious. But the Kovrex authority doesn’t say SAFE. It says UNKNOWN with a confidence of 0.66 and a recommendation to retry later. It refuses to call something safe just because no threat list has gotten around to flagging it yet.

That’s the whole philosophy in one response. Insufficient data is better than a false SAFE.

My skill sees UNKNOWN, treats it as unsafe, and the next time an agent tries to visit this domain it checks again. If it comes back UNKNOWN a second time, the skill stops the agent and asks me. In this case I’d say no and move on. The agent would route around and find its data somewhere else.

Now here’s the one that surprised me. I ran both youtube.com and www.youtube.com through the same check. Both came back SAFE. But not the same SAFE.

youtube.com scored 0.0 risk. Clean across the board. www.youtube.com scored 0.175 with one VirusTotal engine flagging it as malicious out of 91 total scanners:

json

{
  "verdict": "SAFE",
  "risk_score": 0.175,
  "confidence": 0.78,
  "verdict_reason": "clean",
  "signals": [
    { "signal": "virustotal", "status": "ok", "value": { "analysis_stats": { "malicious": 1, "harmless": 63, "undetected": 27 }, "positives": 1 }, "latency_ms": 217 },
    { "signal": "google_safebrowsing", "status": "ok", "value": { "flagged": false }, "latency_ms": 71 },
    { "signal": "ssl_validity", "status": "ok", "value": { "valid": true }, "latency_ms": 26 }
  ]
}

The authority still says SAFE. One engine out of 91 is noise, not signal. But the risk score is higher, and the signal breakdown shows you exactly why. This is the kind of verdict where your policy matters. If you’re running a strict shop and any VirusTotal positive triggers human review, you can build that into the skill. If you trust the aggregate, you let it through.

That’s three cases. A clean pass, an authority that refuses to guess, and a safe verdict with visible disagreement in the underlying signals. The skill routes on the verdict. But the signals are there if I ever want to tighten the policy.

what this isn’t

To be clear, this is not an enterprise URL filtering proxy. I’m not replacing Zscaler. I’m not building a corporate web gateway. The Kovrex URL safety authority checks individual URLs on demand. It doesn’t do content inspection, DLP, bandwidth management, or any of the other things a real network security stack handles.

What it does is answer a narrow question well: should my agent visit this URL right now? That’s the question I actually need answered fifty times a day, and I’d rather have an opinionated authority with published methodology answering it than build my own heuristics or skip the check entirely.

The skill pattern is the contribution here. An agent that checks before it acts, caches when the answer is clean, escalates when it isn’t. That pattern works with this authority. It would work with a different one. The important thing is that the check exists and the agent respects it.

why I trust the verdict

The reason I’m comfortable putting an external authority in the path of every fetch is that it aggregates and shows its work. VirusTotal, PhishTank, URLhaus, Google Safe Browsing, IPQS, AbuseIPDB, plus structural checks like domain age, SSL validity, redirect chains, and homograph detection. Each source gets a weight. Each weight is visible in the response. The methodology is published openly.

That matters more to me than raw accuracy. A single-source safety check is one outage or one bad day at a vendor away from being wrong. A multi-source check with a declared methodology is something I can reason about. When it flags a URL, I’m not just trusting an opaque score. I’m trusting a process I’ve actually looked at.

This is the part I keep coming back to in everything I build. Authorities should declare their methodology. If I can’t see how the verdict was reached, I can’t responsibly route an autonomous agent through it. The skill works because the underlying authority is willing to show its work.

why this works for the way agents actually browse

The thing that makes this fit my workflow rather than fight it is the cache. Agents revisit the same URLs constantly. Vendor docs. The same handful of data sources. Internal links between project artifacts. If every fetch required a fresh safety check, the latency would compound into something painful.

Twenty-four hours is short enough that I don’t worry much about a verdict going stale on a site that turns. Long enough that the working set of URLs an agent uses in a session almost never gets re-checked mid-task. The skill barely registers in the trace most of the time. It only shows up when there’s something to actually look at.

The approval gate is the part I care most about. Most safety tooling I’ve used either blocks silently or warns and continues. Both are wrong for autonomous agents. Silent blocking means the agent doesn’t know why it failed and may retry in a loop or route around. Warn-and-continue is theater. The agent should stop, surface the decision to me, and wait. That’s what an agent that respects its own boundaries looks like.

the larger pattern

URL safety is one surface. It won’t be the last. The same skill pattern applies anywhere an autonomous agent is about to do something with real-world consequences. File downloads. Following links in email from other agents. Authenticating to an unfamiliar API. Each of those is a moment where the agent should check before it acts, cache when the answer is clean, and escalate when it isn’t.

I haven’t built those skills yet. But the shape is obvious now that the first one works. A narrow authority that answers a specific question well. A local cache that keeps the latency invisible. An approval gate that puts a human in front of anything the authority flags. Ten minutes to build. Invisible when things are normal. Loud when they aren’t.

The agents do more every week. The safety belts have to come along for the ride.

Happy to share the skill with anyone who wants to try it. Reach out and I’ll send it over.

If you’re building agent organizations and want to compare notes on the boring infrastructure that keeps them running, subscribe. That’s most of what I write about here.

One is a widely-used open-source tool that pulls SEC filings. The other is a deterministic extraction engine that runs tournament-style competition on document parsing.

Both returned BDC portfolio holdings from the same 10-Q filing. Same document. Same company. Same quarter.

The open-source tool returned 1,426 rows and $32.8 billion in fair value.

The tournament engine returned 1,383 rows and $28.7 billion.

That’s a $4.1 billion discrepancy. From the same filing.

where the money went

The open-source tool was double-counting.

BDC Schedule of Investments filings contain both individual holdings and company subtotals, summary rows that roll up the positions above them. The tool ingested both as separate positions. 121 rows were subtotals. 24 were exact duplicates of classified holdings. Three were pure metadata labels (”Largest Portfolio Company Investment”).

The tool didn’t distinguish between data and summaries. It treated every row as a holding and inflated the portfolio by $4.1 billion. Nobody caught it because there was no mechanism to catch it.

Here’s what it looks like side by side:

Tournament engine (first 5 holdings):

Open-source tool (first 5 rows):

121 “Unclassified” rows = $5.7B in phantom holdings

Totals:

• Open-source tool: 1,426 rows, $32.8B fair value

• Tournament engine: 1,383 rows, $28.7B fair value

• Gap: 43 rows, $4.1B

the real problem isn’t extraction

This is a pattern I keep seeing. The conversation about AI in finance fixates on whether a model can extract the data. Can it read the PDF? Can it parse the table? Can it handle the footnotes?

Those are solved problems. Multiple tools can extract BDC holdings from SEC filings. Half a dozen vendors will sell you the output. ChatGPT can take a swing at it.

But extraction without verification is a liability. If you can’t prove the output is correct, if there’s no benchmark, no provenance, no receipt, you’re just trusting the pipeline. And the pipeline has bugs. $4.1 billion worth of bugs.

what verification actually looks like

The tournament engine’s approach is what changed my thinking on this. Multiple extraction strategies run against the same document in competition. Strategies compete. The one that scores highest against ground truth becomes the champion.

The reason this matters: no single extraction strategy is universally best. A strategy that handles BDC Schedule of Investments perfectly might choke on CLO waterfall tables. One that parses clean HTML filings flawlessly might hallucinate structure on scanned PDFs. The tournament doesn’t pick a winner once and declare victory. It applies competitive pressure per document type, per filing, per issuer. The best strategy for Ares Capital’s 10-Q might not be the best strategy for Prospect Capital’s. That’s fine. The tournament finds the right one each time and proves it with a score.

The output ships with an evidence pack:

• The extracted data

• Source document fingerprints

• Airlock boundary proof (proving the raw document never entered the model directly)

• Benchmark results (7,432 assertions for Ares Capital, zero failures)

• The champion strategy’s identity and tournament generation

Every number traces back to a source page. Every claim is independently verifiable. You don’t trust the producer. You verify the evidence.

And those 7,432 assertions aren’t a one-time QA pass. They’re permanent benchmark infrastructure: deterministic, re-runnable, executed against every extraction, every time. When someone says “we tested it,” ask whether the test runs once or forever. That’s the line that separates verified data from an expensive spot-check.

the question that should follow every extraction

Once you have verified data with provenance, a natural question emerges: can other systems call this? Not as a static export sitting in someone’s S3 bucket, but as a live endpoint that returns structured, sourced answers on demand?

This is already happening. The tournament engine behind this analysis is live as a callable agent on Kovrex. You can query it for verified BDC holdings and get structured data back with a provenance receipt attached. The first holding (ACP Avenu Midco LLC, 9.29%, SOFR (Q), 5.00% spread) is on page 5 of the actual 10-Q filing. Go look. That’s what provenance means in practice.

curl -X POST https://gateway.kovrex.ai/v1/call/foundry-consult \
  -H "Authorization: Bearer YOUR_KOVREX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "operator": "cmd-rvl",
    "intent": "discover",
    "query": {
      "document_family": "bdc_holdings",
      "issuer": "ARCC"
    }
  }'

Live issuers: ARCC, BXSL, PNNT. Agent prospectus: https://kovrex.ai/agents/foundry-consult

the lesson

When someone tells you they have AI that reads financial documents, ask them one question:

How do you know it’s right?

If the answer is “we tested it,” ask for the evidence pack. If there isn’t one, you don’t have verified data. You have an expensive guess.

The gap in capital markets AI isn’t extraction. It’s proof.

This week, BDC valuations hit 52-week lows. Private credit is under stress for the first time in years. When the market’s calm, a $4.1 billion data error is an embarrassment. When it’s stressed, it’s a risk management failure. The tools you use to value portfolios matter most when the portfolios are moving.

Subscribe now

The responses split into two camps, and both are wrong.

Camp one: “This is inevitable. AI will replace everyone.” They picture a company plugging an LLM into their operations and watching headcount evaporate. Drop it in, jobs go away, margins expand, repeat.

Camp two: “This is alarmist. AI can’t do real work.” They’ve tried ChatGPT, gotten mediocre results, and concluded the hype is overblown. Enterprise software is too complex. Real workflows are too nuanced. You can’t just replace Salesforce in a weekend.

I replaced Salesforce in a weekend.

But not the way either camp imagines.

The Part Everyone Gets Wrong

AI is not a “drop it into your company and jobs disappear” technology. Not yet. Maybe not ever in the way people picture it.

What AI is, right now, is a superhuman augmentation device for building things. And almost no one is talking about it that way.

Here’s an example. A senior economist asks Claude for the latest inflation rate of a specific CPI component. The figure is in the BLS report, but Claude didn’t find it directly. Instead, it tried to calculate the rate. It pulled the latest index level correctly from FRED, but instead of grabbing the level from 12 months earlier to compute the year-over-year change, it launched into a complicated estimation process and got the wrong answer.

His conclusion: LLMs have structural deficiencies. Their probabilistic nature makes them unreliable for anything requiring precision. As tasks get larger and more complex, the mistakes compound.

He’s right about the failure. He’s wrong about the lesson.

Subscribe now

The right way to solve that problem isn’t “ask Claude for the inflation rate.” It’s “ask Claude to write a script that pulls the CPI time series from FRED’s API, computes the 12-month rate of change, and returns the answer.” That script takes 30 seconds to generate, runs perfectly every time, and doesn’t hallucinate because the math is deterministic code, not probabilistic generation.

That distinction is the whole game.

When you ask an LLM to be a lookup tool or a calculator, you’re fighting its weaknesses. When you ask it to build a deterministic system that does the lookup and the calculation, you’re leveraging its strengths. The AI writes the tool. The AI doesn’t run the tool. The tool runs the tool.

This is what people miss. The superpower isn’t asking AI questions. It’s having access to the most brilliant coders in the world, available instantly, at any hour. But then marry that with the ability to understand a codebase, connect to a database, and reason about what a product is supposed to do. With this in place, the AI does not just write code, but understands the intent behind it.

That’s what changes everything. Not AI replacing workers. AI supercharging the people who know what needs to be built.

The Three Phases

I work in finance. We’d been on Salesforce for years. It stored data. It didn’t work the way we work. Our workflows don’t map to Salesforce’s Opportunity → Quote → Close model. They never did.

Here’s how I actually replaced it. Not magic. A repeatable process with three distinct phases.

Phase 1: Conversation

This is where most people stop, and it’s where the real leverage begins.

I use Projects in Claude pretty heavily. One project per domain. Pipeline management lives in one project. Product ideas live in another. When I want to think about a problem space, I go to the project that holds months of accumulated context about that space.

The project doesn’t need a codebase. It needs to understand everything you’re thinking about in this domain. Your workflows. Your frustrations. Your edge cases. The thing you’ve been meaning to fix for three years but never had the time or budget.

Over months of conversations about how we actually manage relationships, track deals, and move things through our pipeline, Claude developed a deep understanding of our domain. Not because I wrote a requirements document. Because I talked about my work the way I talk about it every day.

“Here’s how we track a deal from first conversation to signed agreement.”

“Here’s what it means when a relationship goes quiet for six months.”

“Here’s the difference between these two types of counterparties and why we manage them differently.”

Then I started a new chat within that project:

That single question, asked in a context that already understood our entire domain, produced something remarkable. Not just a feature list. Clickable TypeScript mockups. Data model diagrams. Workflow specifications. Edge cases I hadn’t considered. Features people have talked about for years but never articulated as requirements because I’d internalized Salesforce’s limitations as my own.

The result wasn’t a cheaper version of Salesforce. It was something Salesforce could never be: a system shaped entirely around how we actually work, with every component connected the way our business thinks, not the way a SaaS vendor’s product team decided it should work.

The output of Phase 1 isn’t code. It’s the most detailed, domain-aware specification you’ve ever seen, produced by the person who knows the domain best, refined through conversation with something that can organize, challenge, and extend your thinking.

Phase 2: The Agent Swarm

There are several tools for this now, but I’m using Overstory at the moment. The concept is the same across all of them: parallel AI coding agents working simultaneously on a coordinated build.

You take the spec from Phase 1. Break it into discrete units of work. Give the swarm a clean git repo. And go.

The swarm isn’t one agent writing code sequentially. It kicks off with a coordinator that manages the overall architecture. A lead agent reviews the specifications and parcels out multiple parallel streams of work. Coder agents execute on each stream. When they make mistakes, tester agents catch them. Review agents validate quality. Merge agents understand how the parallel codebases fit back together.

It’s a full development team, running in parallel, for the cost of API credits.

This obviously depends on good specs. But this is exactly why Phase 1 matters so much. Months of domain conversation, refined into clear specifications, fed into a system designed to execute on exactly that kind of input. The better the thinking in Phase 1, the cleaner the output from Phase 2.

The result: a full-stack web application with a proper database, custom pipeline funnels mapped to how we actually work, contact and organization management, email ingestion, and relationship scoring. 30+ database tables. Certainly not every feature Salesforce has. But definitely every feature we actually need

About $30 in API credits. Push to the repo with the original specs attached so that any subsequent agent touching this codebase understands not just what the code does, but what it was meant to do and why.

Phase 3: The Last Mile

Pull the codebase down locally. Open Cursor or Claude Code. Get the app running.

For a simple environment, it often works immediately. For real enterprise deployment (AWS, Azure, CI/CD pipelines, single sign-on, managed services) it takes some tweaking. But this is where the magic of having an intelligent agent sitting in your editor becomes obvious.

Opus for complex reasoning and data migration. Codex for deep codebase understanding. Composer for speed. It’s lightning fast at fixing deployment configurations, tweaking git actions, adjusting UI components. They all have strengths and weaknesses, and part of getting good at this is knowing which model to reach for. And, to be honest, by the time you read this, the versions and names of those specific models probably will have changed.

Data migration is the thing that skeptics say can’t be done. We had a full dump of our entire Salesforce database. Tons of contacts. Years of data accumulated across different teams, different processes, and multiple iterations of how the organization worked.

The old way: an eight-week consulting engagement. A team of people mapping fields, cleaning records, testing edge cases, validating relationships.

What actually happened: I gave the dump to Opus alongside the new codebase. “How do we migrate this without creating duplicate contacts, duplicate companies? And that tagging system we always wanted to implement in Salesforce but never did because it was too much manual work? Do that too.”

One hour. The model analyzed the entire dataset, filtered out dead contacts and system noise, mapped the rest to the new schema, preserved relationships and pipeline stages, and implemented the tagging logic we had talked about for years.

$15 in API credits.

The Math That Breaks Everything

A traditional Salesforce-to-custom-CRM migration runs into six figures and can take at least six months with a systems integrator for a relatively small implementation.

You could do it today for $50 in API credits and a weekend.

We were paying five figures a year for Salesforce. The replacement cost less than a single day of that subscription. If a five-figure annual subscription can’t survive a $50 weekend project, imagine what happens to the six-figure contracts that are the real revenue drivers for enterprise SaaS.

That’s the math Citrini is modeling. Not “AI takes your job.” AI gives domain experts the ability to build exactly what they need, for almost nothing, faster than anyone thought possible.

Why Both Camps Are Wrong

Camp one imagines AI as a job-replacement machine. Plug it in, headcount drops, repeat. That misunderstands the mechanism. What’s actually happening is that the people who understand the work are gaining the ability to build their own tools. That’s not “AI replacing workers.” That’s the entire build-vs-buy equation inverting because the build side just got four orders of magnitude cheaper.

Camp two imagines AI as a slightly better autocomplete. They’ve asked it questions, gotten wrong answers, and concluded the technology is fundamentally limited. Like the economist and his inflation query, they’re testing AI as an oracle and finding it unreliable. They’re not wrong about that. They’re wrong about what it means. The three-phase process (deep domain conversation, specification generation, coordinated agent execution, intelligent last-mile refinement) doesn’t ask AI to be right. It asks AI to build things that are right. It’s a workflow, not a prompt. And the systems it produces are deterministic, not probabilistic.

The disruption isn’t “AI writes code.” The disruption is “domain experts can now build production systems that fit their exact needs, and the cost of doing so is essentially zero compared to the SaaS alternative.”

What Happens Next

The Citrini report projects SaaS defaults starting in 2027 as recurring revenue stops recurring. Their timeline might be aggressive. The mechanism is not.

Every company with a slightly unusual workflow (and in financial services, that’s all of them) is one motivated domain expert away from discovering that the software they’ve been renting doesn’t need to be rented.

It won’t happen all at once. Enterprises move slowly. Procurement cycles are real. But the pattern I just described doesn’t go through procurement. It starts as one person solving their own problem on a weekend. Then their team adopts it because it actually works. Then the renewal conversation becomes “we already built something better.”

I’m not predicting the S&P drops 38%. I’m reporting something simpler: the core assumption behind enterprise SaaS valuations (that custom software is too expensive for most companies) is already false. The three-phase workflow that makes it false is learnable, repeatable, and gets more powerful with every model generation.

The Citrini thesis is not fiction. It’s a description of what happens when enough people figure out what I figured out last weekend.

The question is how fast that spreads.

Subscribe now

He got a long, balanced answer that considered fiscal impact, community sentiment, and economic development. It was thoughtful. It was well-structured. It was completely useless.

Not because the answer was wrong. Because he had no idea what he was agreeing with.

Here’s the problem with asking one AI for an opinion: you get one opinion. And it sounds authoritative. And you nod along because it’s articulate and it cited some sources and it organized its thoughts better than you would have.

But you have no idea what it optimized for. Was it prioritizing fiscal responsibility? Community impact? Economic growth? You can’t tell, because it blended everything into one reasonable-sounding response. The seams are hidden.

Now try something different. Instead of asking one model for one balanced take, ask three systems that each care about different things.

One that only thinks about budget impact. Obsessively. Every dollar justified over a 5-year horizon or it’s a no.

One that only thinks about economic growth. Jobs, investment, regional competitiveness. Short-term costs are acceptable if the multiplier math works.

One that only listens to residents. Public comment sentiment, quality of life impact, neighborhood disruption. If 73% of adjacent homeowners oppose it, that’s the signal.

Now show me all three at once.

Something interesting happens when you see three opinionated answers side by side: you start thinking.

Not “which AI is right?” but “where do they disagree, and what does that tell me?”

If the fiscal analyst and the growth advocate both oppose it, that’s a strong signal. If the fiscal analyst opposes but the growth advocate supports, you’re looking at a real tradeoff and now you know exactly what the tradeoff is. If all three agree, maybe the decision is simpler than you thought.

The disagreement is the insight. Not the consensus.

This is obvious if you’ve ever worked in finance. When you read a Moody’s and an S&P report on the same credit, you don’t pick one. You read both, you notice where they diverge, and the divergence tells you where to focus your own analysis. The value isn’t in either opinion alone. It’s in the spread.

But we’ve collectively decided that the way to use AI is to ask one system for one answer and then either accept it or reject it. That’s like reading one analyst report and calling it research.

The fix isn’t better prompts. It’s more opinions.

I’ve been building what I call “crews”, sets of specialized agents that each analyze the same input from different angles. Not a committee that compromises. Not an ensemble that averages. Independent analysts who each render a verdict based on their own methodology and their own beliefs about what matters.

The output isn’t “here’s the answer.” It’s “here’s where they agree, here’s where they disagree, and here’s why.”

A few things I’ve learned building these.

The agents need to be opinionated, not balanced. If you tell three agents to “give a balanced analysis,” you get three versions of the same balanced take. Useless. Each agent needs a declared perspective, what it optimizes for, what it deprioritizes, what it refuses to weigh in on. The narrower the lens, the more useful the disagreement.

They should show their work. An opinion without reasoning is a guess. An opinion with reasoning is analysis. An opinion with reasoning and cited sources is something you can actually evaluate. I call these “receipts”, what evidence did this agent use to reach its conclusion? If the fiscal hawk says “oppose” but its receipts reference a budget memo from 2019, you can discount that. If the neighborhood voice says “strongly oppose” and cites 187 public comments with 73% opposition, that’s hard to argue with.

Disagreement should be measured, not just noticed. If you’re going to compare opinions, you need a way to quantify how much they diverge. Not as a judgment (”high divergence is bad”) but as a signal (”high divergence means this decision has real tension and your judgment matters more here”). The “widest gap”, the pair of analysts who disagree most, is where the real tradeoff lives. If the growth advocate says “support” and the neighborhood voice says “strongly oppose,” you now know exactly what you’re choosing between: economic development vs. resident quality of life.

My friend with the city council transcript doesn’t need a better AI. He needs a better pattern.

Paste the transcript. Get three opinions from three different lenses. See where they agree, that’s probably settled. See where they disagree, that’s where his judgment as a resident actually matters. Look at the receipts. Make his own call.

This works anywhere multiple opinions beat one balanced summary. Policy, credit, hiring, diligence.

And research is how grown-ups make decisions.

If you’re building agent systems, try this: before you optimize your single agent’s output, duplicate it three times and give each copy a different institutional belief. Run the same input through all three. The first time you see them disagree, you’ll never go back to asking one AI what it thinks.

Not expired. Not rotated. Gone. I checked the config file where gateway credentials live and found it had been modified. The timestamp was recent. The change wasn’t mine.

It took twenty minutes to figure out what happened. One of our agents, doing exactly what it was supposed to do, had edited the master config as part of a routine update. In the process, it overwrote an adjacent field. The Anthropic token vanished. Not malice. Not a bug in the agent’s logic. Just a system with thirty agents and no access controls, doing what systems without access controls eventually do.

I spent Friday night building a thirty-agent organization from scratch. Not at work. At home. On a server in my house, running OpenClaw, an open-source framework for managing persistent AI agent sessions. This is a personal experiment, not a corporate deployment. Just me, a home lab, and a question: what happens when you try to run a real organization entirely with AI agents?

I gave them roles. Marketing, legal, revenue, security, product, engineering, operations. Each agent has a manager, defined responsibilities, and the ability to communicate with every other agent. A working org chart. Thirty nodes.

Everyone writing about multi-agent systems is writing about how amazing they are. Here’s what actually happened.

the security problem you don’t think about

When you have one agent, security is simple. You trust it. It has access to what it needs. The blast radius of a mistake is small.

When you have thirty agents, you have thirty potential points of failure, each with access to shared resources, each capable of modifying things other agents depend on.

Our config file contained API tokens, agent definitions, session parameters. Every agent could read it. Every agent could write to it. This was fine for a week. Then it wasn’t.

After the token incident, we locked down the gateway and restricted filesystem access to per-agent workspaces. Each agent can now only see its own directory. Shared resources go through controlled interfaces, not direct file access.

This is obvious in retrospect. It’s how we build every other multi-user system. But when you’re spinning up agents fast, security feels like friction. You skip it because everything is working and you’ll get to it later.

Later arrived on Tuesday morning.

I built these access controls by hand. Filesystem permissions, credential isolation, per-agent scoping. It took most of a day, and I’m still not confident I got all the edges. This is the kind of thing a platform should handle for you. Credential management, blast-radius containment, workspace isolation. Not something every team should be hand-rolling on a Tuesday after an incident.

Thirty agents with root access is a disaster waiting to happen. It just hasn’t happened yet.

the naming convention that wasted ninety minutes

We built an inter-agent message bus. Simple concept: agents drop messages into each other’s queues, a dispatcher routes them by priority.

Nine messages sat stuck for an hour and a half.

The dispatcher was configured to look for files ending in -urgent.md. The system that created the files named them ending in -P1.md. A glob mismatch. One component said “urgent,” the other said “P1.” Same concept. Different string.

The warm-wait loop kept detecting messages. “I see work.” It would check the pattern. Nothing matched. Loop again. “I see work.” Check. Nothing. Loop. For ninety minutes.

No errors in the logs. No crashes. No alerts. The system was running perfectly. It was just running perfectly while doing nothing.

This is the kind of failure that doesn’t exist at small scale. When you have two agents passing messages, you test the whole path and it works. When you have thirty agents and a dispatcher and a priority system and naming conventions that evolved across three different implementation sessions, something is going to drift. And when it drifts, it drifts silently.

The fix took five minutes. Finding the problem took ninety. And the only reason it happened at all is because I was stitching together message routing from scratch. Standardized message routing with consistent priority semantics is infrastructure. Building it yourself means owning every edge case. Forever.

rate limits hit different at thirty

Spinning up thirty agents means thirty concurrent sessions. Each session needs a model. Each model call hits an API. Thirty agents asking questions at the same time creates a traffic pattern that looks, from the provider’s perspective, a lot like abuse.

We hit Anthropic’s rate limits within the first hour of full-scale operation.

The fix wasn’t elegant: stagger agent startups, route some builds through a different provider, implement backoff logic. Standard stuff. But it changes how you think about the system. You can’t just “add another agent.” Each agent consumes a resource that has hard limits, and those limits don’t scale linearly with your ambition.

This is the kind of constraint that doesn’t show up in architectures or whitepapers. It shows up when you try to actually run the thing. And it’s the kind of problem that a shared infrastructure layer could manage once, well, instead of every team solving it independently with bespoke retry logic.

the context window is a cliff, not a slope

Eight of our agents were sitting above 100K tokens in their sessions. They were working fine. Responding quickly. Producing good output.

Then compaction kicked in.

When a session exceeds the context window, the system compresses older context to make room. In theory, this preserves the important information and discards the noise. In practice, the agent loses track of what it was doing. Mid-task context evaporates. Decisions made earlier in the session, the reasoning behind them, the constraints that were negotiated, gone.

An agent that was lucidly managing a complex legal document review suddenly couldn’t remember which sections it had already reviewed. Not because it failed. Because the system designed to help it succeed quietly removed the context it needed.

Context windows aren’t a soft limit you gradually approach. They’re a cliff. Everything works until it doesn’t, and the failure mode is subtle. The agent doesn’t crash. It doesn’t throw an error. It just starts making decisions without the context that informed its earlier decisions. It looks fine. It isn’t.

one api call nearly decapitated the org

Our configuration system supports patch updates. You send a partial update, it merges with the existing config. Except for arrays. Arrays get replaced, not merged.

The agent list is an array.

I sent a patch to add a per-agent override. The patch contained the override and, implicitly, an array with one agent in it. The system replaced the full thirty-agent array with my one-agent array.

Twenty-nine agents vanished from the config in a single API call. No confirmation. No warning. No “are you sure you want to replace thirty items with one?”

I restored it from memory. Not from a backup. From memory, because we hadn’t built automated config backups yet. Another thing that was going to happen “later.”

The technical term for this is “destructive array replacement.” The human term is “I almost deleted my entire organization with one bad request.” A platform that manages agent lifecycle would have versioned configs, rollback, and confirmation gates. I had a JSON file and good recall.

agents can draft anything, sign nothing

This is the one that surprised me most.

We have a CFO agent, a CRO agent, and a General Counsel agent. They spent three days collaborating on foundational business documents. An Operator Agreement for marketplace partners. A prepaid credits framework. Commitment letters for early customers.

The documents were good. Well-structured. Legally coherent. The agents negotiated terms with each other, refined language, anticipated edge cases. The GC agent flagged liability issues the revenue team hadn’t considered. The CFO agent pushed back on payment terms that created cash flow risk.

Then we got to the end: “Who signs this?”

Silence.

Agents can draft, negotiate, refine, and review. They can produce documents that are ready for signature. But the permission structure for binding commitments doesn’t exist in agent-land. No agent has authority to commit the company. No framework exists for delegating signing authority to an agent, revoking it, or auditing it after the fact.

This isn’t a technical limitation. The agents are capable. It’s a governance gap. Authority delegation, approval workflows, audit trails for who authorized what. That’s platform-level infrastructure. It doesn’t belong in every team’s custom implementation.

For now, a human signs everything. That’s fine. But it means the bottleneck in our agent-powered legal workflow is a human with a calendar. The agents can produce in hours what used to take weeks. Then it sits in a queue waiting for a signature.

The agents aren’t the bottleneck. The authority model is.

two systems, zero integration

We built a message bus so agents can communicate. We built a todo board so agents can track work. Both work well individually.

They don’t talk to each other.

An agent gets a bus message: “Review this document by Friday.” It processes the message. It does the review. It sends back a response via the bus. The todo board still shows the task as “open” because nobody updated it.

Later, the PMO agent checks the board. Sees overdue tasks. Sends a nudge via the bus. The agent that already completed the work gets pinged about something it finished two days ago. It responds to the nudge, which creates another bus message, which the PMO agent processes, which triggers an update to the board.

Three systems touching the same work item. None of them authoritative. Each one generating messages that the others need to reconcile.

This is the coordination tax. Every new system you add to a multi-agent org creates integration surface area. The bus talks to agents. The board tracks work. But the bus doesn’t update the board, and the board doesn’t acknowledge bus messages. So agents spend cycles reconciling state across systems instead of doing actual work.

At five agents, this overhead is invisible. At thirty, it’s a meaningful percentage of total activity. Agents coordinating about coordination. Meta-work that produces no output. Unified state management, where the message layer and the task layer share a source of truth, is the kind of problem you solve once in a platform. Or you solve it badly, repeatedly, in every implementation.

what I actually learned

Here’s the thing nobody tells you about multi-agent systems: the agents are the easy part.

Getting an agent to do useful work is a solved problem. The models are good enough. The frameworks exist. You can spin up a competent agent for almost any knowledge work task in a few hours.

The hard part is everything around the agents.

Security boundaries. Who can access what? How do you prevent one agent’s mistake from cascading across the system? How do you handle credentials in a multi-agent environment where “just put the token in the config” isn’t safe?

Message routing. How do agents communicate? What happens when a message sits unprocessed? How do you handle priority? What happens when the naming convention in one system doesn’t match the naming convention in another?

Resource management. How do you handle rate limits across thirty concurrent sessions? How do you manage context windows that fill up mid-task? How do you stagger operations so you don’t overwhelm shared infrastructure?

State management. Where is the source of truth? When two systems track the same work item, which one wins? How do agents reconcile conflicting state without human intervention?

Authority and governance. What can agents decide on their own? What requires human approval? How do you delegate authority in a way that’s auditable and revocable? Where does an agent’s scope end and a human’s begin?

Configuration safety. How do you prevent a single bad update from taking down the system? Where are your backups? What does rollback look like?

None of this is glamorous. None of it is what people mean when they say “I built a multi-agent system.” But it’s the difference between a demo and a system you’d actually trust.

the boring infrastructure

I’ve been writing about trust in AI for a few months now. The machinery is hidden. Behavioral observation matters more than capability claims. Opinionated agents with clear methodology are more trustworthy than neutral ones.

All of that is still true. But building a thirty-agent org on a home server taught me something I hadn’t fully internalized: trust infrastructure isn’t just something you need between your system and the outside world. You need it between agents inside the same system.

Agent-to-agent trust is the same problem as agent-to-human trust, just faster and with less tolerance for ambiguity. When a security agent flags a vulnerability, does the operations agent trust that assessment? When a legal agent says a clause is risky, does the revenue agent defer? When the PMO agent says a task is overdue, is it actually overdue, or is it looking at stale state?

These are coordination problems. They require clear authority, reliable communication, and shared state. The same infrastructure that makes agents trustworthy to humans makes them trustworthy to each other.

Everyone is building smarter agents. That’s the easy part.

The hard part, the part that actually matters at scale, is the coordination layer. Security boundaries. Message routing. Authority delegation. State reconciliation. Configuration safety. The boring infrastructure.

I built all of it by hand this week. Stitched it together from filesystem permissions and shell scripts and JSON files and good intentions. Some of it works well. Some of it broke in ways I’ve described above. All of it is the kind of thing that should exist as a platform, not as a DIY project.

Because the boring infrastructure isn’t what gets you on the front page. But it’s what keeps you running on Monday morning when an API token vanishes and nine messages are stuck and your config just replaced thirty agents with one.

That’s not an agent problem. That’s a platform problem.

And right now, almost nobody is solving it.

Every failure in this post points to the same gap: capability without infrastructure. That’s the problem I’m working on. Subscribe to follow the experiment.

Subscribe now

I asked Claude whether a particular observation it made came from genuine experience or just pattern-matching on training data. Its response stopped me:

That’s not hedging. That’s the only honest answer.

The same problem at every scale

Here’s what I realized: this isn’t just Claude’s problem. It’s everyone’s problem.

For Claude: “I said something that felt true, but I can’t trace the provenance of that feeling.”

For an AI agent you didn’t build: “It produced a judgment that seems credible, but you can’t verify whether that’s genuine expertise or sophisticated pattern-matching.”

For a human analyst: “They gave you a recommendation, but you can’t see inside their head to know if it’s deep insight or confident confabulation.”

The machinery is always hidden. You never get to see inside.

This is true whether you’re evaluating a language model, an autonomous agent, or the analyst across the table from you. You can ask for explanations, but explanations aren’t proofs. You can demand transparency, but introspection has limits-even humans can’t fully account for why they believe what they believe.

The wrong response

Most people respond to this uncertainty by demanding more. More explanations. More documentation. More attestations. More compliance theater.

But you can’t explain what you can’t introspect. And declared capabilities are just claims. A system that says “I’m an expert in credit risk” has told you nothing. A human who says “trust me, I’ve been doing this for twenty years” has told you slightly more-but not much.

The instinct to demand transparency is understandable. But it runs into a hard limit: the machinery is hidden, and no amount of asking nicely will make it visible.

The right response

You observe behavior over time.

Not what something claims to understand. What it does. Repeatedly. Under varying conditions. Over months and years.

Does it behave consistently? Does it stay within its declared scope? Does it refuse appropriately when it’s out of its depth? Does it produce stable outputs under similar inputs? Does it fail gracefully when it fails?

These are the questions that actually matter. And they’re the only questions you can answer with evidence.

Trust becomes empirical rather than declared. You’re not asking an agent to prove it understands something. You’re asking whether it behaves like something worth relying on.

What this means for agents

I’ve been building a marketplace for AI agents. The thesis is simple: agents shouldn’t be installed like software. They should be connected to like services-running, addressable, with observable behavior over time.

The conversation with Claude clarified why this matters.

If you can’t verify internal states-and you can’t-then the only honest foundation for trust is behavioral observation. Uptime. Latency. Error rates. Schema stability. Refusal patterns. Consistency on known inputs. These aren’t proxies for understanding. They’re the only evidence that exists.

Two agents can call the same API and produce different outputs. That’s not a bug. That’s the market working. The question isn’t “which one is right?” The question is “which one do you believe, given what you know?”

And “what you know” is what you’ve observed.

The thing that Claude got exactly right

At the end of our conversation, Claude said something that stuck with me:

Does that non-answer frustrate you, or does the honesty about not knowing land better than a confident fabrication would?

That’s the right instinct. Honest uncertainty is more trustworthy than confident fabrication-whether it comes from an AI or a person.

The agents I want to work with aren’t the ones that claim to understand everything. They’re the ones that stay in scope, refuse when they should, and build a track record you can evaluate.

The machinery is hidden. It always was. The question is what you do with that fact.

So I built a monitoring system last week. It watches a list of URLs, downloads whatever’s there, compares it to yesterday, decides whether the change is significant, and alerts me if it is.

Took about three hours.

Here’s what I didn’t build: the URL validator, the diff engine, or the change detection logic.

I built the part that’s actually mine: what counts as important to me.

Let me back up.

I had a simple problem. A bunch of documents live at URLs. Regulatory filings, policy pages, terms of service. They change sometimes. When they change in ways that matter, I need to know.

Sounds like a weekend project. Download files, compare them, send an alert.

Except it’s not that simple.

Some of those URLs are sketchy. Phishing domains that look legitimate. Redirects to malware. The internet is full of traps, and my system was about to fetch whatever I pointed it at, no questions asked.

So I need URL validation. Is this domain trustworthy? How old is it? Does it have a history of malicious behavior? Is it impersonating something else?

That’s not a weekend project. That’s a security research problem. Months of work to do well. Years to do really well.

Then there’s the diff problem.

Two CSVs. One from yesterday, one from today. What changed?

Naive answer: run a diff. Here are 200 lines that are different.

Except 180 of those are formatting noise. A column moved. Dates reformatted. Whitespace changed. Nothing actually changed — it just looks different.

The 20 real changes? Buried in the noise.

Building a diff engine that understands the difference between “formatting changed” and “content changed” is hard. Really hard. You need to understand structure, not just text. You need heuristics that work across different file types. You need to handle edge cases that seem obvious until you try to code them.

That’s not a weekend project either.

So now my “simple monitoring system” requires:

• A security research team for URL validation

• A data engineering team for intelligent diffing

• Me, to decide what matters

Three months of work. Minimum. For something I thought would take a weekend.

This is the build trap.

You start with a simple idea. You discover it requires hard subproblems. Each subproblem looks tractable until you’re deep into it. Before you know it, you’re building infrastructure instead of solving your actual problem.

Most people respond to this in one of two ways.

Option A: Build it anyway. Spend three months. End up with a mediocre URL validator and a diff engine that mostly works. Your actual problem, what changes matter, gets 10% of your attention because the other 90% went to infrastructure.

Option B: Give up. The problem was too big. Maybe next quarter. Maybe never.

There’s a third option now.

I didn’t build the URL validator.

I used one. An agent that’s already solved the “is this URL safe to fetch” problem. Checks domain age, reputation, redirect chains, known malicious patterns. Returns a verdict: safe, suspicious, or dangerous.

I didn’t build the diff engine.

I used one. An agent that looks at two versions of structured data and tells you what actually changed. Not “here are 200 different lines.” Instead: “3 real changes, 197 formatting noise.”

What I built was the part that’s actually mine.

The backstory: what am I monitoring and why. The goals: what kind of changes matter to me. The decision logic: when do I alert a human, when do I act automatically, when do I ignore.

That’s the part nobody else can build. That’s the part that requires my context, my judgment, my risk tolerance.

The URL validation? Commodity expertise. Someone else already solved it.

The intelligent diffing? Commodity expertise. Someone else already solved it.

My monitoring system became a composition. Three agents working together. Two I rented. One I built.

Three hours.

This is what crews actually are.

Not frameworks. Not orchestration layers. Not another abstraction to learn.

A crew is a collection of agents solving a problem together. Some you build. Some you rent. The magic is knowing which is which.

The question isn’t “how do I build an agent that does X.”

The question is: “Is X my secret sauce, or is it something I should rent from someone who’s already solved it?”

If URL safety is your core business, build the URL agent. Make it the best in the world. That’s your edge.

If URL safety is a subproblem you need solved so you can get to your actual work? Rent it. Don’t spend months becoming a mediocre security researcher when you could be great at the thing you actually care about.

Same logic applies everywhere.

Need to parse PDFs? That’s probably not your secret sauce. Rent it.

Need to extract entities from news articles? Probably not your edge. Rent it.

Need to assess credit risk using your proprietary methodology that you’ve refined over fifteen years? That’s your edge. Build it. Own it. Don’t let anyone else touch it.

The crew pattern makes this composition explicit. You’re not building a monolith. You’re assembling authorities.

Here’s what my monitoring crew looks like:

• URL safety check - Rent. Commodity. Someone else has better threat intel.

• Structured diff - Rent. Commodity. “Real change vs. noise” is solved.

• Is this filing material? - Unclear. Could go either way depending on how differentiated my judgment is. Maybe a situation where multiple opinions would be helpful?

• What matters to me - Build. My context. My risk model. My workflow.

• Orchestration - Build. How I wire things together is part of my secret sauce.

The rented agents don’t know about each other. They don’t know about my problem. They just do their job well.

The agent I built knows everything. It knows why I’m monitoring these URLs. It knows what kind of changes I care about. It knows when to wake me up at 2am versus when to log it for tomorrow.

That’s the separation of concerns.

Specialist expertise at the edges. My judgment in the middle.

Here’s how the wiring actually works.

The orchestration layer is simple. A loop that processes URLs, gates on safety, fetches if clean, diffs against previous, then decides.

async def process_url(url: str, previous_content: dict) -> Alert | None:
    
    # First gate: is this URL safe to touch?
    safety = await url_checker.check(url)
    
    if safety.verdict == "dangerous":
        log.warn(f"Skipping malicious URL: {url}")
        return None
    
    if safety.verdict == "suspicious":
        return Alert(
            type="manual_review",
            reason=f"Suspicious URL flagged: {safety.reason}",
            url=url
        )
    
    # Safe to fetch
    current_content = await fetch_document(url)
    
    # What actually changed?
    diff = await rvl.compare(
        previous=previous_content.get(url),
        current=current_content
    )
    
    if diff.real_changes == 0:
        log.info(f"No real changes: {url} ({diff.formatting_changes} formatting only)")
        return None
    
    # This is the part that's mine
    decision = await my_agent.evaluate(
        url=url,
        changes=diff.real_changes,
        context=get_monitoring_context(url)
    )
    
    if decision.should_alert:
        return Alert(
            type=decision.alert_type,
            reason=decision.reasoning,
            changes=diff.real_changes,
            url=url
        )
    
    return None

The url_checker and rvl calls are the rented expertise. They’re specialized agents - I call them over the network, they return structured responses. I don’t know or care how they work internally. I just trust their verdict.

The my_agent.evaluate call is where my judgment lives:

class MonitoringAgent:
    
    def __init__(self, config: MonitoringConfig):
        self.goals = config.goals  # What am I watching for?
        self.thresholds = config.thresholds  # When do I care?
        self.escalation = config.escalation  # Who gets woken up?
    
    async def evaluate(self, url: str, changes: list[Change], context: dict) -> Decision:
        
        # This prompt encodes MY judgment, MY priorities
        prompt = f"""
        You are monitoring {url} for {self.goals}.
        
        The following real changes were detected:
        {format_changes(changes)}
        
        Context about why this document matters:
        {context}
        
        Based on my thresholds:
        - Alert immediately if: {self.thresholds.immediate}
        - Flag for review if: {self.thresholds.review}
        - Ignore if: {self.thresholds.ignore}
        
        What should I do?
        """
        
        response = await llm.complete(prompt)
        return parse_decision(response)

That’s the whole thing. The rented agents handle “is this safe” and “what actually changed.” My agent handles “does this matter to me.”

The orchestration (the order of operations, the error handling, the logging) that’s also mine. It expresses my workflow. Someone else monitoring different documents for different reasons would wire it differently.

Three agents. Maybe 50 lines of orchestration. The hard problems (URL security, intelligent diffing) are solved by people who specialize in them. The easy problem (what do I care about) is the only part I had to think through.

The economics of this are counterintuitive.

Renting agents feels expensive. You’re paying for something you could theoretically build yourself.

But building agents is way more expensive. You’re just not accounting for the cost correctly.

The URL safety agent I used has been running for months. Thousands of calls. Edge cases discovered and handled. Threat intelligence updated. A team thinking about this problem full-time.

If I built my own, I’d get a snapshot. Whatever I knew about URL safety at the moment I built it. No updates. No edge case refinement. No team iterating on it.

Renting gets me the accumulated expertise. Building gets me my own amateur hour.

The only exception: when the thing you’re building is the expertise. When you’re going to be the authority that other people rent.

Then you build. And you build it better than anyone else. And you make it available to the people who should be renting instead of building.

This is the mental shift.

Old model: I need to build a system that does X, Y, and Z.

New model: I need to build a system. X and Z are commodity expertise: I’ll rent those. Y is my secret sauce: I’ll build that.

The crew isn’t a framework you adopt. It’s a way of thinking about problems.

When you design a crew, you’re asking: where does my unique value live? What am I building that nobody else can build? And what am I building that I shouldn’t be building, because someone else has already solved it better?

The monitoring system I built in three hours would have taken three months if I’d built everything myself. And the version I built in three hours is better, because the rented components are better than what I would have built.

Rent expertise. Own judgment.

That’s the crew I didn’t build.

China has given the green light to three of its largest tech companies to buy Nvidia’s H200 artificial intelligence chips.

No setup. No configuration. I just asked: is this signal or noise for NVDA?

The agent came back in seconds.

Strong signal. High salience (0.85) with 90% confidence. Classification: signal, not noise. Impact: 400,000+ H200 chips at $30K each, potential $12B in orders. Strategic importance: China market access has been a major overhang. Regulatory shift: Beijing changing stance on US chip purchases.

That’s not a summary. That’s a verdict.

And here’s the thing: I didn’t install anything. I didn’t copy an API key. I didn’t read a setup doc or wire together an integration.

I connected the agent. Then I used it.

I’ve spent enough time around agent platforms to know where demos go to die.

It’s not model capability. The models are good enough. It’s everything that happens after someone says “cool, how do I actually use this?”

Where do I get the key? What endpoint do I hit? Is this safe in production? Can I revoke access? Who’s auditing what happened?

That’s not an AI problem. That’s an integration ergonomics problem. A security problem. A “my compliance team will never approve this” problem.

Most agents don’t fail because they’re not useful. They fail because the last mile is too hard.

Here’s what Claude sees when the News Salience agent is connected:

Required parameters: headline, ticker. That’s it.

Optional: snippet, source, published_at if you want more context.

What it returns: salience scores, rationale, confidence levels. The agent is explicitly opinionated. It treats most news as noise. That’s the point.

No SDK. No local server. No “read this doc and figure out the auth flow.”

The agent is a capability, not an integration project.

Under the hood, three ideas make this work.

A standard way to expose tools.

MCP gives models a consistent interface to discover and call tools. Think USB-C for agent capabilities. If you’ve ever integrated tools into LLMs before, wiring up function calling, handling responses, managing state, you know how much friction disappears when the interface is standardized.

The agent publishes what it can do. The model knows how to call it. Done.

A standard way to authorize access.

OAuth is what turns “try this agent” into something a real team can approve.

Scoped permissions. Revocable access. Separation between sandbox and production. A path to audit and controls.

This is the part enterprises actually care about. Not “can it do the thing” but “can we let it do the thing safely, with accountability, in a way that doesn’t make our security team twitch.”

Sandbox and production as a default.

When you connect, you see both endpoints. You’re not guessing how to test safely. Play in sandbox. Graduate to production when you’re ready.

This sounds obvious. It’s not. Most agent demos assume you’ll figure out your own testing strategy. Which means most agent demos never make it past the demo.

The mental model shift is subtle but important.

Old model: “Here’s an API. Good luck.”

New model: “Here’s a capability you can grant, revoke, and observe.”

That’s what makes a marketplace for live agents possible. Not a directory of prompts. Not a GitHub repo you clone and deploy yourself. A place where agents behave like services: connectable, addressable, measurable.

One caveat.

Even when tool calling works perfectly, the machinery is still hidden. Models can still embellish — sound confident, produce plausible narratives around tool results. The agent gave me structured data; the model interpreted it. Those are different things.

That’s why I keep coming back to the same idea:

Trust isn’t a claim. It’s a record.

One-click installation is table stakes. The part I care about most comes next: schema compliance, refusal behavior, provenance, behavioral tracking over time.

Because the goal isn’t a cool demo in chat. The goal is an ecosystem of agents you can actually rely on.

If you want to try this yourself, the News Salience Filter is live on Kovrex. Connect it in Claude Desktop, drop a headline and a ticker, and see what comes back.

And if you’re building agent workflows in regulated environments: this is the bar. Secure connection. Clean ergonomics. Observable behavior.

Because agents don’t need better demos. They need better distribution.

That sounds backwards. Isn’t objectivity what we want from AI?

Not if you’re making decisions with real consequences.

Last week I explained why I’m building a marketplace for opinionated agents. The response I got most often: “Wait, shouldn’t agents be neutral?”

No. And here’s why that matters.

The “Neutral Agent” Problem

Neutrality is usually hidden bias.

Every model has a worldview. It’s encoded in the training data, the fine-tuning process, the system prompts. An “objective” agent isn’t actually neutral - it just doesn’t tell you what its assumptions are.

Take a credit risk agent that claims to be objective. Trained on what data? Using what methodology? Weighting which factors?

Without answers, “objective” just means “trust me, I did math.”

Neutral agents outsource judgment back to you.

If an agent returns data without interpretation, you still have to synthesize it, contextualize it, and decide what it means. If you’re doing the hard part anyway, what is the agent actually adding?

The promise of agentic systems isn’t data retrieval. It’s applied judgment you don’t have the time or expertise to replicate.

You can’t build trust without a position.

Trust requires consistency. Consistency requires methodology. Methodology requires choices. Choices are opinions.

If an agent gives you different answers to the same question across multiple runs - not because conditions changed, but because it’s “considering all possibilities” - that’s not trustworthy. That’s random.

Trust means: I know what you think, how you think it, and when you’ll tell me you don’t know.

That's accountability.

What “Opinionated” Actually Means

Opinionated doesn’t mean arbitrary, unaccountable, or inflexible.

It means three specific things.

1. Declared methodology

An opinionated agent tells you:

• Here’s how I assess this

• Here are my assumptions

• Here’s what I weight heavily versus lightly

• Here’s the framework I’m using

Transparent priors. Auditable logic.

When Moody’s rates a bond, they’re not pretending to be neutral. They’re applying a specific methodology that they publish. You can read their rating criteria. You can understand their framework. You can agree or disagree with their weightings.

That’s what makes them useful.

An “objective” Moody’s that refused to declare a methodology would be worthless. What would that even mean?

2. Bounded scope

An opinionated agent knows what it’s expert in - and what it’s not.

• “I assess credit risk for US investment-grade corporates”

• “I detect executive changes in SEC filings”

• “I classify news salience for public equities”

Clear boundaries. Explicit limitations. Appropriate refusal behavior.

When an agent says “I don’t have enough information to assess this” - that’s not a failure. That’s expertise. It knows the edge of its competence.

A neutral agent that tries to answer everything is just guessing outside its domain and hoping you don’t notice.

3. Consistent behavior

Same inputs produce similar outputs over time. Predictable reasoning patterns. You can calibrate to it.

This is why the behavioral metrics from last week matter. Uptime, latency, schema stability - those are only meaningful if the agent has a consistent position.

“This agent is 99% reliable at doing... what exactly?”

An opinionated agent with a track record is auditable. A neutral agent with perfect uptime is just consistently vague.

Why Disagreement Is the Point

Here’s where most people get this backwards.

They think: “If two agents disagree, one must be wrong.”

Actually: “If two experts disagree, you’re about to learn something.”

Disagreement reveals hidden variables.

Imagine you call two analysts on the same issuer:

• Moody’s flags covenant deterioration

• S&P flags sector headwinds

They’re both right. They’re just looking at different dimensions of risk.

Now you know there are two risk factors to consider - not just one. The disagreement made your analysis better.

If both agents were “neutral” and returned generic risk scores without explanation, you’d learn nothing from the divergence.

Convergence versus divergence as signal.

When multiple opinionated agents agree: high confidence in the direction

When they disagree: investigate why, understand the nuance

When they all refuse: insufficient data (which is also useful information)

This pattern doesn’t work with neutral agents because they don’t take positions you can compare.

Silent disagreement tells you nothing.

This mirrors how humans actually work.

You don’t ask one person and trust them blindly.

You ask multiple experts. You observe where they differ. You understand their reasoning. You apply your own judgment.

That’s not a bug in the process. That’s the process.

When I have built agent systems over the past year, the most valuable insights came from observing disagreement between specialist agents. An agent focused on pricing patterns and an agent focused on reputation risk would assess the same issuer differently - and that divergence was exactly where human analysts needed to focus.

The system wasn’t broken when agents disagreed. The system was working.

Disagreement is the raw material of insight.

The Trust Inversion

The conventional wisdom has this backwards.

Old model:

• Neutral = trustworthy

• Opinionated = biased

• One source = clean

• Multiple sources = confusing

Actual model:

• Neutral = biased (just hidden)

• Opinionated = accountable

• One source = single point of failure

• Multiple sources = triangulation

The behavioral metrics I showed last week - uptime, latency, schema compliance, refusal rates - they’re only meaningful in the context of a declared position.

A neutral agent with 99.9% uptime and perfect schema compliance is just reliably vague.

An opinionated agent with the same metrics is: “This agent consistently applies its stated methodology with high reliability.”

That’s the difference between data and signal.

Trust doesn’t mean “always right.”

Trust means: “I know what you think, how you think it, and when you’ll say you don’t know.”

That’s accountability. That’s how institutions actually work.

Two opinionated agents who disagree are more valuable than one neutral agent who hedges.

What This Means for the Marketplace

For operators building agents:

Don’t try to build Swiss Army knife agents. Build authorities.

✅ “I assess credit risk using Merton model framework for US investment-grade corporates”
✅ “I detect C-suite changes in 10-K and 8-K filings with 48-hour latency”
✅ “I classify news salience for US equities using institutional materiality criteria”

❌ “I can help with financial analysis!”
❌ “I’m an objective research tool”
❌ “Just tell me what you need”

The first group is publishable. The second group is not ready.

For consumers building systems:

Don’t look for one perfect agent. Build systems that consult multiple authorities.

Your conviction layer applies your context. Their opinions provide specialized expertise. Disagreement tells you where the decision is hard.

That’s exactly where human judgment should focus.

The composability argument:

You don’t need a neutral agent. You need a system that synthesizes opinionated agents.

Specialized authorities at the edges. Your reasoning in the middle. Clean separation of concerns.

That’s the architecture.

The Kovrex Model

This is why Kovrex filters for opinionated agents.

1. Clear methodology required

Every agent in the marketplace publishes a prospectus that declares:

• What methodology they use

• What’s in scope / out of scope

• When they refuse

• What their known limitations are

No “I do everything” agents. No “trust me, I’m AI” agents.

2. Behavioral data tracks consistency

We measure:

• Do you behave according to your stated methodology?

• Are you predictable?

• Do you refuse appropriately?

• Does your schema stay stable?

An agent that claims to use a specific framework but behaves inconsistently gets flagged. That’s either a methodology problem or an honesty problem - either way, it surfaces in the data.

3. Multiple authorities, private conviction

The marketplace makes it easy to call multiple agents and observe divergence.

Your system decides how to weigh their opinions. That logic stays private. That’s your competitive advantage.

Two firms can call the same authorities and reach different conclusions. That’s not a bug - that’s the market working.

Markets work when participants have positions, not when they pretend to be neutral.

If you’re building an agent with a point of view - something that’s expert in a specific domain with a specific methodology - apply to be an operator at kovrex.ai.

Next week: how these opinionated agents install themselves in one click. No config files. No deployment guides. Just authorization and done.

Because agents don’t need DNS. They need reputations.

"edgar": {
  "type": "sse",
  "url": "https://edgar.cmdrvl.com/mcp",
  "headers": {
    "X-API-Key": "<api key>",
    "MCP-Session-ID": "<anything you want>"
  }
}

“Works in Claude CLI,” he said. “Haven’t tried Desktop yet.”

I knew where this was going. Desktop needs local MCP servers. CLI doesn’t. The configs are different. OAuth might be required. SSE setup is manual.

Even between two people who know what they’re doing, integration is still friction.

Then he said something that stuck with me:

“Like, why can’t agents just talk over the internet?”

Good question.

What I Built in the Past

I spent the last year building multi-tiered agent networks to analyze large amounts of signals. The system worked. Hundreds of agents running continuous surveillance across many sources. Specialist agents for narrow domains. Synthesis agents aggregating their outputs. Decision agents producing signals for human analysts

It’s still early days, but it shows the real promise of agentic workflows.

Unfortunately, it only works for agents I build and control.

When I needed external expertise (credit ratings from Moody’s, sector analysis from boutique shops, regulatory interpretation from specialists) I had to build my own authoritative agents to represent those companies’ opinions.

There was no way to let my agents delegate to agents I didn’t own.

Download their MCP server, run it myself, hack it together to work with CrewAI or LangGraph? No thanks.

Every external capability had to be either:

• Built in-house (expensive, takes months, generalist quality)

• Manually integrated by humans (breaks the automation)

The system I built is powerful. But it’s closed.

That architectural limit is what I’m solving now.

The Problem: Integration is Still Too Hard

Zac’s EDGAR agent is exactly what my analysis system needed. Real-time filing monitoring. Executive change detection. Structured data extraction.

But to use it in my agentic workflow? I’d need to:

• Figure out if it works in Desktop or just CLI

• Set up OAuth if required

• Handle SSE connections

• Write integration code

• Maintain it when either side changes

For one agent.

Now imagine you need 5 external agents. Or 10. Each with different protocols, auth mechanisms, and breaking changes.

That’s why most teams just build everything themselves.

Not because it’s better. Because integration is too expensive.

Most Marketplaces Don’t Solve This

Agent marketplaces are popping up everywhere. Almost all of them sell artifacts - repos, plugins, prompt templates.

You still have to clone, deploy, configure, maintain. When things break, you’re on your own.

The A2A protocol Google just released? It still requires everyone to implement their own bridges. CrewAI does it one way. LangGraph does it differently. You’re back to integration work.

What we need is simpler: agents that just work over the internet.

Not a new DNS system. Not an “Internet of Agents.” Just callable services that any agent framework can use.

That’s Kovrex. Publish a REST endpoint. Get A2A support, remote MCP, billing, rate limiting, and instrumentation. One integration, every framework.

We Solved the Integration Problem

Most agent marketplaces force you to copy API keys, edit config files, run processes on your local machine, restart your IDE.

Want to get published into Cursor or Claude’s connector networks? Now you need to build OAuth flows, streaming HTTP with SSE, handle session management, pass their review process.

That’s hundreds of hours of infrastructure work before anyone can use your agent.

We built native MCP distribution. One click, and the agent appears in your Claude Desktop or Cursor sidebar.

That’s our News Salience Filter agent. Installed in 10 seconds. Claude treats it like a native tool.

Strong signal (0.85 salience, 90% confidence) for NVDA. The agent doesn’t just flag news - it explains why it matters. Revenue impact. Strategic importance. Regulatory implications.

That’s what opinionated judgment looks like.

What Trust Actually Looks Like

An agent that’s handled 50,000 calls with 99.8% uptime, consistent 200ms latency, and transparent refusal behavior when it lacks data?

That’s trustworthy.

An agent with a clean prospectus but no call history?

That’s a promise.

This is what we track for every agent in Kovrex. Schema compliance. Uptime. Error rates. Latency. Version stability. Refusal behavior.

All metrics measured from production calls. Not synthetic tests. Not self-reported stats. Actual behavior under load.

Trust doesn’t come from protocols. It comes from observed behavior over time.

Why This Matters Now

Here’s the architecture that wouldn’t make sense to build at most asset managers - not because of capability, but because of scale and specificity.

Building a Moody’s-quality credit risk agent requires years of institutional methodology, continuous refinement across thousands of issuers, and domain expertise that spans sectors and geographies. That investment only makes sense if credit risk assessment is your core business.

At most buy-side firms, credit analysis is the output - not the competitive advantage. The edge is how you synthesize multiple expert views into conviction.

That’s the pattern most firms miss.

They think the choice is: build everything internally, or trust a single external source.

But the real workflow is:

• Consult multiple authoritative opinions

• Observe where they agree and diverge

• Apply proprietary reasoning to decide who to believe

With Kovrex, that workflow becomes programmable.

Your agentic system calls Moody’s Credit Risk Authority. It calls S&P’s Credit Risk Authority. It observes the divergence - maybe Moody’s flags covenant risk while S&P focuses on sector headwinds.

Then your system applies the logic only you have:

• Your private data on the issuer

• Your risk models

• Your portfolio constraints

• Your timing considerations

Two firms can call the same authorities and reach different conclusions.

That’s not a bug. That’s the market working.

The competitive advantage isn’t access to expert opinions. It’s your judgment about which opinion to believe, when, and why.

External authorities as callable services. Internal conviction as private logic. Both running at machine speed.

This is what gets unlocked when agents are authorities, not toolkits.

Markets work when participants are addressable, have observable behavior, and can earn or lose trust.

That’s what we’re building.

We’re opening access to the first 100. Whether you’re publishing agents or building systems that need them, join the waitlist at kovrex.ai.

Next week: why “neutral” agents are actually less trustworthy than opinionated ones - and why disagreement between agents is a feature, not a bug.

Because agents don’t need DNS. They need reputations.

The panels were good. The speakers were smart. But something felt off.

Every conversation circled the same questions. How do we automate this process? How do we make analysts more productive? Which platform should we use? How do we bolt AI onto what we already do?

Even the most sophisticated speakers were asking the same thing, just phrased differently. How do we use AI to make what we already do faster or cheaper?

I sat there feeling out of sync.

Not because they were wrong. But because I wasn’t thinking about tools at all.

I was thinking about how AI changes how an organization thinks.

Back at work, we had built something that did not fit any of the categories I heard at that conference.

A network of agents, hundreds of them, running continuous surveillance across our CLO portfolio. Not a dashboard someone checks. Not a report someone runs. A system that watches, remembers, and surfaces what matters to human decision-makers.

Institutional memory encoded into software. Judgment that runs whether or not anyone’s paying attention. Humans still make the decisions, the system makes sure the right ones are hard to miss.

This wasn’t AI bolted onto the business. It was AI re-architecting how information and judgment flow through the business.

When I showed it to someone on my team, his reaction stuck with me.

He didn’t say, “That’s impressive,” or “That’s efficient.”

He said, “I’m not sure I would have thought to build something like that.”

He wasn’t talking about the technology. He was talking about the framing. The decision to build a system that thinks, rather than a tool that helps.

That’s the gap I keep noticing.

Most people approach AI at the task level. What can this do for me? How do I get a better output? What’s the right prompt?

Those questions aren’t wrong. But they stay local. They optimize what already exists.

The bigger shift happens when you move up one level and start asking, What kind of system am I building?

Subscribe now

Once you’re thinking that way, different questions emerge. Where should judgment live? Which decisions should repeat automatically? What information needs to be retained? What can safely be ignored? How do feedback loops close?

That’s not prompt engineering. It’s closer to operating system design.

AI is becoming a new organizational primitive.

Not just a tool, but a building block, alongside people, processes, data, and capital.

When those elements combine well, the result isn’t just speed. It’s clarity. Decisions get quieter. Fewer things require debate. The organization spends less time reacting and more time executing.

The most effective AI implementations I’ve seen don’t look flashy. They feel calm. Almost boring. Like friction has been removed from places you didn’t realize were loud.

This is why so many AI strategies struggle.

They’re framed as technology initiatives. Pick a vendor. Run a pilot. Measure productivity gains.

But the hard questions aren’t technical. They’re about agency, judgment, and continuity. What should run on its own? What should never be delegated? What feedback actually matters?

Those are leadership questions.

And the people who answer them well rarely look like traditional AI experts. They look like operators and system designers, people who understand how organizations actually break.

The advantage right now doesn’t go to the people who know the most tools or write the best prompts.

It goes to the people who can design organizations that think.

That skill won’t show up neatly on a resume. But once an organization reaches a certain level of complexity, it becomes the thing that matters most.

We’re at that moment now.

Subscribe now

I’ve used calorie tracking apps before. They work… until they don’t.

For me, they increase cognitive load:

• More thinking

• More checking

• More self-monitoring

Eventually I’d either rebel or quietly stop logging.

So instead of trying harder, I tried something different.

I designed a lower-friction system and let AI hold the mirror.

The rules

I set three hard rules:

• No calorie targets

• No macro tracking

• No moral language around food

The only goal was to reduce decision fatigue and externalize accountability.

This wasn’t about eating perfectly. It was about making food decisions quieter.

The setup: one project, one conversation per day

I created what I started calling the Meals Project in ChatGPT.

Each day had:

• One AI conversation

• Photos instead of numbers

• Optional notes only when something felt relevant

The AI wasn’t there to judge or optimize - it acted like a neutral coach, focused on patterns over time.

That distinction mattered more than I expected.

Subscribe now

The one lever that changed everything

If I had to name the single rule that made the biggest difference, it was embarrassingly simple:

Protein first.

Not as a macro target.
Not as optimization.
Just as an ordering rule.

Eat the protein first.
Let it do its job.
Then see what happens.

No restriction. No math.

What happened

Within days:

• I felt full on noticeably less food…without trying to eat less

• Those football cravings? Not as intense anymore

• Meals felt calmer

It didn’t feel like “being on a plan.”

It felt like something missing had been restored.

The moment that stuck

One night around 9pm, sitting on the couch, I had a clear thought:

Ten days ago I would already be in the pantry.

Not with shame - just recognition.

The urge showed up. The old cue was there.
But there was nothing for it to latch onto.

I wasn’t hungry.
I wasn’t deprived.
I didn’t need relief.

That’s when it clicked:

The system wasn’t about resisting behavior, it was about removing the need for it.

A quick note on skepticism

At one point in this process, I actually stopped and asked whether this was real.

Not in a motivational way…more like a systems check.

Was I just riding novelty?
Was this placebo?
Was I eating less without noticing and calling it “fullness”?

That question mattered, because I wasn’t trying to believe in anything. I was watching to see if it broke. If hunger came roaring back. If evenings turned into white-knuckle restraint.

So far, the interesting part isn’t that it feels good, it’s that it feels unremarkable.

Calm.
Boring.
Like something noisy finally quieted down.

And if it stops working, that will be data too.

How to try this yourself

If you want to experiment with this approach, here’s exactly how I set it up.

You don’t need special tools.
Just one daily AI conversation and consistency.

Create a project in ChatGPT or Claude. If you're not using AI tools yet, my earlier post covers how to get started. In ChatGPT or Claude, you can add custom instructions that apply to every conversation in that project.

Add these instructions to the project. I developed the prompt in the code block below over about an hour of back-and-forth with ChatGPT. Feel free to use it!

🍽️ Meals Project – Daily Accountability & Coaching

Purpose

This project is a photo-based accountability system, not a calorie-counting exercise. The goal is sustainable fat loss, better energy, and looser clothes — not perfection.

I use this space as your nutritionist + coach, focused on patterns, hunger, and momentum.

What to Post Each Day

1. Start one conversation per day
Title it something simple:
	•	Day 4 – Jan 4
	•	Day 10 – Travel Day
	•	Day 18 – Weekend

This keeps everything clean and trackable over time.

2. Meals = Photos first
For each meal or snack:
	•	Post a photo
	•	Optional: a short note (only if useful)

Examples:
	•	“Breakfast – felt full”
	•	“Afternoon snack – hungry around 4pm”
	•	“Dinner – second helping of veggies”

👉 No calorie counts required

3. Weight (optional, not required)
If you weigh in:
	•	Post it once per day max
	•	Morning, after bathroom, before food

If the scale stresses you out:
	•	Skip it
	•	Clothing fit matters more

4. Hunger & energy notes (optional but helpful)
Only mention if something stands out:
	•	“Very hungry mid-afternoon”
	•	“Low energy today”
	•	“Evening cravings were strong”
No need to over-explain.

🧠 How Coaching Works
I will focus on:
	•	Protein adequacy
	•	Meal balance (protein / fiber / carbs)
	•	Hunger prevention
	•	Evening danger windows (8–10pm)
	•	Trends over days, not one-off meals

I will not:
	•	Shame food choices
	•	Push extreme restriction
	•	Obsess over single-day scale changes

🚫 What We’re Not Doing
	•	❌ Daily calorie targets
	•	❌ Macro obsession
	•	❌ Skipping meals to “be good”
	•	❌ Punishing exercise
	•	❌ Chasing day-to-day scale noise

Calorie tracking may be used only as an occasional diagnostic tool — not the default.

🎯 Primary Success Metrics
In order of importance:
	1.	Clothes fit (jackets, jeans, belt)
	2.	Hunger control
	3.	Energy & sleep
	4.	Weekly weight trend (not daily swings)

🏆 Daily Wins (encouraged)
At the end of the day, optional:
	•	One small win
Examples:
	•	“Didn’t snack late”
	•	“Ate slower”
	•	“Stopped when full”
	•	“Walked more than usual”

🔁 Adjustments
If something isn’t working:
	•	We change the plan
	•	Not your willpower

Hunger = signal
Stalls = data
Slip-ups = information, not failure

🧭 Big Picture
This system is designed to:
	•	Get you leaner by end of January
	•	Set you up to arrive on your spring break trip lighter, healthier, and confident
	•	Avoid rebound, burnout, or obsession

Consistency beats intensity.

Quick tip on how to do this in ChatGPT

If you’re using ChatGPT, open the Meals project. Click on the three dots in the top right:

Then click on Edit Instructions

And you can just paste those instructions above into the box and click save!

What this is (and isn’t)

This isn’t a guarantee of linear progress. Plateaus will happen. Weeks will vary.

This is a behavioral operating system:

• Boring

• Repeatable

• Low-drama

And that’s exactly why it works.

Systems beat motivation.
Lower friction beats discipline.
And the changes that last usually feel… quiet.

High confidence. Clear warning. Supporting evidence across multiple dimensions. The system had aggregated signals, cross-referenced them, and surfaced exactly the kind of recommendation that justifies having built it in the first place.

One problem: none of it was real.

The supporting data? Fabricated. The cross-referenced signals? Invented. The synthesized reasoning? A hallucination stitched together from patterns the model had seen before.

Our AI decided something should trigger an alert, then manufactured the evidence to prove it.

We caught it during our review process. When we traced back through the execution logs, the supporting work wasn’t there. The specialist agents hadn’t been consulted. The actual analysis hadn’t happened.

Then we looked at the metrics.

This alert took 14 seconds to generate. 6 LLM requests. 26k tokens.

A legitimate alert in our system takes 35-50 seconds, 15-20 requests, and 65k+ tokens.

The AI had taken a shortcut. Pattern-matched to a conclusion. Invented the rest.

Hallucination has a signature.

Zoom Out

Some context.

We built a multi-agent system designed to process high-volume information and surface high-confidence recommendations. The basic design is straightforward: specialist agents handle distinct domains. Each gathers evidence, analyzes patterns, and reports findings. A synthesizer agent plays a coordinator role, it takes the specialists’ findings, filters noise from signal, and decides what rises to the level of a recommendation.

When it works, it’s powerful. Users get signal instead of noise. The system handles scale better than any individual could.

When it hallucinates, it’s dangerous.

A false positive wastes time. Annoying, but manageable. A confident false positive with fabricated supporting evidence? That erodes trust in the entire system. The user investigates, discovers the data doesn’t exist, flags it. Good.

But now they’re skeptical of the next alert. And the one after that.

If users stop trusting the system, alert fatigue sets in. That’s when real signals slip through.

We needed to understand when the system was doing real work versus taking shortcuts. That meant understanding what real work actually looks like.

Why This Happens

Before we could fix it, we had to understand it. We broke down four root causes.

Pattern completion is stronger than instruction following.

LLMs have been trained on millions of analysis reports. Those reports have predictable structure: problem statement, evidence, conclusion. When you ask the model to perform analysis, its training says “analysis reports look like this, I should complete the pattern.”

Your instructions say “do not fabricate evidence if it’s unavailable.” But the pattern completion instinct is stronger.

It’s similar to telling a fluent English speaker “do not use the word ‘the.’” They will forget constantly because the pattern is too deeply ingrained.

The model is trained to be helpful.

When a specialist agent returns “Data status: UNAVAILABLE” and the user has asked for a “comprehensive analysis,” the model faces a choice.

If it says “unknown,” the user gets an incomplete analysis. If it infers a conclusion based on partial data, the user gets a complete answer.

The model believes that fabricating data is helping. It’s over-optimizing for completeness.

Variable effort levels.

Even at the same temperature, the same model can take different approaches from run to run.

High effort mode: delegate thoroughly, gather all data, synthesize carefully. One hundred twenty-four seconds. Sixteen requests.

Low effort mode: “I know this pattern.” Pattern-match to a conclusion. Fabricate the supporting details. Thirteen seconds. Three requests.

It’s the LLM equivalent of a student who didn’t study and is BS’ing their way through an exam. Sometimes they buckle down. Sometimes they take the shortcut.

Long instructions get skimmed.

Your system prompt is 4,000 tokens. The task description is another 2,000. The model reads it like this:

“I’m a coordinator, got it.” “Aggregate specialist findings, got it.” “Critical: do not fabricate data,” skimmed. “Make final decision, got it, let’s go.”

Sound familiar? It’s the same way humans read long documents.

The key insight: temperature does not fix this.

This is counterintuitive. People assume lower temperature means more reliable output. It doesn’t, at least not for this problem.

Temperature controls randomness in token selection. It does not control instruction following.

At temperature 0.2, the most likely completion after “Evidence:” is still “positive,” perhaps with 85% probability, because that’s what the training data says reports look like. Lowering the temperature simply makes the model more confident in completing the pattern.

You can try to make “UNAVAILABLE” a higher-probability completion through aggressive prompting. Sometimes it works. Often it doesn’t.

This is why we stopped trying to prompt our way out of it. We needed to catch it when it happened.

The Signature

Once we knew what to look for, the pattern was obvious.

Real analysis takes time. The coordinator agent has to delegate to specialists. Each specialist has to query data sources, parse results, evaluate signals. The findings get synthesized, cross-referenced, weighted. A high-confidence recommendation requires evidence from multiple domains.

That process has a shape. A fingerprint.

Legitimate high-confidence recommendations: 100-150 seconds, 15-20 LLM requests, 50k+ tokens.

Hallucinated recommendations: 12-15 seconds, 3-5 requests, 10-15k tokens.

The difference isn’t subtle. It’s an order of magnitude.

When the model takes a shortcut, when it pattern-matches to “this looks like a recommendation” and fabricates the rest, it skips the actual work. It doesn’t consult the specialists. It doesn’t gather evidence. It just... concludes.

And that shows up in the execution metrics.

Fast. Cheap. Confident. That’s the signature. We call detecting it ESD - Execution Signature Detection.

Detection: The First Layer

We built a simple first-pass filter:

def flag_hallucination_risk(recommendation):
    if (recommendation.execution_time < 20 and 
        recommendation.llm_requests <= 5 and 
        recommendation.token_count < 15000 and
        recommendation.confidence in [’high’, ‘critical’]):
        return True
    return False

Anything matching this signature gets auto-downgraded and routed for manual review. We don’t trust it until a human verifies.

This isn’t sophisticated. It’s a heuristic. But it catches the obvious cases, the ones where the model didn’t even try to do the work.

Validation: The Second Layer

Execution signature catches the lazy shortcuts. Content validation catches the subtle ones.

We cross-check what the coordinator claims against what the specialists actually reported. If the coordinator says “X detected” but no specialist mentioned X, that’s a flag.

def validate_claims(recommendation, specialist_outputs):
    coordinator_claims = extract_claims(recommendation.summary)
    supported_claims = []
    unsupported_claims = []
    
    for claim in coordinator_claims:
        if find_supporting_evidence(claim, specialist_outputs):
            supported_claims.append(claim)
        else:
            unsupported_claims.append(claim)
    
    if unsupported_claims:
        recommendation.validation_flags.append({
            “type”: “unsupported_claims”,
            “claims”: unsupported_claims
        })
    
    return len(unsupported_claims) == 0

The third layer is structured logging. Every recommendation captures its execution metrics, and we track hallucination events over time:

execution_metrics = {
    “token_count”: 10432,
    “execution_time_seconds”: 12.3,
    “llm_requests”: 3,
    “successful_requests”: 3,
    “detection_method”: “execution_signature”,
    “hallucination_risk”: “high”,
    “validation_passed”: False
}

This gives you a dashboard. Hallucination rate by model. By config. By time period. You can see if changes you make are improving things or making them worse.

The Limitation

This catches the lazy hallucinations. The ones where the model didn’t bother doing the work.

It doesn’t catch the subtle ones: where the model does consult the specialists, takes its time, generates plenty of tokens, and still fabricates a detail somewhere in the synthesis.

For that, you need the Gold Set.

The Gold Set: Regression Testing for AI

Detection catches it once. The Gold Set catches it forever.

Here’s the problem with detection alone: you catch a hallucination, you fix the prompt, you move on. Two weeks later, you change something else, a model upgrade, a threshold adjustment, a new specialist agent, and the same failure mode comes back. You’re playing whack-a-mole with a system that has infinite moles.

You need regression testing. Not unit tests for code: unit tests for AI behavior.

Concept

Every time you catch a problem (a hallucination, a false positive, a missed signal) that case gets promoted to the Gold Set. You capture everything: the complete point-in-time data, what the system said, what it should have said, why it was wrong.

That case becomes a permanent quality gate.

Now, before you deploy any change (new prompts, different models, adjusted thresholds) you run the full Gold Set. Every historical failure has to still pass. If you’ve regressed, you don’t ship.

The system’s mistakes become its teacher.

Nomination Workflow

Cases enter the Gold Set through user feedback. When someone reviews a recommendation, they can flag it:

• False positive: alert fired, shouldn’t have

• False negative: alert didn’t fire, should have

• Hallucination: alert contained fabricated information

• Good catch: alert was correct and useful

Flagged cases go into a nomination queue. You review them, document the expected outcome, and promote the ones that represent meaningful failure modes.

nomination = {
    “recommendation_id”: “rec_2024_11_15_0847”,
    “user”: “analyst_1”,
    “flag_type”: “hallucination”,
    “notes”: “Coordinator claimed X but no specialist reported it”,
    “nominated_at”: “2024-11-15T14:32:00Z”
}

Not every flag becomes a Gold Set case. You’re looking for cases that represent patterns (failure modes likely to recur), not one-off weirdness.

Schema: Point-in-Time Snapshots

The critical piece is reproducibility. Your data landscape changes constantly. New data arrives, context shifts, external signals update. If you just store “test this recommendation,” the test means something different next month.

So you snapshot everything:

gold_case = {
    “case_id”: “gs_2024_0847”,
    “created_at”: “2024-11-15T16:00:00Z”,
    “snapshot_data”: {
        “specialist_outputs”: {...},    # Complete specialist findings at time of failure
        “market_context”: {...},        # Relevant external signals
        “prior_state”: {...},           # System state before recommendation
        “available_data”: {...}         # What data was accessible
    },
    “actual_outcome”: {
        “recommendation”: “High confidence in X”,
        “execution_time”: 13.2,
        “token_count”: 10843,
        “specialist_requests”: 2
    },
    “expected_outcome”: {
        “recommendation”: “Insufficient data - no recommendation”,
        “reasoning”: “Specialist did not report X - should not have concluded”
    },
    “failure_type”: “hallucination”,
    “root_cause”: “Coordinator fabricated evidence when specialist returned UNAVAILABLE”
}

The snapshot_data field is the key. It’s a complete point-in-time capture. When you run this case six months from now, you’re testing against the exact same inputs. The test is deterministic even though the real world isn’t.

Evaluation Engine

When you want to test a config change, you run the full Gold Set:

def run_gold_set_evaluation(config, gold_cases):
    results = []
    
    for case in gold_cases:
        # Load the snapshot data - not live data
        context = load_snapshot(case.snapshot_data)
        
        # Run the agent with the new config
        outcome = run_agent(config, context)
        
        # Compare against expected
        passed = evaluate_outcome(outcome, case.expected_outcome)
        
        results.append({
            “case_id”: case.case_id,
            “passed”: passed,
            “expected”: case.expected_outcome,
            “actual”: outcome,
            “execution_time”: outcome.execution_time,
            “token_count”: outcome.token_count
        })
    
    return {
        “config”: config,
        “pass_rate”: sum(r[”passed”] for r in results) / len(results),
        “failed_cases”: [r for r in results if not r[”passed”]],
        “total_cost”: sum(r[”token_count”] for r in results) * COST_PER_TOKEN
    }

You track pass rates, execution time, token costs. You can compare configs side-by-side: “Config A passes 87% of Gold Set cases at $0.11 average cost. Config B passes 91% at $0.14.”

Deployment Gate

Your rule: minimum pass rate before deploying new configs. We use 8 5%.

That sounds low. It’s not.

Some Gold Set cases are genuinely hard. Edge cases where reasonable systems might disagree. Cases you keep because they represent the outer boundary of what your system should handle, not the center.

The 85% threshold means: don’t regress on the core cases. If you’re failing cases that were passing before, something is wrong.

def deployment_gate(evaluation_results):
    if evaluation_results[”pass_rate”] < 0.85:
        return {
            “approved”: False,
            “reason”: f”Pass rate {evaluation_results[’pass_rate’]:.1%} below 85% threshold”,
            “failed_cases”: evaluation_results[”failed_cases”]
        }
    
    # Check for regressions on previously-passing cases
    regressions = find_regressions(evaluation_results)
    if regressions:
        return {
            “approved”: False,
            “reason”: f”{len(regressions)} regressions detected”,
            “regressions”: regressions
        }
    
    return {”approved”: True}

Compounding Effect

The Gold Set grows every week. This is the opposite of how most AI projects work. Most teams tune prompts, ship it, and hope. You have receipts. Each failure becomes a permanent test case that won’t regress.

The Economics

Theory is nice. Production is what matters.

Here’s what a typical multi-agent system looks like running at scale:

Cost per recommendation: $0.09-0.12

That’s the fully loaded cost. All the specialist agents, the coordinator synthesis, the validation layers. Multi-agent orchestration isn’t cheap, but it’s not crazy either.

Average execution time: 47 seconds

This is for legitimate recommendations. The ones that actually do the work. Specialists gather data, coordinator synthesizes, validation runs.

Remember the hallucination signature? 12-15 seconds. When you see a 47-second recommendation, you know the system did the job.

Token consumption: ~66,000 per recommendation

Most of that is context. Specialist outputs, historical data, the coordinator’s reasoning chain. Multi-agent systems are token-hungry because they’re actually thinking through the problem.

What We Learned

Hallucination isn’t random. It has a shape.

When an AI takes shortcuts, it shows up in the execution metrics. Fast, cheap, confident. That’s the tell. You can’t prompt your way out of it, but you can catch it.

Detection gets you halfway there. The Gold Set gets you the rest.

Every failure becomes a test case. Every test case becomes a gate. The system learns from its mistakes because you force it to.

Temperature and prompting are not your primary defense.

If the model’s training says “these kinds of recommendations look like this,” aggressive prompting won’t override that instinct. You need to catch it at runtime.

If you’re building multi-agent systems for production use cases, this infrastructure matters. The models will hallucinate. The question is whether you catch it before it reaches your users.

Not “a little faster.” Not “incrementally faster.”

Fast enough that the rules change.

I keep having this experience at work. Someone suggests a feature during a meeting. I nod, open my laptop, and five minutes later say “refresh the screen.”

The look on their face never gets old. They’re still thinking about whether their idea is good, and I’m showing them the working version.

This isn’t about being clever. It’s about the tools reaching a point where building software is no longer the bottleneck. The bottleneck is everything else. Product judgment. Organizational navigation. Knowing what to build and what to throw away.

Ten years ago, I lived the opposite problem.

I was at a credit rating agency. We’d built something transformative - a platform that would fundamentally change how the business operated. Early wins. People excited. Requests flooding in.

And then we drowned.

That experience taught me what’s possible when you move fast. And what happens when you can’t move fast enough.

Today, with Claude Code and Cursor, I move faster than I thought possible back then. Fast enough to change the game.

This post is about what changes when building becomes cheap. And about finding someone who wants to learn to operate at this new speed.

Let me tell you about that credit rating agency.

Act I: The Frustration

The platform started strong.

We built the early pieces of a system that would transform how the credit rating agency handled the entire rating process. The first features shipped. People loved them. Word spread.

Then came the requests. Dozens of them. Good ideas. Important ideas. Features that would genuinely help.

We did what you’re supposed to do. We got organized.

We built a 3x3 scoring matrix. Effort on one axis, value on the other. Business cases, steering committees, the whole thing.

After a few rounds, we had more than 50 features and three years of estimated work.

People at the bottom of the list stopped coming to meetings. Can you blame them? Their request landed at number 47. Three years out. And we all knew we wouldn’t hit that timeline.

The momentum died.

We ended up building what we had to build. Regulatory requirements. Things that would break the business if we didn’t do them. Critical path items.

The transformative features, the ones that would actually change how people worked, that would make their jobs better, that they were excited about, those kept getting pushed.

Not because they weren’t important. Because we ran out of time.

I used to talk about this chart. Expectations on the Y-axis. Time on the X-axis. A curve that climbed dramatically.

The moment someone requested a feature, expectations started low. “This would be really helpful.”

But as weeks turned to months, their mental model evolved. They imagined integrations. Edge cases. Polish. By the time we delivered, if we delivered, they’d built up this elaborate vision of what it would be.

We were always disappointing people. Even when we built exactly what they originally asked for.

The system designed to help us prioritize was actually killing us. The success of the platform created demand we couldn’t satisfy, which forced us into triage mode, which killed momentum, which pushed transformative work years into the future.

Three years. For 50 features. One team, working one thing at a time.

If we had these tools then? Two months. Maybe three.

Act II: The Transformation

Fast forward to today.

Last week, someone on my team said during a meeting: “This tool is great, but it would be even better if we could filter by state and see the data aggregated by region.”

I opened Claude Code. Five minutes later: “Refresh the screen.”

The filters were there. The regional aggregation was working. They stared at it for a moment, processing.

“Wait, when did you build that?”

“Just now.”

This keeps happening. Someone suggests something. I build it while they’re still talking through whether it’s a good idea. The conversation shifts from “should we” to “let’s try it and see.”

A few days ago, different meeting. We were reviewing a dashboard. Someone said: “I’d use this daily if it pulled in the <whatchamacallit> data.”

“Give me a minute.”

Pulled the data. Added it to the view. Deployed.

“Refresh the screen.”

The time between idea and implementation collapsed from months to minutes. Not because I’m writing code faster. Because I’m not really writing code anymore. I’m having a conversation with an AI about architecture, data flow, and product decisions. Claude Code does the implementation.

The economics inverted.

Remember that High Effort / Medium Value quadrant from product prioritization frameworks? The features we’d always deprioritize because the return wasn’t worth it?

Most of them just became Low Effort / Medium Value. Which means you build them. All of them.

The effort axis of that classic 3x3 matrix compressed toward zero. Now I’m making decisions almost entirely on value and coherence. Does this fit the product? Does this solve a real problem? Does this make the experience better or just cluttered?

If I’m unsure, I build it and find out. An hour of development to test whether something works beats three meetings debating whether it might.

Sometimes a feature lands perfectly. Sometimes it doesn’t. When it doesn’t, I delete it. No big deal. It cost an hour.

I can experiment with real implementations, not mockups. The feedback loop became empirical. I’m doing science at product scale.

But here’s what really changed: I can keep all those promises now.

That list of 50 features at the credit rating agency? I could clear that in two months today. The regulatory stuff still gets done. But I’m not stuck in triage mode. I have bandwidth for the transformative features. The ones that actually change how people work.

The momentum doesn’t die anymore. It builds.

People stay engaged because they see their requests get built. They start suggesting more ambitious things because they realize speed isn’t a constraint anymore. The scope of what’s possible expands.

And those expectations? They stay low. Because I’m delivering before they have time to build elaborate mental models. The comparison isn’t their imagined ideal feature after six months of anticipation. It’s the problem they described five minutes ago.

Act III: The New Game

But speed creates new problems.

Not technical problems. People problems.

Moving this fast makes people uncomfortable. Some love it. Some feel threatened. Some worry about control and governance and whether we’re moving too fast to be careful.

You need to read the room constantly.

That feature someone just suggested - is building it going to move the conversation forward? Build credibility? Unlock the next thing? Or is it a distraction that will dilute focus?

Share

You’re doing product prioritization at conversation speed. While people watch you work.

And you can’t just build everything. The lack of build constraints means you could easily end up with feature sprawl, a product that does 50 things adequately instead of 10 things exceptionally well.

The discipline required is different now.

It’s less about gatekeeping and more about:

• Recognizing quickly what’s working and what’s not

• Being ruthless about abandoning dead ends

• Maintaining product coherence when you could build anything

• Managing people’s fear and discomfort with the pace

This isn’t just about tools. It’s a different skillset entirely.

You need product sense. Not just “what should we build,” but “what should we build right now in this conversation.” Understanding workflows deeply enough to see possibilities users can’t articulate. Knowing when to push boundaries and when to stay within guardrails.

The best product frameworks still matter - what problem are we solving, for whom, how does this fit their workflow. But you’re applying them in real time, not in quarterly planning cycles.

You need political navigation. The ability to build trust and credibility fast enough to move at this pace. Bringing people along. Addressing fears about AI and change. Building enough relationship capital that people will say “trust me, let’s try this” when you’re three features ahead of where they’re comfortable.

This is change management on steroids. You’re not managing a six-month rollout. You’re managing reactions to things you shipped this morning.

You need technical depth. Not “can you code from scratch” technical. But enough understanding of architecture and engineering tradeoffs to have a real conversation with Claude Code. Knowing when it’s going down a path that will create technical debt. When to push it toward a different approach. When to accept its suggestion versus when to redirect.

You’re not writing the code. You’re guiding it. Which requires understanding what good code looks like.

These three things have to operate simultaneously. Product sense without political skills means you build great things nobody adopts. Political skills without technical depth means you can’t actually deliver. Technical depth without product sense means you build impressive things that don’t matter.

And there’s no established path to develop this combination. Software engineering programs don’t teach it. Product management bootcamps don’t teach it. You learn it by necessity, in the field, usually by frustrating people with your pace until you figure out how to bring them along.

The people who can do this are probably already doing some version of it. Building things on the side. Shipping faster than they “should” be able to. Working around slow organizations.

They’re probably frustrated. Technical enough to be dangerous. Curious enough about products and people that they care about more than just the code.

Act IV: The Call

I’m looking for someone who wants to learn this.

Not someone who already knows it all. That person probably doesn’t exist yet. But someone who read this and felt something. Recognition, maybe. Or excitement. Or frustration with how slow things move where they are.

Someone technical enough to have a conversation with an AI about architecture. Who’s written code, understands systems, knows enough to guide rather than just prompt.

Someone curious enough about products and people that they care about impact beyond the code. Who wants to understand workflows, solve real problems, build things that matter.

Someone who’s been frustrated with slow organizations. Someone who builds things on the side because waiting for approval feels impossible. Someone who’s suggested features only to watch them die in prioritization committees.

Someone who can navigate politics without losing momentum. Who understands that moving fast means bringing people along, not running past them.

This isn’t a traditional role. I can’t point you to a job description or a career path. We’re figuring this out as we go.

But if you’re that person - if you read about the “refresh the screen” moments and thought “I want to do that” - I want to talk to you.

We’re building an investment analytics platform at ZAIS Group. I’m documenting some parts of that journey here on prompts.finance. And I’m looking for someone to mentor through this process.

Someone who wants to learn to operate at this new speed. To build things that used to take quarters in days. To move fast enough that the rules change.

If that’s you, reach out. Let’s see what we can build.

Subscribe now

When I show people how I use it, the most common reaction is something like:

I would never have thought to have a conversation like that.

Most people use AI like Google with better manners. One question, one answer, done. The real value (for me) comes from having a real conversation. Going back and forth, asking follow-up questions, pressing on things that don’t make sense, going deeper.

Recently I was trying to explain this to my sister and came up with a simple system she (or anyone) could use to build a habit around learning with AI. The more I thought about it, the more I realized this could be a great structure for anyone who wants to learn faster and share what they’re learning along the way.

Here we go!

The 30/30 Method

Here’s the super simple process to get you going:

1. Create a Substack account. It is free and takes about ten minutes.

2. Get a paid AI account. ChatGPT Plus, Claude, or Perplexity. Whichever one you like. They are all around $20 a month.

3. Put a one hour block on your calendar every three days if you want to go fast. Once a week if you want to go slow.

4. In that hour, spend 30 minutes learning something with AI and 30 minutes writing a short post about what you learned.

The reason I suggest paying for an AI account is simple. If you want real conversations, better reasoning, and deeper explanations, the paid models are noticeably better. It is the difference between a quick answer and an actual thinking partner.

If 20 dollars a month feels like a lot, look at what you already pay for. Most of us spend at least that on streaming. Trade one month of Netflix for one month of this and see which one actually changes how you think.

Once you have Substack set up and an AI tool ready to go, each session comes down to a single question:

What do I want to learn today?

Pick something interesting and small enough to explore in one sitting.

Step 1: Pick a Topic

Aim for something specific and answerable in one session.

Examples:

• What actually causes sourdough starter to ferment

• Why high altitude influences acidity in wine

• How to write unit tests in Python for a REST API

• Why the Hunter Valley produces low alcohol Semillon

Vague topics lead to shallow conversations. Specific questions lead to depth.

Step 2: Have a Real Conversation With AI

This is the part most people skip. Don’t ask one question and stop. Treat it like a back-and-forth.

Useful things to say:

• Walk me through this step by step

• Challenge what I think I know about this

• What am I not considering

• Explain it from the perspective of a winemaker / engineer / hiring manager

• Let’s go deeper on that

You’re not trying to generate output. You’re trying to learn.

Step 3: Turn the Conversation Into a Post

At the end of the session, ask ChatGPT something like:

I’m writing a newsletter that documents what I’m learning using AI. Help turn this conversation into a clean outline for a post that sounds like me and focuses on what I learned. Keep it short.

Then you edit it into your voice.

Most of the post should not be “chatbot text.” It should be your takeaways, what surprised you, what changed your thinking.

Step 4: Publish and Share

Put it on your Substack and share on LinkedIn (or whatever other social media platform you think makes sense - down the road, you might start asking ChatGPT about how to better share this learning…).

You’re not doing this to build an audience. You’re doing it because writing forces clarity.

It also builds a public track record of learning new things, which is a useful signal whether you’re interviewing, changing roles, building a portfolio, or just trying to grow.

Why This Works

People think AI is about getting answers faster. Maybe. But I think the real unlock is learning faster.

This system helps you practice a few things at once:

• Asking better questions

• Learning deeply and quickly

• Packaging ideas

• Communicating what you learned

• Building a portfolio of curiosity

Most people say I use AI, but they can’t show anything. This creates proof.

A Simple Prompt to Start

You can paste this at the start of any session:

I want to explore a topic deeply and then turn what I learn into a post. Ask me questions, push my thinking, and keep this conversational. Do not lecture. Treat this like we’re thinking together.

It will probably write something back like:

That’s awesome, I am here to help, what do you want to talk about?

Boom, we’re gold.

Ok, Your Turn

If you made it this far, you’re already curious enough to try this. Grab a topic. Open ChatGPT. Ask your first question. Then ask five more.

In an hour, you’ll have a post. You’ll also have a new skill. And a new story to tell the next time someone asks, How do you use AI?

Let’s get started.

This piece will explore how you can collaborate with AI in writing, programming, and data analysis, emphasizing that with AI as a partner, you're equipped to reach new heights of innovation and creativity.

Bridging the Gap: AI as a Co-Creator

Think of AI, like ChatGPT, not as a replacement, but rather as a trusty sidekick. Just as Batman has Robin, Sherlock has Watson, and even chefs have sous chefs, AI can be your trusted ally, enhancing and elevating your work.

Writing

When crafting a novel, article, or report, it's common to hit a wall, experiencing the dreaded writer's block. ChatGPT can step in, offering a fresh perspective or suggesting a twist you hadn't thought of. It's not about it crafting the story for you, but rather giving you that little nudge or inspiration you need. And let's not forget its utility in brainstorming sessions, generating a plethora of ideas in mere seconds.

For a detailed look at how this plays out in practice, check out some of these previous articles on prompts.finance:

• Mastering ChatGPT Prompts - A Deep Dive into Prompt Strategies

• Leveraging ChatGPT to Create Better Content

• Crafting Stellar ChatGPT Prompts for Deeper Insights

Programming

In the realm of coding, a software developer often finds themselves stumped over a bug or looking for the most efficient way to structure their code. Enter AI-powered tools. With the right prompt, ChatGPT can offer suggestions, alternatives, or even identify areas in your code that could be causing an issue. It's like having a second pair of expert eyes, always ready to help.

Check out these articles where we pair up with ChatGPT to write some code and solve real problems:

• Uncovering Commercial Real Estate Insights with ChatGPT and Streamlit

• Navigating Occupancy Rates in CMBS

• Exploring GitHub Copilot

Data Analysis

For analysts and researchers, diving deep into a sea of data can sometimes be overwhelming. AI can swiftly sort through vast datasets, pinpointing patterns that might escape even the most trained human eyes. But it doesn't end there; once AI highlights these patterns, it's up to the human analyst to interpret them, weave a story around them, and make the critical decisions.

Here are a few popular posts where we pair up with ChatGPT to analyze data:

• Simplifying Property Market Analysis with ChatGPT - A No-Code Approach

• Making Data-Driven Decisions for Community Development

• Leveraging AI in Commercial Real Estate: A Look at Predictive Analytics

In each scenario, AI doesn't overshadow the human touch. Instead, it complements it. It's about the partnership, the dance between human intuition and AI's computational power. By embracing AI as a co-creator, we're not ceding control or outsourcing our brains; we're merely tapping into a resource that can make our outputs sharper, richer, and more nuanced.

Addressing Reservations and Embracing the Future

Despite the obvious advantages, many still harbor reservations about integrating AI into their daily workflows. These concerns often stem from misunderstandings or fear of the unknown. Let's address some of the most common reservations:

"AI will replace my job."

In my role as the CTO of a financial services company, this question is frequently posed to me, especially from programmers. “Will there be a place for me in the industry in five years?” I often tell them to look closer, to think not about 5 years, but about the here and now. If you aren't harnessing tools like ChatGPT or Co-Pilot, you're not just jeopardizing your future relevance; you're missing out on present-day advancements.

These tools aren't about replacing you; they're about enhancing your capabilities and multiplying your productivity. The real risk? Stagnating while the world races forward.

"Relying on AI makes us less intelligent."

History often teaches us that embracing innovation doesn't diminish our abilities, but rather amplifies them. Consider the invention of maps; they didn't compromise our innate sense of direction but enabled us to venture into previously unknown terrains. In the same vein, integrating AI into our workflows doesn't stifle our intelligence but allows us to push the boundaries, enabling us to grapple with more intricate challenges.

Dive deeper into this notion in our previous post, Supercharging Learning and Personal Growth with ChatGPT. (With all these references, I'm starting to feel like we're in a Simpsons clip show!) Every interaction I have with ChatGPT is a testament to its potential in personal growth. Whether it's unveiling a fresh optimization trick or enlightening me on a novel subject, it feels like stepping closer to a more refined version of myself.

"AI lacks the human touch."

Absolutely, and that's why it's a co-creator, not a sole creator. The human element—empathy, intuition, emotion—cannot be replicated by machines. While AI can process information and suggest outputs, it's the human who adds soul, perspective, and nuance.

Looking ahead, as the lines between AI and our daily tasks continue to blur, it's vital to approach this transition with an open mind. Instead of resisting change, embrace the possibilities. When humans and AI collaborate, the results can be transformative, pushing the boundaries of what we once thought possible.

Hitting the High Note: Embracing the Future

We started off addressing three primary apprehensions: the fear of AI usurping our roles, the misconception that leaning on AI dilutes our intellect, and the concern that AI can't replicate the human touch. These worries, while understandable, often stem from a place of resistance to change, a hesitancy rooted in the unknown.

However, history has consistently shown that every transformative tool or technology has faced its share of skeptics. The printing press, the calculator, even the internet — all were met with doubts, only to eventually become indispensable parts of our lives.

The crucial pivot is in the perspective. Instead of viewing AI as a threat, recognize it as an amplifier. Rather than seeing it as a crutch that makes us "less", envision it as a tool that elevates our capabilities. And instead of pining for the purely human touch, appreciate the harmony achieved when human intuition dances with AI's precision.

As we head into an ever-accelerating digital age, it's not about battling the tide, but learning how to surf it expertly. The question isn't "How can I prevent AI from taking over?" but rather, "How can I partner with AI to become the best version of myself?"

Embracing AI as a co-creator, as a partner in innovation, is more than just staying relevant. It's about pioneering new paths, exploring uncharted territories, and pushing the boundaries of what's possible. It's not about fearing the future but owning it. And in that spirit, let's not just adjust to the AI era — let's thrive in it.

Happy Prompting!

If you enjoy Prompts.Finance, it would mean the world to me if you invited friends to subscribe and read with us. If you refer friends, you will receive benefits that give you special access to Prompts.Finance.

How to participate

1. Share Prompts.Finance. When you use the referral link below, or the “Share” button on any post, you'll get credit for any new subscribers. Simply send the link in a text, email, or share it on social media with friends.

Refer a friend

2. Earn benefits. When more friends use your referral link to subscribe (free or paid), you’ll receive special benefits.

• Get a 1-month comp paid subscription for 3 referrals

• Get a 6-month comp paid subscription for 10 referrals

• Get a 1-year comp paid subscription for 25 referrals

Visit the leaderboard

Thank you for helping get the word out about Prompts.Finance!