Context, Capability, Correctness: Three Bets on Trusting an AI Agent

Two big agent platforms launched this month. Each addresses a different reason an agent cannot be trusted to act alone. But neither addresses the question that matters when the output is silicon: is the result actually correct?

August 12, 2026 • By Shivaram Mysore

Within a few weeks of each other, Cloudflare and Spotify each shipped a platform for putting AI agents to work inside a company. Both are serious pieces of engineering from teams who have thought hard about the problem.

What follows is my reading of the two, not a summary of claims either company makes. Neither presents its platform as a complete answer to whether an agent can be trusted, and I am not suggesting either does. What is interesting is that when you line them up, they turn out to have picked different halves of the problem — and that the half neither picked is the one my industry cannot ignore.

Both are also days old. Announcements describe intent; the rough edges show up later, and platforms of this reach accumulate a lot of surface to get wrong. Read the quotes below as design intent rather than field results — mine included.

Every agent platform is a bet on a single question: why can't we just let the thing act?

There are three defensible answers.

Bet one: it doesn't know enough

Spotify's answer is context. Their framing of the failure is the sharpest sentence I have read on this:

AI agents made fast, confident decisions that were technically correct and operationally wrong.

Technically correct and operationally wrong. Every engineer recognises that. The change compiles, the tests pass, and it is still the wrong thing to have done — because it ignored a decision the team made two years ago, or a service ownership boundary, or a constraint that lives in somebody's head and one Slack thread.

Their remedy is retrieval: capture what the organisation knows, keep it current, and feed it back so the agent understands your services, your dependencies, your architecture. The bet is that a well-informed agent makes good decisions.

Bet two: it can reach too much

Cloudflare's answer is capability. Their platform starts every agent with access to nothing and makes it ask:

Inside, every agent and app starts with access to nothing. An agent can ask for access to a specific resource, which you can grant or deny.

When access is granted, the agent gets a typed object rather than a credential — the secret stays isolated from the agent and from any code it writes. Between the agent and each real service sits what they call a Gatekeeper, which can narrow permission to one repository, allow reading issues but not source, mask fields, apply rate limits. Every resource an agent looks at is recorded, and that record follows the work.

Look at that list again and you will recognise it. Deny by default. An access-control list per resource. A policy enforcement point in front of every service. An audit log of everything touched.

This is a firewall. It is least privilege and perimeter control, pointed at a new kind of client.

That is not a criticism — it is the reason to take it seriously. Least privilege has forty years of operational history behind it, and it is one of the few security ideas that has survived contact with reality more or less intact. Cloudflare, of all companies, knows how to build this, and reaching for a proven model rather than inventing an agent-specific one is the correct instinct. If you must be wrong about something, be wrong about the thing that has been debugged since the 1980s.

They are also refreshingly unromantic about where models belong:

Many are a known sequence of steps with one or two places where judgment is useful. A workspace can turn those jobs into mostly deterministic workflows, using code for the predictable steps and a model only where it adds value.

That is exactly right, and it is the same conclusion we reached from the other end of the industry.

But notice what a firewall has never claimed to do. It tells you a packet was permitted. It has never told you the packet was correct. Nobody expects that of it, and no amount of tightening the rules gets you there — a perfectly configured firewall will pass a malformed request all day long, because that was never its job.

Bet three: it might simply be wrong

Here is the sentence this whole piece turns on.

A perfectly informed agent with perfectly scoped permissions can still produce a design that misses timing.

Read it slowly, because both platforms address the first two layers directly, and the sentence still holds. The agent knew the systems — every service, every ownership boundary, every architectural decision. It touched only what it was permitted to touch, through a typed capability, with the whole interaction logged. Context: solved. Capability: solved.

And the result is still wrong. Nothing in either design notices, because noticing was never what either was built to do.

That is not an oversight. Read both announcements closely and you find careful engineering around what an agent knows and what it may touch, and silence on whether what it made is right. Cloudflare logs everything an agent observed — but an audit trail tells you what happened, not whether the result is good.

And in their domains, they cannot do much better. Ask "is this internal workflow correct?" or "is this service refactor right?" and there is no program you can run that returns a trustworthy yes or no. The best available answers are the tests somebody wrote and the judgment of somebody who knows. Given that, context and capability really are the only two levers available, and both companies pulled theirs well.

Why silicon is different

Chip design is one of the few engineering domains where correctness is not a matter of opinion.

Does this layout violate the process rules? Does the netlist match the schematic? Does the design meet timing once you account for parasitics and crosstalk? These are not questions you settle in code review. They are computations, and they return a verdict. The domain gives you deterministic checks for important classes of correctness.

That changes what is possible. If a machine can decide whether the answer is right, then an agent can be allowed to propose freely, because something other than the agent gets the final say. The model plans; deterministic tools decide.

This is the thread we have been pulling on with Vyges™ Loom — open sign-off engines that check geometry, connectivity, parasitics and timing, and that describe their own interfaces so a model can discover and drive them without bespoke integration code. The engines are deterministic. Run them twice on the same input and you get the same verdict, whichever model asked.

Where we actually are

I want to be careful here, because it would be easy to write the triumphant version of this post and it would not be true.

This is early. The engines run, the verdicts are real, and we have correlated them against reference tools and published what we found, including where we came up short. That makes it a credible proof of concept. It does not make it a practice anyone depends on yet.

The harder part is not engineering. It is that adding a second, independent opinion to a sign-off flow is a change in how a team works, and changes like that are earned on somebody's real design, not in a blog post. No silicon team has yet built this into how they operate. Until one does, the honest description is "promising and unproven."

There is also a question we have not answered: whether an independent verdict is even the thing teams most want. It might be. It might turn out that what actually hurts is time to sign-off, or the tax of maintaining a dozen tool dialects, and that verification is the interesting-but-secondary part. We have a hypothesis. We do not yet have enough conversations to know.

Three layers, not three competitors

The useful conclusion is that these are not rival products. They stack.

Which returns us to the sentence above. Context and capability both fail open on correctness: they will let a wrong answer through, politely, with a complete audit trail and every permission properly checked.

For software, that is survivable; you find out in staging and roll back. For silicon, the feedback arrives as a mask set and a wafer run. That asymmetry is why we think the third layer deserves more attention than it is getting, and why we have spent the year building it in the open rather than as a product feature.

We would rather be corrected than agreed with

If you build chips and this framing is wrong — if the verdict is not what would help you, or the real pain is somewhere else entirely — that is the most useful thing you could tell us.

Three ways to help us find out, in increasing order of how much of your time it costs.

Run the engines. Install the suite and point a sign-off engine at something of yours. They are open source and need no account. Installing fetches the binaries from GitHub, as you would expect; after that, running an engine makes no network calls at all — we checked with strace, not just by reading our own code. Your design does not leave your machine. If the verdict disagrees with the tool you trust, we want to know that more than we want a clean result.

# macOS, or Linux with Homebrew
brew install vyges/tap/vyges

# anywhere else
curl --proto '=https' --tlsv1.2 -LsSf \
  https://github.com/vyges-tools/cli/releases/latest/download/vyges-installer.sh | sh

# then pull the sign-off engines and look at one
vyges install loom
vyges loom drc --help

Tell us how you would want to drive them. Every engine describes its own interface, so a model can discover and run them over MCP without integration code. The MCP server is local too — it speaks stdio and runs beside the tools rather than as a service we host, and it makes no network calls of its own. Which model you point at it is your decision, and that decision, not our tooling, is where your data boundary actually sits.

That whole design is a bet about how engineers will want to work, and it is a bet made mostly from our own bench. If you have a view on how sign-off should sit next to an LLM in your flow — or a reason the idea is wrong — we would rather hear it now than after we have built more on the assumption.

Talk to us about your situation. If you have a block, a flow, or a sign-off problem you are willing to describe, we will tell you honestly whether this is any use to you yet. Sometimes the answer will be no, and that is a useful conversation too.

See Vyges Loom · Read the docs · Start a conversation