Ond is a group of researchers and engineers. We found that the actions of autonomous agents lack a common governance abstraction, so we set out to build an open protocol for it. To prove it can run in real systems, we built OSuite. This post explains why we chose that order.
Where this started
For most of the last few years, enterprise AI meant generating things: answers, summaries, drafts, code suggestions. A person read the output and decided what to do with it. Governance could sit around the model: which data it could see, what it was allowed to say, who could use it.
That changed when agents started to act. Working with enterprises as they adopted AI, we watched the questions they asked shift. Early on they asked whether the answers were good. Later they asked something else: what will the agent actually do, and who said it could?
An agent that can open a pull request, refund an order, change a firewall rule or export a customer list is no longer producing text for a person to judge. It is taking an action whose consequences land in a real system. The organization that owns that system owns the consequences, whoever built the model.
Our research started from a simple observation. When an agent action goes wrong, the hardest questions are not about the model. They are about the action. What exactly was attempted? Was it allowed, by whom, and on what basis? Did what ran match what was approved? Can anyone outside the system check the answer?
Why a protocol, not a product feature
Take one ordinary action: deploying code to production.
In a single company, that action might arrive as a shell command from Claude Code, a task from Codex, a call to an MCP deployment tool, or an API request from an internal agent framework. The syntax is different every time. To the business it is the same action, with the same risk and the same people who should be able to approve it.
Today each runtime handles this its own way. One has a permission prompt, another a policy file, a third an audit log in its own format. An organization that uses four runtimes ends up building approval, authorization and audit four times, and evidence from one system cannot be checked in another. When the agent framework changes next quarter, the work starts again.
We think this is being solved at the wrong layer. If agents are going to act across many runtimes, the action itself needs a representation that does not belong to any one of them: a way to say what an action is, what it may affect, who may authorize it, within what bounds it can run, and what proof remains afterwards.
The existing protocols are good at what they were built for, and we rely on them. MCP connects agents to tools and data. A2A lets agents work with other agents. Identity and access management establishes who a person or workload is and what they can reach. None of them is designed to describe the consequences of a specific action, bind an approval to exactly that action, or prove afterwards that what ran was what was approved. That is the gap we are trying to fill.
This is why we think it should be a protocol rather than a feature. A feature makes one product better. A protocol lets governance stay the same when the model, the framework or the vendor changes.
The abstraction we're proposing
We call the protocol Ambit, after the word for the scope within which someone is allowed to act. It is built from five ideas, and each grew out of a piece of our research.
Action. One canonical identity for an action, whatever runtime it arrives from. A shell command, a tool call and an API request that do the same thing should resolve to the same object. This comes from our work on CAVA.
Effects. A description of what the action may do: which resource, which destination, how much, with what evidence, and what is still unknown. A description is not permission. It is an input to a decision, not the decision itself. This is Action Effect Spec.
Authority. Who holds final authority over the action, and how an approval binds to the exact action that will run, so that a later rewrite cannot slip past it. Our view is that this authority belongs to the organization that bears the consequences, not to the model provider. This comes from PCAA and our Final Authority paper.
Bounds. An approval is a lease, not a blank cheque. It is valid for one action, actor, session, destination, policy version and time window. This comes from our work on the Bounded Action Firewall.
Evidence. Every decision should close into a record that survives replay and audit. When the environment changes, some evidence can be reused and some must be checked again. Knowing which is still an open research problem, and it is the subject of Matoi.
Two more pieces sit alongside these: a fast path that approves ahead of dispatch and checks at the boundary, from ZeroGate, and a conformance suite that anyone can run, Action Effect Bench.
These parts are not equally mature, and we want to be exact about it. One layer is a published working draft today: Action Effect Spec, which has 28 core requirements and two consumers written separately in JavaScript and Python, tested by Action Effect Bench. Action, Authority, Bounds and evidence receipts come from our papers and already run in OSuite, but they are not yet public specifications. The status of every layer is listed at ond.cc/ambit, and we will keep that page current.
Why we built OSuite
Protocols that exist only on paper tend to stay there. We built OSuite, first of all, to prove that Ambit can run in real systems. Real runtimes, real latency budgets and real approvers find problems that a specification review never will.
Running it in production does three more things for the protocol. It lowers the barrier: most teams will not implement a governance protocol from a specification, and OSuite lets them use it now, where their agents already run: Claude, ChatGPT, Codex, Cursor, n8n and Dify. It makes the research reproducible: a running system gives our papers a place to run experiments that others can repeat. And it shows where the protocol is wrong: when something breaks in OSuite, the fix becomes a change to the protocol, not a private workaround.
This is also how we intend to sustain the work. The protocol defines a common language. OSuite turns it into infrastructure that an enterprise can deploy, manage and operate, and that is what we sell. To keep that relationship honest, we hold ourselves to one principle:
The protocol should not depend on OSuite. OSuite should depend on the protocol.
Some of this is true today. The specification is versioned separately from OSuite, it is MIT licensed, and the conformance tests run without an OSuite server or account. Some of it is a commitment: nothing in the protocol should require an OSuite API, and others should be free to build products on Ambit, including products that compete with ours. Open governance for the protocol is still a proposal.
How to take part
We are not announcing a standard. Standards are not declared by the people who write the first draft. They form when independent people implement a specification, test it, argue with it and keep using it. What we are doing is publishing a technical claim, together with the work we have done to test it, so that others can check it.
If you build agent runtimes, gateways or governance tools, there are four useful ways to take part:
- —Implement it. Emit and check effect descriptions in your own runtime.
- —Challenge it. Open an issue wherever the specification is wrong, vague or too narrow.
- —Test it. Run Action Effect Bench offline against your implementation.
- —Build without us. An implementation that never touches OSuite is the strongest test there is.
We think agent actions need a common representation that can be understood, authorized and verified across runtimes. Ambit is our attempt at one. If it proves useful, we hope others will adopt it, improve it and build on it. If it is wrong, we would rather hear it from you than learn it from a production incident.
The protocol overview is at ond.cc/ambit. The specification is at github.com/OndCo/Action-Effect-Spec, and the benchmark is at github.com/OndCo/Action-Effect-Bench.
