Governance in the Age of Agents

A few months ago, an agent working on our codebase picked up a task involving manifest path resolution. It investigated, found the relevant code, and proposed a plan. The plan was technically reasonable. It could easily have worked, the tests may have passed, and the PR would have looked fine. But it conflicted with an undocumented contract elsewhere in the system. The constraint was that the manifest we send must remain byte-for-byte what the author originally pushed. The agent's proposed dual-base lookup would have made the local behaviour work, but it risked breaking the scorer that relies on the manifest and archive layout agreeing. That constraint came from a product decision about trust, not a rule the agent could infer from the resolver alone.

We caught it during plan review, before any code existed. Working through that conflict changed the approach entirely. If we'd let the agent carry on, we'd have had a clean implementation of the wrong thing. And because the agent would have written the tests too, those tests would have confirmed the wrong thing. I wrote more about this in The Code Was Never the Job.

Governance can't assume that every consequential decision already exists in a document. Some of them live in people's understanding of why the system works the way it does. The remedy is both to catch those conflicts in review now and to encode them into the agent's context for future work.

That experience crystallised something for me. When a human engineer works on a task over a few days, assumptions surface naturally. They come up in standups, in conversations with someone who knows the history, in the friction of reading code someone else wrote. The team has moments where it notices when something is heading in the wrong direction.

Agents can compress or skip those moments. An assumption gets made, implemented, tested, and documented in one session. The code, the tests, and the docs all agree with each other, because the same process produced all of them. By the time a human sees the pull request, disagreeing with the approach means throwing away finished work. Most people won't do that, and I don't blame them.

The thing I've learned building Swamp is that you have to put those moments back deliberately. That's what governance means here: deciding which choices the agent can make alone, which need a human decision, and what evidence must exist before work can move forward. It isn't forms and approvals. It is specific points where assumptions get examined before they become code.

Three things worth protecting

I think about this as three protections, each aimed at a different failure mode.

Decision-making before implementation. A plan is where the important choices happen: which approach to take, what to change and what to leave alone, what assumptions to make when the requirements are ambiguous. The manifest path issue is a good example. The agent's plan was reasonable given what it could see, but it needed human judgment about context it didn't have. Not every plan needs deep scrutiny. A well-understood bug fix with a small blast radius is different from a change that touches shared contracts or reflects a product direction call. But the option to engage has to exist before the code does, because after the code exists, the plan is already baked into it.

Independent verification. When an agent implements code and then runs tests against it, passing doesn't tell you much if the agent also wrote or influenced the expectations. It can misunderstand a requirement, implement that misunderstanding, and produce a comprehensive test suite that confirms it. I covered this in Why Agent-Written Code Needs Product Verification. The verification that matters comes from outside the implementation. Expectations that existed before the agent started, and that the agent can't alter to make a failure go away.

Iteration provenance. When an agent hits a test failure, it adjusts the code and tries again. Sometimes it does this well. Sometimes it works around the problem rather than solving it. Softening a test, narrowing the scope of what's being checked, changing the implementation until the symptoms disappear. From the outside, all you see is a PR with passing tests. You have no way to reconstruct how it got there. The record of what the agent tried, what failed, and what changed between attempts can matter as much as the final commit.

These connect. A plan review that catches a bad assumption saves you from an implementation loop that would have buried it. Verification that's independent of the implementation makes the iteration record meaningful rather than circular.

What this looks like in practice

At Swamp, every piece of work goes through a lifecycle with defined states and enforced transitions. The agent can't skip a step, and every state change is recorded.

A task comes in. We check it, then the agent investigates the codebase, understands the context, and produces a plan. That plan goes through an adversarial review first, a separate check that looks for conflicts and risks, and then through human approval. If the approach needs to change, it changes before any code exists.

After approval, the agent implements. Verification runs as independent workflows, pinned to the exact commit being checked. If verification fails, the agent goes back to implementing and iterates. Every iteration is an audit entry: what failed, what changed, and the sequence of attempts that led to the final result.

Once verification passes, a conformance review compares the verified code against the approved plan. Each step is marked: implemented, deviated, partially implemented, missing, or added. Deviations are expected. Plans change during implementation for good reasons. But every deviation has to be justified before the work can move forward. The PR can't open until verification has passed, conformance is complete, every deviation is explained, and a verification attestation is posted.

I'm not describing this as a template for you to follow, it's what we built because we needed it. The specific gates reflect the kind of work we do: changes to a product that other people depend on, where a wrong assumption in shared infrastructure can compound quickly.

Maybe not everything needs every gate

A well-scoped bug fix with clear reproduction steps and a small blast radius may not need the same scrutiny as a change to a shared contract or a feature that reflects a product direction decision. How much governance you need depends on the ambiguity, the blast radius, whether it's reversible, and how much product or architectural judgment is involved and your own organisational process.

The plan review matters most when the task involves a judgment call where context, history, or product direction is relevant and not fully captured in the codebase. For straightforward work with low ambiguity, the plan review can be light. The point is that the option to engage exists at the right moment, not that every task gets the same treatment.

What shouldn't scale down is the record. Even for simple work, knowing what the agent tried, what verification looked like, and whether the output matched the intent is worth having. You don't always need to act on it, but you need it to be there when you do.

Speed is why this matters

Human engineers have always filled gaps in requirements and made assumptions when the spec was unclear. This isn't new but the speed at which an unexamined assumption becomes a finished feature is what we have had to adjust to.

A question that would have surfaced over a few days of development, in a standup or a pairing session or the moment where an engineer asks "wait, does this conflict with the thing we did last month?", can now be answered by the agent and built on before anyone else is involved. The agent isn't being careless, it's just doing what you asked and doesn't have enough context to know which assumptions are safe and which ones aren't.

Governance is the thing that reopens that window. The plan review catches assumptions before they're implemented. Verification catches an implementation that satisfies its own tests but not the product's actual expectations. The iteration record shows you how the agent reached the result. Without something like this, speed will carry a bad decision all the way to production.

I'd rather have those conversations before the work is done than discover the assumption after it's been shipped.

For every piece of code we ship at Swamp, I want to trace the chain of decisions that produced it: what was planned, what was challenged, what was independently verified, what the agent actually built, where it deviated, and why. That isn't a side effect of a cautious development loop, it's what governance gives you when you build it into the architecture instead of hoping the PR review will catch everything.