Four worked examples with the actual reason → act → observe trace played out step by step, so you can see exactly what an agent does between receiving a task and finishing it — not just the theory behind it.
AssertionError: expected total=45.00, got total=40.50 in test_apply_discount.connection pool exhausted errors, starting right after the last deploy.| Example | What it couldn't have done in one shot | Where the guardrail sits |
|---|---|---|
| Support agent | Didn't know the order details or eligibility until it looked them up | Dollar threshold routes large refunds to a human |
| Coding agent | Didn't know the real cause of the failure until it ran the tests and read the code | Diff shown before changes are applied |
| Research agent | Didn't have current prices in memory and had to recover from a bad first search | Every number is tied to a cited source |
| Incident agent | Didn't know the root cause until logs were pulled after the alert fired | Reversible action (restart) is autonomous; risky one (rollback) isn't |
In every case, the value came from the loop — the ability to look something up, be wrong or incomplete, and correct course — not from the model being smarter in isolation.
"Resolve the customer's refund request" — not "look up order, then check policy, then...". If you find yourself writing the flowchart, you may want a simpler pipeline instead of an agent.
Start narrow. Each of the four examples above used three or four tools, not a dozen — fewer tools means fewer wrong choices.
A refund issued, a test passing, a report written, an alert resolved or escalated — give the agent a concrete, checkable stopping condition.
Anything like the refund, the rollback, or a message sent to a real customer needs a threshold, an approval step, or a stricter check than everything else the agent does.
Don't just check the final answer — look at what it searched for, what it read, and where it changed its plan. That's where you'll find the fragile steps worth hardening.