Which steps should get an agent, and which should not — yet.
Most agent design reviews ask one question: can the model do this step? That is the wrong question. How good the model is decides how much thinking you hand over. How hard an action is to undo decides how much authority you hand over. They are two separate limits and you have to set both.
4 undo levels · 5 questions per step · 3 worked examples · 40 minutes
The demo did both in one go. That is where the mistake hides.
Say an agent finds the cause of an outage in ninety seconds. That proves it is good at one thing: understanding the problem. It says nothing about whether it should be allowed to act on it.
Teams mix up the two because the demo did both at once. The mistake stays hidden until the first action that cannot be undone.
Give every action a level before you decide who owns the step.
Read a log. Add a few servers. Draft a message. Produce a list of possible causes.
Turn a config flag off. Put a job back in the queue. Restart a pod. Revert a small, clean commit.
Roll back a deploy that changed data. A support message already sent. An alert that was never raised.
A payment sent. A database migration run. A record deleted. A public API released. Something a customer has already been told.
The line you are drawing is almost always between R1 and R2. Above that line, the agent only suggests. Below it, the agent can act.
For every single step. Not for the workflow as a whole.
Evidence
What must be true before this step runs? And can I confirm it was actually checked, not guessed? If the input was invented earlier, the policy check later will still pass. That check is then only for show.
Judgment
Is there one right answer, or can two good engineers disagree? If they can disagree, you need an eval set. If they cannot, you need a rule in code, not a model.
Hard limit
What must not bend here, however good the explanation sounds? Write it as a fixed check in code, placed where no argument can go around it.
Undo cost
If this step acts wrongly, is it R0, R1, R2 or R3?
Repeat
If this step runs a second time because we never learnt the result of the first run, what happens? In production, the second action usually does more damage than the first.
One row per step. Fill Evidence and Undo cost first.
Before you form any opinion about owners. Print this page to take the blank table into a room.
| Step | Evidence needed | Who decides (code / model / human) | What it may do | What happens if evidence is missing | Undo cost |
|---|---|---|---|---|---|
Only after the table is full, never while you are filling it.
A rule is cheaper, faster and easier to audit. Do not spend a model on a check that a simple condition can do. Most rows will land here. That is a good result, not a disappointing one.
This is where an agent is actually worth it: real judgment needed, and cheap to be wrong. Build the eval set before you build the agent.
"Not yet" means until you have a log of real production failures. It does not mean until the demo looks good.
Handling repeats is not a phase-two item. It is the difference between one failover and two.
Incident triage and fixing
| Step | Evidence needed | Who decides | What it may do | If evidence is missing | Undo |
|---|---|---|---|---|---|
| Collect signals | Deploy log, alerts, health of dependencies, service owner list | Code | Read only | Say which signal is missing and lower the confidence. Do not fill the gap. | R0 |
| Line up the timeline | Deploy and alert timestamps that were actually read | Code | Give a likely time window | Widen the window. Never narrow it on partial data. | R0 |
| Rank possible causes | The signals above, with evidence attached to each cause | Model | A ranked list, each item showing its evidence, plus a clear "not enough evidence" option | Return "not enough evidence" as a proper answer | R0 |
| Decide whether to page someone | Severity rules, owner, customer impact signal | Human (rule in code) | The agent may ask for a page. It may not stop one. | Page by default | R2 |
| Suggest a fix | The chosen cause, what it will affect, and the command to reverse it | Model | Write the plan, including how to undo it | Refuse to suggest an action that has no known way back | R0 |
| Act: add capacity or fail over inside a tier | Plan approved, run ID created, earlier run checked | Model / Code | Act | Do not act when the earlier state is unknown. Check first. | R1 |
| Act: roll back a deploy with a migration, change a Tier-0 service, or act during a freeze | All of the above, plus a human approval | Human | Agent prepares the command. Human runs it. | Escalate | R3 |
| Confirm and close | Signals recovered and stayed recovered for a fixed period | Code + Human | Confirm | Keep the incident open. Never close it just because alerts stopped. | R1 |
Where I would say no agent, not yet — and why
Stopping a page. This is the only decision here that gives you no feedback. If the agent pages too often, everyone notices. If it wrongly decides not to page, nobody ever finds out. You cannot build an eval set from outcomes you never saw. So until you can measure the misses, the agent only suggests and the rule decides.
Any action above R1. The risk is not an agent that thinks badly. It is an agent that thinks well about the cause, then runs an action whose side effects were never part of what it looked at. "Roll back the deploy" sounds like one action. A rollback that also reverses a database migration is a completely different action with the same name.
Refunds and goodwill credit
| Step | Evidence needed | Who decides | What it may do | If evidence is missing | Undo |
|---|---|---|---|---|---|
| Check the order, the payment status and past refunds | Order system and ledger, read directly | Code | Read only | Stop. No refund on an unconfirmed state. | R0 |
| Understand what the customer is saying | Chat or call transcript, order history | Model | Summarise the complaint, and clearly separate what the customer claims from what we have confirmed | Mark it as unconfirmed and carry on. A believable story is not proof. | R0 |
| Check refund policy | The policy version that applied on the purchase date | Code | Pass or fail | Not eligible means no refund | R0 |
| Decide the amount, within a set band | Eligibility, customer tier, earlier credits given | Model under a hard cap | Suggest an amount inside the band | Suggest the lowest amount and flag for review | R3 |
| Decide an amount above the band, or any exception to policy | All of the above | Human | Agent writes the reasoning. Human decides. | Escalate | R3 |
| Send the refund | Approved amount, plus a unique key made from order ID and reason code | Code | Send once | Never send when the earlier attempt's result is unknown. Check first, then act. | R3 |
| Record what was decided | Decision, amount, reason code | Code + weekly human review | Log it | — | R1 |
Where I would say no agent, not yet — and why
Amounts above the band. An agent that is rewarded for closing tickets quickly will learn to give money away to make complaints go away. You will not see this in the transcript, which reads very well. You will see it in next quarter’s refund numbers. This is not a guardrail problem. It is a problem with what you asked the agent to optimise for, and better prompts will not fix it.
Exceptions to policy. The eligibility check is the one thing here that must not bend. The moment a good enough story can create an exception, the policy has stopped being a control and become a suggestion.
The record step. Most teams skip it. Every goodwill refund teaches customers what to ask for next time. This is the row that adds up over months.
Automatic pull request merge
| Step | Evidence needed | Who decides | What it may do | If evidence is missing | Undo |
|---|---|---|---|---|---|
| Run CI, tests and static analysis | Green build on the merge commit, not on the branch head | Code | Pass or fail | Fail closed | R0 |
| Compare what the code does with what the PR says it does | The diff, the description, the linked ticket | Model | Flag it when the two do not match | Flag as "cannot review" | R0 |
| Check owners and approvals | CODEOWNERS file, approval records | Code | Pass or fail | Fail closed | R0 |
| Merge a low-risk change | No migration, no auth or payment code, no public API change, and the revert is one clean commit | Model / Code | Merge | Do not merge. Ask for a review. | R1 |
| Merge anything touching auth, payments, migrations or a public API | All of the above | Human | Agent prepares and summarises. Human merges. | Escalate | R3 |
| Trigger the deploy | Merge done, deploy window open | A separate decision, with its own owner | — | — | R2–R3 |
Where I would say no agent, not yet — and why
Anything touching auth, payments, migrations or a public API. Once a migration has run or an API is public, undoing it is not the reverse of doing it. Also, judging whether the code matches the description is exactly the task where models sound most confident and are most often wrong. Both the description and the diff read well on their own. The gap between them is the bug.
The deploy trigger. Keep it as its own row with its own owner. Teams that merge and deploy in one step have given away deploy authority without ever discussing it. This is the most common accidental handover I see, and it never shows up in an architecture diagram, because it lives in a CI config file.
Pick the workflow you are most tired of.
One workflow or runbook that you own. Not the most interesting one.
- List the steps. Decide nothing.
Do not assign owners yet. Your first guess will be wrong and it will bias everything after it.
- Fill only two columns: Evidence and Undo cost.
Every row, before anyone says the word "agent".
- Mark the rows where two good engineers could disagree.
Judgment is the axis that decides whether a model belongs here at all.
- Apply the reading rules.
Only now. Applying them while you fill the table is how the table ends up agreeing with whatever you already thought.
- Circle every row where you cannot answer question 5.
Those are the rows that turn one failover into two.
What you will usually find: fewer agent rows than you expected, several rows that should have been plain code all along, and at least one action that cannot be undone and has never had a named owner.
That last one is worth the forty minutes on its own.
This tells you where an agent belongs. Not whether yours works.
For every row where two engineers could disagree, you now need an eval set. Writing evals for those cases is a different skill from the assertion tests you already know, and it is the skill that separates a demo from something you can leave running.
The Living Craft runs a 6-week cohort on exactly this: building agents for decisions where the right answer is genuinely debatable, and building the evals that show they hold up. 8 seats, by application only, for Staff+ engineers, engineering managers and architects who ship to production.
See the cohort → All resources →
Published 14 September 2026 · free to use and to pass on