Intelligence is cheap now. Trust is the bottleneck.

One line in a recent a16z crypto essay, The 5 Ways Blockchains Can Help AI Agents, has stuck with me. The authors write that “the bottleneck for the agent economy is now identity, not intelligence.” They point out that machine identities already outnumber human employees in financial services by roughly a hundred to one, and that most of those identities have no portable way to prove who authorised them or what they’re allowed to do.

I agree with that diagnosis almost completely. I’d go a little further, too. The same bottleneck shows up wherever agents produce work at scale, and the place I see it most clearly is software. Getting an agent to write code is no longer the hard part. Trusting what it wrote is.

The diagnosis

Take the blockchain out of the essay and what’s left is a clear statement of a few problems that don’t depend on any particular technology.

Agents don’t have a verifiable identity that ties them to a principal and a set of permissions. When people delegate decisions to agents, they need firm limits on what the delegated system can do. And once execution is cheap, verification becomes the scarce, expensive thing. The authors argue that markets underinvest in verification because oversight costs money now and failure arrives later.

That last point is the one I keep coming back to. It’s the quiet killer. A team ships an agent that produces output faster than anyone can check it. The checking gets skipped because it’s slow. Unverified work piles up as a liability that nobody priced. Gartner’s widely cited forecast that a large share of agentic projects will be abandoned by the end of 2027 is, underneath, a story about exactly this gap between how fast agents produce and how slowly people can verify.

What it looks like in software

Translate the essay’s language into a software team and it becomes very concrete.

Identity means being able to say which agent made this change, acting for whom, with what permissions. Not “the CI bot”, not a developer’s personal token that three agents happen to share. If you can’t attribute a change, you can’t reason about it after the fact, and you certainly can’t revoke the right thing when something goes wrong.

Limits mean the agent can only touch what it was meant to touch. An agent asked to fix a failing test shouldn’t be able to change the deployment config, and it shouldn’t be able to grant itself that ability halfway through.

Verification means a change is accepted because something independent checked it, never because the agent said it was done. Agents are very good at sounding finished. The tests either pass or they don’t.

And the essay asks for receipts: a history of who did what that can’t be quietly edited afterwards. In software that’s a record per change that an auditor, or just a sceptical colleague, can rely on.

None of this is exotic. A good engineering organisation already does most of it for humans, through code review, access control, CI and change management. What’s new is the volume. A team of ten people with agents can produce the change rate of a much larger organisation, and the human-shaped versions of these controls don’t scale with it.

The guarantee is the goal

The essay’s answer is a public blockchain: onchain registries for identity, attestations for verification, smart contract limits for delegation. Where agents transact in the open, that’s a strong fit, and I don’t want to argue against it.

The phrase in the essay I like most is that authority requires “enforceable guarantees built into the system itself.” I think that’s the real point, and it’s independent of where the guarantees live. Plenty of the organisations that feel the trust problem most sharply, banks, insurers, hospitals, government departments, can’t put their change history or their decision records on a shared network. Some run their most sensitive work with no outside connection at all. They still need every one of those guarantees. So the job is making the guarantees hold wherever the work happens, including places a public chain can’t reach.

What doesn’t work, wherever you are, is guarantees written as policy on top of a system that doesn’t enforce them. “Agents must not merge without review” in a wiki page is not a limit.

Where we fit

This is the problem we’ve organised Deep Thinking around. Kizuna is where AI agents build software under the customer’s rules. Every agent has its own identity. Its work is independently verified before anyone relies on it. People approve the changes that matter. And each change leaves one record of who asked, which agent did it, what checked it and who signed it off. Voxeltron is where the result runs, on ground the customer chooses.

We’re still in development, with a pilot programme open, so I’ll keep it at that. The part I’m confident about is the shape of the problem.

A few honest uncertainties

I don’t think anyone yet knows what good verification costs at scale. Running a test suite is cheap. Having a person genuinely review a risky change is not, and the temptation to drift from one to the other is strong. I also don’t know how quickly regulators will start asking for agent-level attribution rather than system-level logs, though my bet is sooner than most teams expect.

What I’m fairly sure of is the direction. Models will keep getting cheaper and better. Every improvement makes the work of trusting their output worth a little more.

If you’re working on the same problem, we’d like to hear from you. For more on what the record itself should answer, see deterministic replay as the audit trail.