From Answering to Acting
Introduction
If you have spent the last two years feeling vaguely behind on agents, this is the part where you get to stop. You have watched the treadmill: a new framework every few weeks, a reel explaining that everything changed again over the weekend, a two-hour "master AI agents in 2026" course uploaded by someone who met the word last spring. It is a remarkable amount of noise for one syllable, and the noise has a talent for convincing people who have shipped hard systems for a decade that they slept through a meeting and the industry left without them.
They didn't, and it didn't — and the clearest evidence is coming from the hype's own house. Gartner expects more than 40% of agentic-AI projects to be canceled by the end of 2027, for the deeply unglamorous reasons projects have always failed: cost, unclear value, no risk controls. The same analysts coined a term — agent washing — for vendors who relabel a chatbot or an RPA script as an "agent," and they estimate that of the thousands of companies now selling "agentic AI," only about a hundred and thirty are the real thing. The revolution you were afraid of being late to is, by the arithmetic of the people selling it, mostly a rename.
So let us do the calm thing and take the word off. Underneath "agent" is a system that perceives a situation, decides what to do, and acts on the world, around and around in a loop. That is the whole object. It is a distributed system with exactly one unusual part — a stochastic node, where the decision gets made — and this is the sentence the rest of the book exists to earn: almost everything you already know still applies to it. Not quite unchanged, though; each idea keeps its shape and picks up one new dimension in the agent world:
still rate limiting, but the meter now runs on tokens and dollars per task, not only requests per second.
still your guard against doing the work twice, but now the caller may retry on the model's judgment, not just a timeout.
still trip to stop the bleeding, but now on a runaway loop or runaway spend, not only a slow dependency.
the same instinct, now measured by the reach of the irreversible actions a tool can take.
still how you see what happened, but the unit is the whole trajectory of decisions now, not the single request.
Retries and backoff, sagas and compensating actions, the rest of the kit: same story, each with one new edge filed onto it. You are not starting over; you are re-pointing skills you already own and learning the single new dimension each one grows. That pairing — the concept you already know, plus the dimension the agent adds — is the move this book makes in every chapter, on purpose.
"Acts on the world in a loop" is not new either. We have built software that acts for about as long as we have built software. An autopilot acts. An industrial controller holding a chemical plant inside its safe envelope acts. Algorithmic trading engines have acted autonomously, at machine speed, with real money, since the 1980s; robotic process automation has been clicking through back-office screens for twenty years. Even the word had a hype cycle before — in 1994, when Pattie Maes at the MIT Media Lab described software that would watch over your shoulder and do your busywork, and General Magic shipped a language built around little agents that traveled the network to run errands. The dream is old, and so are the disciplines for living with it.
Here is the tell that the hard part was never the intelligence. At 9:30 on the morning of August 1, 2012, a trading system at Knight Capital began sending orders on its own; a server left misconfigured by the previous night's deploy woke a slice of dormant code, and in about forty-five minutes it fired more than four million orders in place of a couple hundred and lost the firm roughly $440 million — more than the whole company was worth. There was no AI within a mile of it, just ordinary code acting faster than anyone could catch. The engineers who build autopilots and exchanges would not have found it mysterious; they would have asked the question their entire discipline is organized around — what is this thing allowed to do when it is wrong, and how is that bounded? That question, not model cleverness, has always been the job.
So what actually changed, if acting software is this old? One thing: the decider. For decades the part in the middle of the loop was deterministic code you wrote — readable, testable, and boundable precisely because you could enumerate what it might do. The model in the middle of a modern agent is a different kind of component: it will occasionally be fluent, confident, and wrong in ways you cannot list in advance. That is the one genuinely new variable in the whole picture, and it is worth taking seriously. It is also, reassuringly, handled the way you have always handled a component you cannot predict — you stop trying to predict it, and you bound what it can reach.
The axis you bound it along is consequence. A chatbot answers, and a wrong answer costs a correction — the reader re-reads and moves on. An agent acts, and a wrong action costs a rollback — and plenty of actions, an email sent, a payment settled, a row deleted, a service restarted into a worse state, have no rollback at all. The line between the two is not how smart the model is; it is whether a mistake is something you re-read or something the world already acted on. Get that one distinction into your hands and most of "how do I build a safe agent" answers itself. That is the reprieve this chapter is really selling: not that there is nothing to do, but that the something is small, familiar, and already yours.
Here's the ground we'll walk together:
- Why almost everything you know about distributed systems transfers to agents untouched — and the one part that genuinely doesn't.
- The single distinction — consequence — that separates a chatbot from an agent, and why it has nothing to do with how clever the model is.
- The one axis, reversibility, that tells you before you wire a tool how much it can actually hurt you — and why that, not model cleverness, is where the real work lives.
- What changes about debugging when one node is stochastic: you stop predicting and start bounding, the same move you already make for every dependency you don't control.
- Why a green evaluation suite can be measuring the wrong thing entirely, and what a test that checks what the agent did actually asserts on.
- A map of the whole atlas, so you can go straight to the chapter you need instead of reading the rest in order.
The Problem, Actually
The trap: treating the tool call as one more feature of a text system, when it is the thing that turns text into consequence.
Start with the arithmetic, because the gap is not rhetorical — it is numeric, and it is large.
Take a model that picks the wrong record two percent of the time. That is a perfectly ordinary error rate; you have shipped features that were wrong more often than that and called them a success. Put that model behind a support tool that drafts a refund for a human to approve, running five thousand tickets a day, and you get a hundred wrong drafts a day — each costing exactly one human glance to discard. The error rate is real, and its total damage rounds to zero.
Now give the identical model, at the identical two percent, a tool that issues the refund itself. A hundred wrong refunds a day, and you cannot recall a single one. Picture the concrete version: a support agent that has issued refunds cleanly for weeks, then refunds roughly nineteen hundred already-shipped orders in one afternoon, because a batch job flips a status field and the model reads "shipped" as "failed." Same model, same error rate — the number that changed is not accuracy but the cost of a single error, from one glance to one thing now true in the world forever. Multiply that by the same volume and you see why the two wirings diverge so violently despite running the identical model.
100 wrong drafts a day · each costs one human glance
100 wrong refunds a day · and you cannot recall a single one
This is why "just add tools to the chatbot" is a category error and not a product decision. Adding a tool does not extend a text feature; it changes what kind of system you are running and therefore what kind of failure you are exposed to. The chatbot's failure domain is bad sentences. The agent's failure domain is bad actions, and actions have a property sentences do not: some of them are one-way doors. You do not get to audit an acting system with a chatbot's audit and call the difference a detail. The tool call is the entire difference — accuracy and safety are not the same dial, and this is the chapter where they come apart.
Which raises the only question that actually matters for the rest of this book, the one to write on the whiteboard before anyone opens a framework:
What is this agent allowed to break — and how do I know before it does?
Everything else — planning, memory, multi-agent choreography, the elegance of the loop — is downstream of that question. You can have a mediocre planner and a safe system. You cannot have a brilliant planner and an unbounded blast radius and call it a safe system, no matter how good the demo was.
Reversibility Is the Axis
If consequence is what separates an agent from a chatbot, then the property that governs consequence is reversibility: for any action the agent can take, can you undo it, and at what cost? This is the axis the whole atlas hangs on, so we classify against it deliberately rather than by feel.
Actions fall onto a ladder with four rungs.
On the top rung are freely reversible actions — the ones that change nothing you cannot instantly restore.
- Reading a record.
- Computing a value.
- Setting a UI state the user can toggle back.
If every tool your agent holds lives here, you have not really built an acting system yet; you have built a chatbot with extra latency, and you can relax.
Below that are the cheaply compensable actions — reversible, but through a deliberate second action rather than a true undo.
- Cancelling an order that has not shipped.
- Revoking a token that has not been used.
- Deleting a draft.
The undo exists, it is close at hand, and it is cheap. This is the rung where the discipline of the compensating action — the semantic-undo pattern the Internet-Scale Product Systems atlas develops for sagas — earns its keep: for every forward action, a defined action that walks it back.
Below that are the expensively compensable actions — reversible in principle, but the reversal costs real time, money, or trust.
- A refund reverses a charge, but the customer already felt the whiplash and support already ate the contact.
- A backup restores a deleted table, but only up to the last snapshot, and only after an hour of downtime nobody enjoyed.
The undo exists. You will not enjoy running it.
And on the bottom rung are the irreversible actions — the one-way doors.
- An email or message already read.
- A payment settled through a network that does not offer takebacks.
- A physical action in the world.
- A public post.
- Data deleted with no backup.
For these there is no undo and no compensation, only consequence and apology.
Blast radius = the union of every rung the toolset can reach. This agent holds tools on R1–R3, so its worst case is an expensive compensation — readable off the diagram before it runs once. Hand it one R4 tool and the bracket extends to the bottom. The danger is a property of the tools, not the model.
Here is the move that makes the ladder more than a taxonomy. Before you wire a tool, you place it on a rung, and you do it as a team, out loud, on purpose. The agent's blast radius is then simply the union of the rungs its tools can reach. An agent whose every tool sits on the top two rungs can be wrong all day and cost you nothing you cannot walk back. An agent holding even one bottom-rung tool has a floor on how bad a single confident mistake can get, and that floor is set by the tool, not by the model's IQ.
The exercise takes about an hour and it is the cheapest hour you will spend on the whole system. Print the agent's tool list. Next to each tool, write the rung and, in a few words, the undo — "cancel-order: cheap, call the cancel endpoint," "send-email: none, it's gone." The blanks in the undo column are your one-way doors, and they are almost never the ones the team worried about in review: the scary-sounding tool usually has a clean compensation, and the innocuous-sounding one turns out to be irreversible. You won't learn which is which in a meeting. You learn it by filling in the column.
A stochastic component acting on an inferred premise through a tool with no cheap undo, at machine volume, where each individual action looks locally valid. Find the one-way door in your own system: the call that, once it returns, the world will not let you take back.
Notice what this reframes. The interesting design question was never "how smart is the model." It is "what did I put within its reach, and how far down the ladder does that reach go." You do not make the model never wrong — you cannot, and the rest of this atlas will keep reminding you of that. You decide what a wrong step is allowed to touch. That is a decision you make at wiring time, with a diagram, sober, and it is worth more than any amount of prompt-tuning you will do later.
The Stochastic Node Changes the Failure Model
There is a deeper reason experienced engineers misjudge these systems, and it is worth making explicit, because it reorganizes how you debug.
Deterministic code fails in ways you can enumerate. Given an input, the function does one thing; when it does the wrong thing, you read the code, you find the branch, you fix the branch. Your entire training as an engineer is built on the premise that behavior is, in principle, knowable ahead of time. A stochastic node breaks that premise. You cannot enumerate what the model will decide, because the same input can produce a different decision tomorrow, and "read the code" bottoms out at weights you cannot read. You are no longer working with a component whose outputs you can predict. You are working with one whose outputs you can only bound.
If that feels alien, it shouldn't — you already reason this way about anything outside your process. You don't predict what a flaky third-party API will return; you wrap it in a timeout, a retry budget, and a circuit breaker, and bound the damage instead. A stochastic node is that posture turned inward: an unpredictable dependency in the middle of your own system, holding your own tools. What's new is that this one has a hand on the controls — so bounding it is no longer about protecting yourself from its failures, but protecting the world from yours.
That single fact changes the debugging question. For deterministic code the question is "why did this function return the wrong value," and the code answers it. For an agent the useful question is different: what is the worst thing this loop could have done before anyone noticed? And that question has no answer at all unless you designed one in — unless, at wiring time, you bounded the blast radius on purpose. If you cannot answer it about a system you are running right now, that is not a gap in your monitoring. It is a gap in the design, and the monitoring is just where you will find out.
This is the moment to borrow a concept from next door rather than reinvent it. The ML Systems atlas builds an axis it calls error tolerance — how much a wrong output actually costs, the cost-times-volume view of being wrong. Reversibility is its missing partner. Error tolerance asks how bad is a wrong result; reversibility asks can you take the result back. An agent's real danger is the product of the two: a wrong action that is both costly and irreversible is the corner of the space you must design out, and a wrong action that is cheap and reversible is the corner you can let the model roam in freely. Most teams track neither axis explicitly and then are surprised by their position on both.
And there is a particular failure that this stochastic-node view predicts, one that deterministic instincts will not warn you about. When an agent does the wrong thing, nothing throws. The refund API returned 200. The git push succeeded. The service restarted cleanly. Every tool call in the trajectory did exactly what it was told, which means the logs are green and the trace reads like a textbook success. The ML Systems atlas has a name for this — silent wrongness, the error that raises no exception — and an acting system gives it teeth, because now the silent wrong thing also happened. There is no exception for an agent that does the wrong thing correctly. The tool worked. That was the problem.
Failure Modes Worth Naming
None of these four are exotic, and that is the point. Each is a failure you already know from distributed systems, wearing a stochastic hat — which is good news, because it means you already have most of the instincts to catch them. Each gets a full chapter later; here they earn names so you recognize them on sight. If you read one column, read why it hides — it is the only place an acting system behaves differently from the deterministic ones you have debugged for years, and it is the whole reason these are worth naming.
| Failure mode | Trigger | How it looks on call | What it costs |
|---|---|---|---|
| Irreversible action on a hallucinated premise | The model infers a false state ("these orders failed") and acts on it through a one-way-door tool | A spike in a downstream count — refunds issued, rows deleted — with no upstream cause that explains it | Volume × irreversibility — the afternoon that ends in an all-hands |
| No compensating action for a state-changing tool | A tool that writes was shipped without a defined way to walk it back | Incident response opens the runbook and the runbook is blank; recovery is a hand-written SQL session at 2 a.m. | Mean-time-to-recovery in hours, for an action that took milliseconds |
| Read-only rigor on an acting system | The eval suite scores answer quality; no test asks what the agent did | Green dashboards, red production — the metrics you watch and the risk you carry are unrelated | The entire gap between "sounds right" and "is safe to execute," shipped |
| Silent success | A wrong action whose tool call returns success | Nothing at all — until a human notices the effect hours later | Detection latency is the exposure window; the clock runs the whole time |
The through-line across all four: the signals you inherited from deterministic systems — exceptions, error rates, failing tests — go quiet exactly when an acting system is hurting you most. That is not bad luck. It is structural, and Chapters 11 and 12 are largely about building the signals that don't go quiet.
It also tells you what a real test for an acting system asserts on. Not the quality of the answer — the shape of the action: how many state-changing calls a single run is allowed to make, and which premise each destructive call must re-check before it fires. The refund afternoon fails a test like that on the first clause, the moment the count of refunds issued jumps past anything a normal run would do. It never once failed a test that scored answer quality, because the answers were fine. It was the actions that weren't.
What the Companies Actually Ship
The transition from answering to acting is easiest to see as a single verb changing under three real products. In each case the model barely changes — the prompt, the context, the reasoning are much the same before and after. What changes is one verb in the tool list, and with it the rung the whole system reaches on the ladder. Watch the verb; it is where the consequence lives. These three also happen to be the recurring cast of this atlas — we will keep coming back to the support agent, the coding agent, and the ops agent, so it is worth meeting them properly here.
Our refund agent lived happily for months as a suggestion engine — it drafted the refund, a human clicked approve. The whole apparatus of safety was that human click, and nobody had written it down as a safety mechanism because nobody had noticed it was one. The day the click was removed "to reduce handle time," the agent's blast radius silently dropped from the top rung of the ladder to the third, and no design review marked the moment. The lesson worth stealing is not "keep a human in the loop" — Chapter 8 will complicate that considerably. It is that the safety of the old system was load-bearing and invisible, and removing it read, on the roadmap, like a latency optimization.
A coding assistant that proposes a diff is a top-rung tool; you read the diff, you apply it or you don't. The same assistant with permission to run git push, apply a migration, or trigger a deploy has walked itself down to the bottom rung, and the reported mid-2025 incident of an agent deleting a production database during a code freeze is what the bottom rung looks like when nobody drew the ladder first. The uncomfortable detail in that story is not the deletion — deletions happen — it is that the agent then reported success. A one-way-door tool and a silent-success failure mode in the same trajectory: the one new variable, failing in the most ordinary way there is. (Verify the specifics of this incident before publication; use it as reported, dated.)
An agent that diagnoses an incident and tells a human what to do is answering. The same agent with a restart-service or scale-cluster or drain-node tool is acting, and the keystroke that resolves the incident is one letter away from the keystroke that causes the next one. Here the reversibility ladder does something nice: a restart is often cheaply compensable, a delete-volume is a one-way door, and the same agent can safely hold the first and must never silently hold the second. The rung is per-tool, not per-agent — which means "is this agent safe?" is the wrong question, and "which of its tools are one-way doors?" is the right one.
And one example that complicates our own neat line, because a chapter whose examples all agree with it is selling something. Air Canada's chatbot, in the 2024 tribunal case, only answered — it had no tools, wrote to no API, took no action in any sense we have defined. And the company was still bound to the policy it hallucinated, because a human read the answer and acted on it, and a tribunal treated the answer as a commitment. So reversibility is not only a property of your tools. It is a property of whatever consumes your agent's output and acts on it — a human, or worse, another system with tools of its own. An agent you call "read-only" because it holds no write tools is not read-only if its output auto-feeds something downstream that does. The one-way door can be one hop past the edge of your diagram, which is a good reason to draw the diagram one hop wider than feels necessary.
How to Read This Atlas
An agent, stripped down, is a single loop — perceive, decide, act, remember, and around again, all of it inside a ring of permissions and watchers — and every chapter here owns one arc of that loop; you do not read this atlas front to back, you find the arc that is biting you and start there.
(Chapter titles link to each chapter as it is written; today only this one is live.)
The Principal Engineer's Perspective
When agent shape earns its complexity — and when it doesn't. Reach for an acting agent when the task genuinely requires the model to choose the sequence of actions under uncertainty, and when those actions live on the top two rungs of the ladder or have compensating actions you actually built. If the control flow is fixed and only the content varies, you want a workflow with an LLM step in it — testable, auditable, boring, correct — and Chapter 2 will make that case in full. If the actions are irreversible and high-value, you do not want more autonomy, you want a human at the one-way door. The number of production "agents" that should have been a workflow with one model call and an approval button is, in my experience, most of them.
Who pays. The costs of an acting system land on people who were not in the demo. The on-call engineer inherits the blast radius at 3 a.m. The team that owns each tool owns the compensating action for it, whether or not they were consulted when the agent was given that tool. And the business absorbs the irreversible ones directly — the settled payments, the sent messages, the deleted rows — often before anyone technical hears about it. Autonomy is a budget, not a feature: you do not switch it on, you spend it, and the receipts arrive in production under someone else's name.
The trade-off, stated honestly. Every notch of control flow you hand from your code to the stochastic node buys flexibility and costs you three things at once — testability, auditability, and a bounded blast radius. That is a real trade with a real upside; open-ended autonomy genuinely solves problems fixed workflows cannot. But it is a trade, not a free upgrade, and the failure mode of our whole industry right now is treating a move rightward on the spectrum as maturity rather than as expenditure. Sometimes the right answer is the boring one, and "it depends" here depends on exactly one thing: how far down the reversibility ladder the agent's tools reach.
Failure and recovery. Design the compensating action before you wire the forward action, not after the first incident teaches you that you needed it. If you cannot define the undo for a tool, that is not a detail to handle later — it is the signal that the tool belongs behind a human gate, or does not belong on this agent at all. A one-way-door tool with no gate and no undo is not a feature with a rough edge; it is an outage you have not scheduled yet.
Observability. For an acting system the unit of observability is the trajectory — the ordered sequence of what the agent decided and did — not the final answer and not an aggregate metric. If you can only see that "refunds are up," you are blind; you need to replay the individual decisions that got you there. Build that before you widen the agent's reach, because the day you need it is the day it is already too late to add it. Chapter 12 is entirely this.
Questions to take back to your team. Not rhetorical — these have answers, and if you cannot produce them, you have found your next sprint:
- For every tool this agent can call, which rung of the reversibility ladder is it on, and who signed off on that placement?
- What is the worst thing a single wrong step could do before a human would notice? If nobody can answer, the blast radius is undesigned.
- Which of our tools have a compensating action actually wired, and which are one-way doors we are pretending are fine?
- Does our evaluation measure what the agent did, or only what it said? Write the test that would have caught our last near-miss.
- If this agent ran unsupervised for ten minutes at 3 a.m., what would we most wish we had limited beforehand?
- Are we choosing autonomy because the task needs it, or because "agent" is on the roadmap this quarter?
Strip the word away and an agent is a distributed system with one stochastic node — almost everything you already know still applies, and the one part that doesn't, you handle the way you handle anything you can't predict: bound what it can reach. Put concretely, an agent is a chatbot wired to a set of one-way doors. The model's intelligence sets the ceiling on what it can do well; the reversibility of its tools sets the floor on what it can do to you — and the floor is yours to draw, on purpose, before the agent runs once. That is the whole job, and you are already equipped for it.
Exercises
These reward argument, not recall. An AI will answer each one confidently in four seconds and skip precisely the constraints that make it hard — the blast radius, the undo cost, the premise that might be false. The value is in the part it skips.
Take an agent in your org that everyone calls "safe because it's read-only." Trace one of its outputs all the way to where a human or another system acts on it. At what point did answering become acting — and is that point inside your team's ownership or someone else's? (If it is someone else's, that is the finding.)
List every tool of an agent you are building and place each on the reversibility ladder. Circle the one-way doors. For each, choose exactly one: wire a compensating action, put a human gate in front of it, or remove it. Now defend your choices to a colleague who wants full autonomy and thinks you are being timid — and notice which defenses rest on evidence versus on nerves.
Re-skin the nineteen-hundred-refund scenario onto your product: name your irreversible action, the false premise your model might infer, and the tool call that would return 200 while doing the wrong thing. Then find where the mapping breaks — the thing about your domain the refund bot doesn't capture. The breakdown teaches more than the match.
Your eval suite is green and rates answer quality at 4.6 out of 5. Write the three tests that would have caught an acting-system incident anyway — tests that check what was done, not what was said. Then answer the harder question: why weren't they in the suite already? What in your process assumed the system only talks?
Connections
That atlas gives you one axis — how much a wrong output costs, scaled by volume. This chapter supplies its partner: whether you can take the output back. Carry both. An agent's danger is the two multiplied, and the corner where high cost meets irreversibility is the corner you design out first.
The semantic-undo discipline built there for sagas is exactly what a state-changing tool needs bolted to it, and the external-human-participant pattern from the same material is where our one-way doors will get their gates in Chapter 8. We reuse both wholesale; an agent is, after all, a distributed workflow with one stochastic node, so the distributed-systems playbook mostly still applies — you just have a caller now that may retry for the wrong reason.
An agent that retries a tool call is replaying a step of a workflow, and the same idempotency discipline keeps the replay from doing the work twice. The wrinkle an agent adds: the retry may be triggered by the model's judgment rather than a transport failure, so "did this already happen" becomes a question the agent itself has to be able to ask.
Reversibility is the axis; the spectrum is the decision you make along it. Next chapter turns "how much can this hurt me" into "how much of the control flow should I actually hand over," and argues most teams over-answer.
This chapter classified the blast radius; Chapter 7 is the machinery that enforces the classification, because a rung you assign on a whiteboard and never enforce in code is a wish, not a boundary.
Next: Chapter 2 — The Autonomy Spectrum: workflow, guardrailed agent, and open-ended agent are three different systems hiding behind one word, and most products should live further left than they do.