DEV Community

Azan Hyder
Azan Hyder

Posted on

Models converged. Trust hasn't.

#ai #agents #llm #architecture

Field notes from the Harness Layer.

The models are becoming the same

Two years ago, choosing a model felt like the most important decision in the whole stack. The gap between the best frontier model and the next few competitors was wide enough that you had to design around it. Teams picked a provider the way they once picked a database, because the choice shaped everything built on top of it.

That era is ending. As of mid-2026, the leaderboards people actually cite, like LMArena and Artificial Analysis, show the top cluster within a few points of each other, and the cluster keeps getting denser. Every lab ships reasoning. Every lab ships tool use. API prices fell by roughly an order of magnitude across 2024 and 2025, and they kept falling after that. Open-weight models now trail the frontier by months rather than by a generation.

None of this is controversial anymore. The interesting part is what it does to the rest of the stack.

Scatter plot of frontier model scores from 2023 to now: widely spread dots in 2023 tighten into a dense indigo cluster labeled

Illustrative, not data. The shape is the claim.

When the models become interchangeable, the model stops being the product. A task that fails with one frontier model usually fails with the others in the same way, because the failure was never in the weights. It was in everything around them. Real edges still exist, mostly in long context, underrepresented languages, and tool-calling reliability, but the center of the distribution has converged.

The bottleneck moved

There is a frame circulating among people who build agent loops for a living: in any agent loop, the verifier is the bottleneck, not the model.

The logic becomes obvious once you watch a loop run. Generation is cheap and can spin forever, so a loop only produces value as fast as something can judge whether to ship the output, retry the step, or stop entirely. Andrew Ng's letters on agentic design patterns put reflection, the practice of the model checking its own work, at the center of agent engineering. Karpathy's Software 3.0 keynote frames the whole discipline as keeping fast generation wired to fast verification. The practitioners writing about loop engineering keep landing on the same gate from different directions.

Single-agent teams have absorbed this lesson. They write evals, they add judges, and they constrain output schemas. It is hard work, but it is understood work.

Now step up one level, to where the industry is actually headed. The destination is not one agent in a loop. It is many agents, from many vendors, speaking different protocols, composed into a single goal. And when you look at that picture closely, you notice that nothing about trust made the jump.

What convergence didn't touch

Watch a real multi-agent run and the trust story falls apart in familiar places:

  • Plans drift. The plan made sense at step one. By step four the context has shifted, an intermediate result was misread, and the remaining steps are executing confidently against a goal that no longer exists. Nobody noticed, because nothing was checking the plan against reality in the middle of the run.
  • Calls route wrong. The agent picked a plausible tool instead of the right one. With three tools this is a prompt problem. With thirty registered capabilities across a network, it becomes a retrieval problem, and many stacks are still solving it by stuffing everything into context and hoping for the best.
  • Identity is a vibe. Which agent acted, under what authority, with what declared scope? Protocol-level authorization and scoped tokens are starting to exist, but in most stacks the honest answer is still "whatever the prompt said." If an agent exceeds what it was allowed to do, there is no contract to point at. There is only a transcript to argue over.
  • Output evaporates. The run ends in prose. A chat bubble cannot be checked against a schema, diffed between runs, or monitored in production. It is the least verifiable format our industry has ever shipped at scale, and it is the default.

Different teams, different frameworks, same four failures. The models converged. The layer that would make runs trustworthy did not, because it barely exists.

Four cards side by side: plans drift (step four executes a goal that died at step two), calls route wrong (a plausible tool, not the right one), identity is a vibe (authority is whatever the prompt said), output evaporates (a chat bubble cannot be checked). Footnote: the models converged, the trust layer did not.

The transcript is not evidence

Here is the thought experiment I keep coming back to. An agent run executes something consequential overnight: it moves money between accounts, files a document, or changes infrastructure. In the morning you ask the obvious question: did it do what it was supposed to do?

What do you actually have to answer that with?

You have a transcript. It is a log of messages, in the best case with tool calls inline, and it was produced by the same system you are trying to check. You cannot verify it independently. You cannot show it to a third party and have them confirm anything. You cannot diff last night's run against last week's. You are asked to trust the narrator, and the narrator is the suspect.

Every other mature engineering domain has already built its version of an answer to this. Aviation does not trust the pilot's recollection, so it keeps a flight recorder that investigators can read without asking the airline. Finance does not trust the trader's terminal, so it keeps clearing records that both sides can reconcile. Software supply chains stopped trusting build claims and started demanding provenance.

Agent runs have nothing equivalent. Observability tooling exists and keeps improving, and traces, spans, and dashboards are genuinely useful. But a trace is still produced by the system you are checking, stored by the vendor you are paying, and viewable only by logging back into both. As independently checkable evidence, the state of the art in 2026 is a screenshot of a chat window.

Two panels. Left, dashed red border:

What a trust layer would have to look like

Sit with that gap long enough and some properties start to feel non-negotiable. I will offer mine as a draft, in the spirit of the first field note:

  1. Output as contract. Results come back in structured, schema-checked formats, so that "did it work" becomes a checkable question instead of a reading comprehension exercise. Plain prose still passes through when it has to, but prose is the exception rather than the interface.
  2. Identity and scope as data. Every actor carries a verifiable identity and a declared scope of what it is allowed to do, and that scope gets checked at orchestration time instead of being assumed from prompts.
  3. Verification that admits its own limits. Structural checks and semantic judgment are different things. Asking "is this well-formed, non-empty, and in contract" is not the same as asking "is this actually right." A trustworthy system says exactly which check it applied, instead of implying judgment it does not have.
  4. Evidence, not transcripts. A finished run should export something a third party can check independently. The test of evidence is simple: verification cannot require calling the system that produced it. Signed evidence still has to anchor somewhere, because someone has to answer whose key it is and under what identity it signed. That is part of why property two carries so much weight.

Notice what is not on this list: a better model. Every property here is orchestration, contract design, and verification engineering. That is not a coincidence. It is the convergence argument applied honestly.

A four-layer stack: 01 output as contract (structured, schema-checked results, prose is the exception), 02 identity and scope as data (verifiable actors, declared authority, checked at runtime), 03 verification admits its limits (says which check it ran, structural or semantic), 04 evidence, not transcripts (a third party can check the run without calling you), the fourth layer highlighted in indigo. Footnote: none of these is a better model.

The question

The first field note ended by asking what belongs in the harness layer. This one ends with the sharper version:

What evidence would make you trust an agent run you didn't watch?

Not "what dashboard would reassure you." Evidence. Something you could check yourself, show to someone else, and rely on when the run mattered. I have been working through one set of answers, and I suspect the interesting disagreements are in property four. Curious what yours are.

Sources and further reading:

Top comments (0)