🪶 A note on how this was written. This article was co-authored with the support of Claude, Anthropic's AI assistant. It draws on the principles and documentation developed while building and running the real-world working examples it describes.

Parts 2 and 3 described what the platform and its evidence do on their own. The third principle is about who decides: what the agent may do alone, what it brings to me, and why some things always need two of us.

Manage the agent like a team member and maintain separation of duties

The key lesson I've learned is that none of this is new. Running an agent well takes the same skills as leading a team. In Effective Delegation I described Active Calibration: some decisions a team member owns and tells you about afterwards (Inform), some you work through together (Consult), and some are red lines they always bring to you (Escalate). The agent gets exactly the same treatment. Its instruction file is the "Empower" tactic from The Priority Matrix written down: guidelines and guardrails it can act on, and gates that trigger escalation. Its tests and checks are its definition of done. And briefing it well is Effective Business Writing by another name.

The question that decides each zone isn't "human in the loop or not?". It's: if the actor doing this alone were compromised, or simply wrong, what could it do? Where the answer is serious, a second, independent actor is required. That's separation of duties, with the agent as one of the actors. The FCA's review makes the same point from the other side: human review is a risk-based control, not a box to tick, and a reviewer without the authority, information and escalation route to challenge the output adds little.

Three zones, from least to most control. Inform, automation acts alone and reports after in one email: merge dependency updates by CVSS band after checks pass, promote them to production on the same clock, fix failing checks without skipping a test, regenerate compliance reports. Consult, the agent proposes and Andy approves before it happens: every other change arrives as a pull request that Andy merges, and production deploys only after Andy confirms staging. Escalate, human only, the agent stops and tells Andy: accept a risk with Andy's words quoted, deploy the account, audit and backup stacks by hand, change the agent's rules, CI, trust root or the update round, widen anyone's access. Underneath all three: only a human moves the line between zones.Three zones, from least to most control. Inform, automation acts alone and reports after in one email: merge dependency updates by CVSS band after checks pass, promote them to production on the same clock, fix failing checks without skipping a test, regenerate compliance reports. Consult, the agent proposes and Andy approves before it happens: every other change arrives as a pull request that Andy merges, and production deploys only after Andy confirms staging. Escalate, human only, the agent stops and tells Andy: accept a risk with Andy's words quoted, deploy the account, audit and backup stacks by hand, change the agent's rules, CI, trust root or the update round, widen anyone's access. Underneath all three: only a human moves the line between zones.
Nothing acts alone where it could change the rules.
  • Inform: the update round merges dependency updates on their clock once checks pass and sends one short report when anything changed; the agent fixes failing checks and regenerates the reports.
  • Consult: every other change arrives as a pull request that I merge, and production follows only once I've confirmed staging.
  • Escalate: only I accept a risk, and the record quotes my words. The account, audit and backup infrastructure is deployed by me, by hand. The automation refuses to merge anything that changes the agent's own rules, its CI, the trust root or the merge automation itself, or that widens anyone's access.

These aren't just habits. The roles the automation uses are fenced in by AWS permissions: they can deploy hosting, DNS and certificates, but they can't touch the audit trail, the account's own roles and policies, or the backups. Only I, signing in by hand, can change those.

Not every rule can be enforced that way. Some, such as when to stop and ask, can't be expressed as a permission, so they're instructions in the agent's file, and an agent can misread an instruction as a person can. Those rules rely on the checks and on a second actor to catch a mistake, which is why I turn an instruction into a permission wherever I can.

Two design points are worth drawing out. First, the rules that govern the agent can't be changed by the agent alone; otherwise the autonomous zone can widen itself. Second, recovery doesn't trust the actor it recovers from: a weekly backup goes to locked storage, written by a role that can only add to it, so a compromised source account can't erase it.

Never merge a change to your own rules, CI, access policies or the automation that merges for you; propose it, and stop for a person.

Rule for your agent, from the companion skill

Here the second actor is me. In an organisation it's a different person or team, which maps directly onto the four-eyes controls you already run. It also speaks to the gap I was quoted on in the State of AI in Security & Development 2026 report, the lack of clarity over who is accountable when AI-generated code causes an incident: every action has a named, accountable actor, and the agent is never the only one on anything that matters.

The trade-off: NoOps for the owner, not no operations

Someone builds and keeps the platform, the agent's runs cost money, and the two-actor checks take a person's time. I chose the schedules by weighing cost against benefit and may need to adjust them if real-world threats change.

In part 5 I bring the series together, with its limits and the companion Claude Code skill that lets your own agent work this way.