An AI agent is a language model running in a loop: it looks at the situation, chooses an action such as calling a tool, sees the result and repeats until the task is done.

What is the difference between a pipeline and an agent?

A pipeline runs fixed steps in a known order; an agent decides its next step as it goes. Pipelines are cheaper and easier to test, so use agents only when the path can't be known in advance.

How do you stop agents from making costly mistakes?

Give each agent few, well-described tools, keep state in a database rather than in the model, validate every action against real data, treat documents and messages as untrusted, and require human confirmation for anything irreversible.

Orchestrating AI agents: patterns that hold up in production

Diagram of a router sending work to several agents

What orchestration means

An agent is a language model in a loop: it reads the situation, picks an action (often a tool call), sees the result and repeats until the job is done. Orchestration is everything around that loop: deciding which agent handles what, passing information between them, keeping state, and stopping them from doing damage.

Five patterns, from simplest to most complex

One model, one call. Many "agent" problems are a single well-prompted call with the right context. Start here.
Router. A classifier decides what kind of request this is and sends it to the right handler. In Faheem, an intent router sends a customer's message to the menu, a booking, an order or a human; only open questions go down the retrieval-and-answer path.
Pipeline. Fixed steps, each done by a model or by code: extract, validate, enrich, write. Predictable and easy to test.
Planner and workers. One agent breaks a goal into steps, worker agents carry them out, and the planner checks the results. Strong for open-ended work such as research or code changes.
Supervisor with parallel agents. Several agents work at once on independent parts and a coordinator merges what they find. I use this when building software with coding agents: separate agents review correctness, security and design in parallel, then one pass verifies their findings before anything is changed.

What makes it hold up

Keep decisions deterministic where you can. If a rule or a database lookup can decide, don't ask a model. In Faheem, whether a message asks for a purchase link is a fixed check, not a model's guess.
Narrow agents, few tools. An agent with three well-described tools makes fewer mistakes than one with thirty.
State lives outside the model. Conversations, half-finished orders and job progress belong in a database with explicit steps and timeouts. Faheem's ordering flow is a small state machine that expires stale sessions instead of hoping the model remembers.
Check before acting. Validate tool arguments, verify links and numbers against real data, and require a person's confirmation for anything irreversible.
Treat every input as untrusted. Documents and messages can contain instructions aimed at the model (prompt injection). Keep data separate from instructions, and scrub outputs before they leave the system.
Measure. Keep a set of real conversations and run them after every change. Orchestration bugs hide in the hand-offs between steps.

When you don't need agents

If the steps are known in advance, a pipeline with one or two model calls is cheaper, faster and easier to debug than an autonomous agent. Use agents where the path genuinely can't be known up front, and keep a human close to anything that costs money or can't be undone.