How to build an AI agent that holds

Measure one process first

A team asks for an agent. What it usually has is a process: a person already runs it, the inputs already arrive, and someone can say when a case is done. Start there, with one process, not a platform.

Take two readings before a model is called: how long a case takes today, and where the process fails, meaning the cases that get sent back, escalated, or quietly fixed later by someone else. Those two readings are the baseline. When the system is in place, take the same readings on the same kind of cases. Without the before, the after is an opinion.

Three questions decide whether a process is ready.

• Can a person say, case by case, what done looks like? If two people who run the process disagree about a case, an agent will not settle it for them. It will pick one answer at random and look confident.
• Do the inputs exist where a system can reach them? A process that lives in one person’s head and three inboxes needs that fixed first.
• What does a mistake cost, and can it be undone? The answer sets how much of the path a person keeps.

If a product the team already uses does the job, stop there. A second system beside a feature that already exists does not give you a result you can defend.

To keep this concrete, the rest of this guide follows one example process, which we chose because it touches every decision below. Supplier invoices arrive by email as PDFs. A person matches each one to a purchase order, flags the ones that don’t match, and queues the rest for payment. It reads documents written by outsiders, it writes to a finance system, and it ends next to money.

How we take a process like this into production sits on the AI agents page.

Who holds the plan

Two different machines get the same name. In the first, your program decides the order of steps and the model fills one of them. Anthropic’s engineering note of 19 December 2024 calls that a workflow:

Workflows are systems where LLMs and tools are orchestrated through predefined code paths.

The note is Building effective agents, by Erik S. and Barry Zhang. A line added at the top says much of the tooling it describes has changed since December 2024 and points to Anthropic’s newer Managed Agents material. The distinction between the two machines has not changed.

In the second machine, the model reads the result of a step and decides the next tool, the next question, or the stop. OpenAI’s guide of 15 January 2026, A practical guide to building agents, draws the same line from the other side. An agent uses the model to run the workflow, recognises when it is finished, and can halt and hand control back. A chatbot that answers once, or a classifier, is not one.

The useful question is not “agent or not” but “who decides the next step, at each point.” Most systems that hold in production are mixed. In the invoice process, the order of steps is known in advance: read, match, flag, queue. That part is a workflow. A model earns its place in step one, reading invoices in a hundred layouts. The match against the purchase order is arithmetic, and code does arithmetic better.

Every step you hand to the model costs something. Anthropic is direct that agentic systems buy better results with extra latency and cost, and that autonomy adds the risk of errors compounding across steps. When the path can be drawn before the run, draw it.

When a fixed path fails

OpenAI names three situations in which a checklist stops being the right machine. The examples are theirs.

• The decision turns on exceptions and context the checklist does not hold. Their example is a refund.
• The rules have piled up until changing them is a project of its own. Their example is a vendor security review.
• The work arrives as language: documents, messages, a claim written in prose. Their example is a home insurance claim.

Their framing for this is a fraud check. A rules engine flags a transaction when a preset condition is met. An agent works more like an investigator who notices a pattern no rule was written for. Their advice is to confirm that a use case clearly meets these criteria before building, because otherwise a deterministic solution may be enough. Anthropic reaches the same place: for many applications, one call, given the right documents and a few examples, is the whole system.

There is a second test, and it comes from the other source. Anthropic’s appendix describes where agents have actually paid off: tasks that need both conversation and action, that have clear success criteria, that allow feedback loops, and that keep a person meaningfully involved. Customer support and coding are their two cases. Code can be checked by tests. A support ticket is resolved or it isn’t.

Read together, the two lists answer different questions. OpenAI’s tells you when a process needs a model to choose. Anthropic’s tells you when you will be able to tell whether the model chose well. The process to avoid is the one that passes the first test and fails the second: it needs flexibility and has no way to check the result.

The invoice process passes the first test on two counts, a rulebook that has grown with every supplier and inputs that arrive as unstructured documents. It passes the second because every case ends in a state you can check: matched, flagged, or queued. That justifies a model for reading. It does not justify a model deciding what gets paid.

The smallest system that works

Start with one call. Add a step only when a run shows that call getting one specific thing wrong. Each of the patterns Anthropic names has a condition and a typical way of failing.

• A chain, when each step is easier than the whole job. One call drafts. A gate, written in code where possible, checks the draft against a list you wrote before the next step runs: the fields that must be present, the claims you will stand behind. The failure is a chain without gates, where step three inherits step one’s mistake.
• A router, when you can name the kinds of input in advance and classify them reliably. A question the documents can answer goes one way. A request that needs a person goes another. Anthropic also uses routing to send easy cases to a smaller, cheaper model and hard ones to a stronger one. The failure is silent: a misrouted case looks like a normal case down the wrong path. Score the router on its own.
• Parallel calls, in two forms. Sectioning splits a job into independent parts. Voting runs the same check several times and compares. Anthropic notes that a guardrail tends to work better as its own call than folded into the call that does the work.
• A loop, where one call produces and a second evaluates. Anthropic gives two signs that this pays: a person’s written feedback measurably improves the output, and a model can produce that same feedback. Without a criterion, the loop has nothing to judge.
• An orchestrator, when the subtasks only appear once the input arrives. Anthropic’s usual case is a change across a codebase, where the files involved depend on the task.

The last pattern is already close to an agent. When you go that far, two things from Anthropic’s note matter most. The agent should get ground truth from the environment at each step, such as a tool result or a test outcome, rather than its own account of progress. And it needs a stopping condition you set, such as a maximum number of steps.

On frameworks, Anthropic’s advice is to start with the model’s API directly, since many of these patterns take a few lines of code. Frameworks speed up the start but can hide the prompts and responses you need to see when something breaks. If you use one, know what it does underneath.

Model, tools, instructions

OpenAI splits a build into the model, the tools, and the instructions.

The model. Prototype on the most capable model you are willing to run in production, score it, and only then try a smaller model on the steps that stayed easy. The score from the first model is the bar the smaller one has to meet. Keep in mind that a score belongs to the model and the code around it together. Change either and you have a new system to score.

The tools. OpenAI sorts tools into three kinds. Data tools read: a database query, a document, a search. Action tools change something: a record, a message, a ticket. Orchestration tools are other agents. The kind matters more than it looks. A data tool and an action tool need different guardrails, and the guardrails guide starts from that split.

Write each tool the way you would brief someone new on the team: a clear name, the arguments, an example, the edge cases, and how it differs from the tools next to it. Anthropic reports spending more time on their tools than on the overall prompt while building a coding agent for SWE-bench. Relative file paths failed once the agent left the project root, and requiring absolute paths removed that class of mistake. The general lesson is to change the tool so the mistake is hard to make, rather than adding a warning to the prompt. Prefer formats the model has seen often in ordinary text, and avoid ones that force it to count lines or escape characters.

How many tools is too many? OpenAI’s answer is that overlap matters more than number. Some systems handle more than fifteen distinct tools well. Others struggle with fewer than ten that look alike.

The instructions. Do not write them from a blank page. OpenAI recommends starting from the documents the process already has: operating procedures, support scripts, policy pages. Break dense passages into steps, make each step a specific action or output, and write down what happens when an input is incomplete or unexpected. Then add three things the existing documents rarely state: the task, the condition that ends a run, and the cases that go back to a person.

One agent or several. Start with one. OpenAI’s advice is to get as far as one agent can go before splitting, because each extra agent adds coordination you then have to test. Split when the instructions have filled up with if-then branches, or when tools overlap so much that clearer descriptions no longer help. At that point there are two shapes: a manager that calls other agents as tools and keeps control of the conversation, or a handoff in which a second agent takes the conversation over.

Before it touches a live system

Three documents come first, each written with the person who owns the process. Each has its own guide.

The cases. At least 50, taken from the process, each with a result a person can mark. That number is our bar, not a published finding. Anthropic’s January 2026 note on evaluating agents suggests 20 to 50 cases drawn from real failures as a good start, and we set ours at the top of that range so that every known failure type is represented more than once. How to build and keep that set is in Score an AI agent on its own work.

The limits. What the system may read, what it may change, and what it must refuse, enforced by permissions rather than by instructions alone. That is Guardrails before an AI agent runs.

The handoff. How many retries are allowed, and which actions wait for a person. That is Where a person stays on the path.

Then the run itself. A wrong step becomes the input of the next one, so errors compound. Anthropic recommends extensive testing in a sandbox before anything else, and that is where the system meets its cases. It stops on the conditions you wrote. OpenAI lists the common ones: a final output in the expected form, an error, or a maximum number of turns. A model that has decided it is finished is not one of them.

If you are about to build, read the two source guides in full. Then see how we take one measured process into production, on the AI agents page.