Designing an agent operating model
An agent operating model sounds like it should be mostly agents. It isn’t. The reliable ones are mostly deterministic software (retrieval, checks, tests, release mechanics that run identically every time), with model steps placed only where judgment earns its keep. That is how production agents actually work (12-factor agents: small, focused agents inside control flow you own). And one rule sits above the whole design: no capability ships without a baseline. If you never measured the process before the agent, you cannot claim the agent improved it.
The other pages in this track are components: enforcement, memory, verification, routing. This page is the assembly, how they combine into a system a team can actually run.
The decision loop
Section titled “The decision loop”Every change an agent makes to something that matters (code, a document, configuration, customer-facing content) should travel the same road. One loop, not one process per tool, with each step assigned to whatever does that step best.
- Retrieve context deterministic
- Author model
- Automated checks deterministic
- Test deterministic
- Review model, then human
- Human gate human, never optional
- Release deterministic
- Inform deterministic
↺Every change travels the same road. Two of eight steps are model work, and only one writes.
- Retrieve context (deterministic). The agent gets the relevant files, standing instructions, and the task definition by lookup. What goes into the window is a decision, not an accident.
- Author (model). The one step where judgment is the point. The agent drafts the change inside the context it was handed.
- Automated checks (deterministic). Lint, formatting, policy rules. Anything that can be checked by a script must be; a rule that only a model reads is a wish.
- Test (deterministic). The suite runs, every time, regardless of how confident the draft sounds.
- Review (model, then human). A fresh model with no stake in the draft gives a second opinion; a human reads what matters.
- Human gate (human). A person approves the change and owns it as if they had written it by hand. This step is never delegated and never optional.
- Release (deterministic). The same release mechanics you’d trust for human work, with no special agent side-door.
- Inform (deterministic). The change notifies whoever depends on it: the ticket, the changelog, the team.
Count the model steps: two of eight, and only one of them writes. Everything around the judgment is machinery, which is why the judgment can be trusted. The loop is boring on purpose; boring is what makes it a system instead of a demo.
No baseline, no proof
Section titled “No baseline, no proof”The most common failure in agent adoption is an unmeasured agent, not a bad one. A team ships a capability, feels faster, and reports improvement it cannot demonstrate. The feeling might even be right. It still isn’t proof.
The best-known field evidence exists precisely because someone measured first: a study of generative AI in customer support found +14% productivity on average, and +34% for novice workers, measured against a pre-deployment baseline (NBER working paper 31161). No baseline, no such sentence. That’s the ladder your operating model climbs:
| Rung | You have | You can honestly claim |
|---|---|---|
| 1. Ad hoc | Individuals prompting on their own; nothing shared | Anecdotes |
| 2. Documented | A written loop and standing instructions, under version control | Repeatability |
| 3. Baselined | Pre-agent numbers: throughput, defect rate, review load | A starting line |
| 4. Measured | The same numbers after each capability ships | Improvement, with evidence |
| 5. Compounding | A baseline gates every new capability, by rule | A system that gets better on purpose |
Sequence by risk, not by excitement
Section titled “Sequence by risk, not by excitement”The instinct is to automate the most painful task first. Resist it. The most painful task is usually also the riskiest, and a failure there costs more than the automation: it costs the team’s trust in the whole programme.
Ship the lowest-risk capability first. An agent that drafts release notes can be wrong cheaply; someone reads the draft, fixes it, moves on. An agent that touches production configuration cannot. Start where errors are cheap and visible, prove the loop end to end, and let each safely shipped capability buy patience for the next. The riskiest agent ships last, onto a road the safer ones already paved: checks tuned, baselines in place, the human gate exercised until it’s routine.
Trust compounds the same way the baselines do. A team that has watched five small capabilities ship cleanly will give the sixth an honest trial. A team burned by an ambitious first launch will quietly route around everything that follows.
AI amplifies the system it lands in
Section titled “AI amplifies the system it lands in”AI amplifies the system it lands in rather than substituting for it. That is machtsinn’s core thesis, and the conclusion this whole operating model is built around. AI speeds up whatever you point it at and has no opinion about direction. It echoes what Google’s DORA research program has found for years about tooling in general: capability compounds where the fundamentals are already strong. Drop an agent into a team with clean tests, fast review, and working release mechanics, and it compounds those strengths. Drop the same agent into a messy process and it compounds the mess, faster and at scale. A bad process at machine speed is still a bad process; it just produces more of itself per hour.
This is why the loop, the ladder, and the sequencing come before the agents. The operating model isn’t overhead on the way to the interesting part; it is the interesting part. The teams that win with AI built something worth amplifying, then amplified it.
The rest of the track
Section titled “The rest of the track”Each step of the loop has a page of its own: