Where agents work today

Working wellCopy Anchor Link

Coding: reading a repository, editing files and running tests gives a built-in checker. Research: gathering and cross-checking sources. Customer support: answering from a knowledge base and taking bounded actions like a refund within limits. Data work: writing and running queries, then charting results. Operations: triaging alerts and drafting runbook steps for a person to approve.

Working poorlyCopy Anchor Link

Open-ended goals with no way to tell if the result is right. Long chains where each step is unreliable. Irreversible actions with no human check. Tasks a fixed script could do reliably and cheaply.

A checklist before buildingCopy Anchor Link

Can success be tested automatically? What is the worst thing a wrong action can do? Can it be undone? How many steps will it take, and what is the per-step failure rate? What does one run cost? If you cannot answer, start with a workflow and a human in the loop, then loosen it as evals show the agent is reliable.

A worked example: the checklist appliedCopy Anchor Link

Idea: "An agent that books meetings by email." Can success be tested automatically? Partly. Worst failure? Booking the wrong person, or sharing private info. Reversible? Mostly. Steps? 4 to 8. Verdict: a draft-and-confirm workflow first, with a person approving each invite, loosened later if the pass rate is high.

Questions that save monthsCopy Anchor Link

What does one run cost? What is the pass rate on twenty realistic cases? Who reviews the output? What is the rollback?

Why coding works and market research does notCopy Anchor Link

Picture a coding agent fixing a bug. It edits a function and runs the tests. Three tests fail. It reads the output, edits again, and one test fails. It edits once more and all pass. At every step something outside the model said whether it was right.

Now ask an agent to write a market analysis. No test exists. The agent stops when the text sounds finished, and that is a feeling, not a check. The agent is the same in both cases. What differs is whether the task has a verdict that does not come from the model.

What goes wrong: a confident wrong finishCopy Anchor Link

The symptom is a run that ends with "done" and a tidy report, where a figure in it does not exist in any source. Confirm it by taking ten finished runs and checking every claim against its source by hand. Count the runs with at least one unsupported claim. Do this before anyone trusts the agent, and again after every change to the prompt or model.

How much to trust twenty runsCopy Anchor Link

Suppose 17 of 20 test tasks pass. That is 85 percent, but with only twenty runs the true rate could plausibly sit anywhere from about 65 to 95 percent. A second batch might give 14 of 20. Treat a small test as a rough warning light, not a measurement. To tell two versions apart, you need many more runs or a very large gap between them.

Common mistakeCopy Anchor Link

Starting with the most ambitious use case instead of the most checkable one.

Why long chains failCopy Anchor Link

Suppose each step of an agent is 95 percent reliable. After 10 steps, the chance that every step is right is 0.95^10, which is 60 percent. After 30 steps it is 21 percent. That is why useful agents have short chains, checks after each step and a person at the risky points. It is also why a tool that lets the agent verify its own work, such as a test, is worth so much.

Hype to discountCopy Anchor Link

"Autonomous employees", agent swarms for tasks a script could do, and demos that worked once. The real limits are reliability over many steps and cost, because every step re-reads the context. The agents that work today have a narrow scope, good tools and a way to check themselves.

How to read an agent claimCopy Anchor Link

Ask four questions. What are the steps? What checks the result? What does one run cost? What is the pass rate on twenty realistic tasks?