Governing Autonomous Agents

I run a multi-agent engineering operation every day. Not as an experiment — as how the work actually gets done. A coordinated set of agents plans, writes, tests, and ships code across a portfolio of products, mostly without me sitting over anyone's shoulder. That arrangement only holds up if it's governed. An agent with write access to a codebase and no accountability structure around it isn't leverage — it's a liability waiting for a bad day. Over the past several months I've been codifying the instruments that make autonomous engineering trustworthy enough to run daily, and I want to lay out the three that matter most.

Objective Contracts

The first problem I kept hitting was self-grading: an agent that builds a feature is not the right judge of whether it actually works. It's invested in the answer being yes. So the rule I settled on is structural, not aspirational — the agent that builds a piece of work never grades its own work. That rule gets enforced through what I call an Objective Contract, a five-part specification attached to any nontrivial task before an agent starts:

• the goal, stated as an outcome, not a task list
• the acceptance criteria, specific enough that "done" is never a judgment call
• the evidence required to prove those criteria were met
• the reviewer — a separate agent or process, never the builder
• the fallback for when the contract can't be satisfied as written

Five parts, every time. The discipline isn't in any one field — it's in refusing to leave the reviewer field blank, which is the one an agent (or a person, for that matter) is most tempted to skip when the deadline is close.

Standing Orders

The second problem was recurring work running quietly out of sight. A one-off task is easy to reason about — you can watch it happen. A nightly sync or a scheduled cleanup script is a different animal: it runs when nobody's looking, on and on, until something finally surfaces that it needs attention. I don't let any of that exist informally anymore. Every recurring job is declared as a Standing Order — a named, versioned document that states its trigger, its autonomy level, and its stop conditions before it ever goes live. Each one is gated: it has to clear an explicit checklist before it's allowed to run unattended, and that gate fails closed, not open, whenever the checklist doesn't clear. Every Standing Order also carries a kill switch that any of us can throw without first needing to understand the job's internals. The order matters here — build the kill switch before the automation ships, not after you discover you needed one.

Agent Charters

The third instrument covers the agents themselves, not the work. A recurring, standing agent — one that shows up across sessions with real authority, whether that's write access, spending authority, or the ability to act without a human approving each step — needs the same kind of accountability a person in that role would need. An Agent Charter answers four questions for exactly that kind of agent: who acted, under what authority, at what cost, and with what evidence. No charter, no standing authority — a new agent starts scoped down until one exists. It's the same instinct behind the Objective Contract's reviewer split, applied to identity instead of task: the record of what an agent did has to live somewhere that agent doesn't control.

Naming, deliberately

One smaller discipline runs through all three: names are original and collision-checked before anything ships under them. It sounds like a footnote, but it isn't — a governance document that shares a name with something else invites exactly the kind of ambiguity governance exists to remove. Every instrument here was checked against prior art before it got its name.

What's public

I've published the specifications behind all three as open documents:

None of this is theoretical. It's the operating layer under a real, daily multi-agent practice, refined because the problems above happened to me first and I had to close them before they could happen again. If you're running agents with real authority — write access, budget, the ability to act unsupervised — and you don't have something like these three in place yet, that's the gap I'd close first.

I wrote a longer, more technical edition of this piece on the RAYFINITE blog: rayfinite.com/blog/governing-autonomous-agents.