How I Keep AI Agents Accountable

I start with the workflow, not the agent count

I use one agent by default. I add another only when the work separates into independent questions or when a fresh review adds real value. Research across unrelated sources can run in parallel. Two changes to the same data model cannot. The shape of the work decides the team.

I draw the workflow as a short sequence. It starts with an approved plan, moves through isolated tasks, joins at one integration point, and ends with human validation. I mark every dependency before agents begin. This exposes false parallelism early. If one task needs the output of another, I keep them sequential.

This decision saves more time than any orchestration trick. A multi agent system adds handoffs, context boundaries, merge work, and new failure paths. I accept that cost only when the split removes a larger bottleneck.

I write a contract for every agent

A role name does not define responsibility. Researcher, developer, and reviewer all leave too much room. I give each agent a contract that states the outcome, inputs, allowed scope, tools, expected evidence, handoff target, and stop condition.

The contract describes what the agent must not do as clearly as what it should do. A source agent verifies claims but does not rewrite the article. An implementation agent edits named files but does not redesign adjacent features. A review agent inspects the result but does not silently repair it. Clear boundaries keep ownership visible.

I also define success in a form another person can check. The agent does not finish when it feels confident. It finishes when it returns the required files, tests, screenshots, links, or decisions. That turns completion from a sentence into a reviewable package.

I isolate work and permissions

One writable area gets one owner at a time. I separate coding work by real architecture boundaries and use isolated workspaces when two agents need to edit in parallel. The integration owner receives their changes after each task passes its own checks.

Tool access follows the same rule. A task that reads documentation does not need deployment access. A local code review does not need messaging tools. An agent that can inspect a repository does not automatically receive permission to edit every directory. I grant the narrowest access that completes the contract.

This matters inside my local AI setup too. A model can run on my machine while its tools still reach the network, terminal, memory, and external chat. I place the boundary around the full agent, not only the model endpoint.

I make every handoff small and complete

A handoff should answer six questions. What changed? What evidence passed? What failed? What decisions did the agent make? What remains open? What should the next agent read? I use the same order every time so I can scan several returns without decoding a new format.

The agent links each completion claim to evidence. A test log supports behavior covered by that test. A screenshot supports the visible state shown in the image. A source link supports one factual claim. No single artifact proves the whole task. I match the evidence to the claim and keep it short enough to inspect.

I record handoffs in the project rather than leaving them inside chat history. The next agent starts from a verified state, not a compressed memory of the previous conversation. This also lets me replace an agent without losing the reasoning that matters.

“As big as the step from source code to agents was, loops are just as important and as big a step.”

Boris Cherny, creator of Claude Code↗

I use fresh review, not agent voting

I separate implementation from review when the change carries enough risk. The reviewer receives the original contract, the diff, and the evidence. It does not inherit the implementation conversation. That fresh context helps it notice assumptions the first agent stopped questioning.

When agents disagree, I reduce both answers to claims, assumptions, and proof. A focused test settles technical behavior. Repository evidence settles an existing convention. A product tradeoff returns to me because no agent vote can decide what the product should value.

I also watch the reviewer. Review agents often praise structure, repeat the completion report, or approve tests they never ran. My review contract requires direct inspection and names the failure classes to search for. The reviewer must show where it looked and what would block approval.

I keep stop conditions and final approval human

Every run stops when its contract passes, its limit arrives, or a missing decision changes the work. I prefer a precise blocked handoff over an agent that invents a bridge. Endless loops waste time because they have no valid definition of done.

I place a human gate before deployment, publication, deletion, payment, permission changes, and any expansion of the approved scope. The agent must present the action, reason, affected system, evidence, and recovery path. Then I approve or reject it.

This is how I stay inside the loop without controlling every keystroke. Agents own bounded execution. I own the plan, the boundaries, the product decisions, and the final validation. My coding agent method explains how I connect those gates to phased implementation.

• Start with one agent and add only a justified role.
• Give every writable area one owner.
• Require evidence for each completion claim.
• Use a fresh reviewer for risky changes.
• Keep consequential actions behind human approval.