Six Ways to Structure Work for an AI Agent

The short answer: six AI agent workflow patterns cover almost everything

If you are trying to make sense of AI agent workflow patterns, start with this: "agent" is doing a lot of work as a word. People use it for a chatbot with one tool attached and for a system that runs for twenty minutes making its own decisions. Those are not the same thing, and they do not fail the same way.

Underneath the marketing, almost everything being built with language models falls into six AI agent workflow patterns: routing, parallelisation, orchestrator and workers, tool use, reflection and planning. Knowing which one you are building tells you what will go wrong, what it will cost, and what you need to handle before you let it run unattended.

I build LLM features into production software, and the most expensive mistake I see, from students and from experienced teams alike, is reaching for the most complicated pattern first. This post walks through each of the six, what it is genuinely for, how it fails, and the durable execution work that separates a demo from a system you can leave running overnight.

There is one thread running through all six, so I will state it once at the top: every one of these can fail halfway through. A model call times out, an API returns a 500, a step loops. Whether that partial failure is handled, or whether the whole job dies with half its work done, is the real test of the engineering.

Workflow vs agent: the distinction that matters first

Anthropic's Building Effective Agents draws the cleanest line I know between two kinds of system:

• Workflows are systems where models and tools are orchestrated through predefined code paths. You wrote the steps.
• Agents are systems where the model dynamically directs its own process and tool usage. The model decides the steps.

That same article names five common workflow patterns (prompt chaining, routing, parallelisation, orchestrator workers and evaluator optimiser) and then describes agents on top. My six below overlap heavily with that list. I fold prompt chaining into "the baseline" because it is simply writing steps in order, and I split out tool use and planning because those are where agentic behaviour really begins.

The practical rule from that article is the one I repeat to everyone: start with the simplest thing, measure it, and add multi step agentic complexity only when simpler solutions fall short. The baseline, a fixed sequence of calls you wrote yourself, solves more problems than people expect.

One: routing

Look at what came in, decide which model, prompt or path should handle it, and send it there.

A support system that sends billing questions one way, technical problems another, and anything it cannot classify to a human. A cost layer that sends easy requests to a small, cheap model and hard ones to a capable, expensive one.

Why it helps: each path can be tuned for its own job instead of one giant prompt trying to be adequate at everything. It is also the simplest way to cut cost, because most traffic in most products is easy.

What goes wrong: the classifier itself is sometimes wrong, and a misrouted request gets confidently handled by the wrong specialist. Nobody notices, because the answer still looks fluent.

How to handle it:

• Add a low confidence path. If the router is unsure, send it to a general handler or a human, not a guess.
• Log every routing decision. Misclassification is invisible unless you look at what went where.
• Evaluate the router separately. A labelled set of fifty real inputs tells you its accuracy before users do.

Two: parallelisation

Run several known tasks at the same time, then combine the results. It comes in two flavours: sectioning, where you split one job into independent pieces, and voting, where you run the same task several times and aggregate.

Checking a document against five policies simultaneously is sectioning. Asking a model the same classification question three times and taking the majority is voting.

Why it helps: it is faster, and voting gives you a confidence signal you would not otherwise have. If three runs disagree, that disagreement is useful information.

What goes wrong: one branch fails and now you have four results out of five. Is that an answer or an error?

How to handle it:

• Decide in advance what partial success means. Four out of five policy checks might be acceptable; four out of five sections of a contract is not.
• Retry only the failed branch. Rerunning the whole batch turns a two second recovery into starting over.
• Watch rate limits. Ten parallel calls hit an API's limit ten times faster than one.

Three: orchestrator and workers

One model breaks a task into subtasks, hands each to a worker, then assembles what comes back. Research across many sources, a code change touching several files, anything where the number of pieces is not known until you look.

Why it helps: it handles tasks where you genuinely cannot write the subtask list in advance. That is the honest reason to use it, and it is a narrower reason than most people assume.

What goes wrong: this is the most expensive pattern here and the most over used. Workers duplicate each other's effort. Token cost grows faster than quality does. Anthropic was unusually open about this in describing its own multi agent research system: agents used about four times more tokens than chat, and multi agent systems about fifteen times more. It paid off on broad research tasks, and they are clear it does not suit everything.

How to handle it:

• Try one model with good tools first. It is frequently enough, and it is an order of magnitude simpler to debug.
• Give workers tight, non overlapping briefs. Vague delegation is where duplication comes from.
• Checkpoint each worker's output. If worker six fails, you rerun worker six, not all of them.

If you want a structured look at how these patterns combine in larger designs, Microsoft's AI Agent Orchestration Patterns and LangChain's How and When to Build Multi-Agent Systems are both free and worth reading.

Four: tool use

The model decides which function to call, calls it, reads the result and continues. This is the foundation the other agentic patterns sit on, rather than a competitor to them.

Why it helps: it connects the model to real, current information and real actions: look up an order, query a database, send an email.

What goes wrong: almost always the tool, not the model. Two things matter most.

Descriptions are the interface. The model has your tool's name, its parameters and its description text, and nothing else. There is no colleague to ask. Anthropic's guide to writing effective tools for AI agents suggests describing a tool the way you would explain it to a new hire, and returning clear, human readable results and error messages that tell the model what to try next, rather than opaque codes. Building Effective Agents makes the same point with a lovely idea borrowed from manufacturing, poka-yoke: change the arguments so that mistakes are harder to make.

Retries need idempotency. A tool call that times out may or may not have run. If the retry can charge a card twice, you have not built a retry, you have built a bug. Give side effecting operations an idempotency key so a repeat is safe.

If tool design is new to you, the Model Context Protocol is the standard way to expose tools once and use them from any compatible client, and it is covered in stage 5 of the AI engineering roadmap.

Five: reflection

The model produces something, reviews it, and revises. Anthropic calls the two model version of this evaluator optimiser: one call generates, another evaluates and feeds back.

Drafting, then critiquing, then rewriting. Generating code, running the tests, fixing what failed.

Why it helps: the second pass genuinely catches things the first missed, and when there is an objective signal to react to, like a failing test or a schema validation error, it works very well.

What goes wrong: without a stopping condition it keeps going, and without an objective signal it tends to converge on agreeing with itself.

How to handle it:

• Set a hard iteration limit. Three rounds is often plenty.
• Keep the best version so far. Revision four is sometimes worse than revision two.
• Prefer real signals over self critique. Tests, linters, validators and retrieval checks beat "review your answer".

Six: planning

The model writes out a sequence of steps, executes them, and revises the plan when reality disagrees.

Why it helps: the plan is inspectable. You, or another check, can read it before anything runs. For long or risky tasks, that is the strongest argument for this pattern, and it is why many coding agents show you a plan before they touch your files.

What goes wrong: everything downstream of a bad plan is wasted. Step seven fails, and without checkpoints you restart from step one. If the model can replan freely, it can wander away from what you asked for.

How to handle it:

• Bound replanning. Allow a small, fixed number of plan revisions.
• Put a human approval gate before irreversible steps. Deleting, paying, emailing customers.
• Persist the plan and progress. So a crash resumes at the step it stopped on.

Durable execution: what separates an agent demo from a system

Once a task has multiple steps, the interesting engineering stops being about prompts. It becomes the same durable execution problem that background jobs and payment processing solved years ago.

• Checkpoint after each step. Save what has been completed. If step six fails, resume at six.
• Retry the step, not the job. One flaky API call should cost seconds, not the whole run.
• Make actions idempotent. Retries are only safe if repeating an action is safe.
• Bound everything. Maximum steps, retries, spend and wall clock time. An unbounded loop with a paid API on the end is a bill you will remember.
• Trace it. Every model call, tool call, input and output. When something goes wrong at step nine of a twenty minute run, you will not reproduce it by rerunning hopefully.
• Manage the context between steps. Long runs fill the context window with old tool output. Anthropic's piece on effective context engineering is the best guide I know to keeping only what the next step needs.

The difference from a classic job queue is how failure looks. A job queue fails loudly. An agent fails by producing a confident, wrong, incomplete answer. That is why the patterns microservices teams use for long running work (sagas, compensating actions, retries with backoff) transfer so directly; Grokking Microservices Design Patterns covers those well if you have not met them.

How to choose between AI agent workflow patterns

Work through these questions in order and stop at the first yes.

1. Can you write the steps down? Write them down and run them in order. That is a workflow, not an agent, and that is fine.
2. Do different inputs need different handling? Add routing in front.
3. Are there genuinely independent chunks? Parallelise them.
4. Do the steps depend on results you cannot predict? Now you need tool use, and possibly planning.
5. Is there an objective signal to improve against? Add reflection.
6. Is the work large and its shape unknown until you start? Only then reach for orchestrator and workers, and expect to pay for it.

These patterns also compose. A router can send hard cases to an orchestrator; each worker can use tools and a reflection loop; a planner can fan steps out in parallel. Compose deliberately, one layer at a time, with an eval at each step, and you will know which layer actually earned its cost.

The most common expensive mistake in this area is building the sixth pattern for a problem the first would have solved. If you are designing one of these as part of a larger system, Grokking the AI System Design Interview is a useful way to practise thinking about the whole picture: retrieval, serving, cost and failure together.

Where to go next

If some of the terms here were unfamiliar, start with the AI engineering words you keep hearing, explained properly. If you are still deciding whether you even need an agent, RAG, fine tuning or a better prompt walks through the cheaper options first. And an AI engineering roadmap that puts things in the right order shows where agents sit in the learning path: near the end, for good reason.

Learn it on Sefism

• AI engineering roadmap, stage 6 covers agents and durable execution
• AI engineering cheat sheet
• Building Effective Agents and Writing Effective Tools for AI Agents
• Which AI topics are worth learning: agents, RAG, MCP, LLMs
• Grokking the AI System Design Interview
• AI resource library

FAQ

What is the difference between an AI agent and an agentic workflow?

In a workflow, you write the steps in code and the model fills in each one. In an agent, the model decides which step to take next based on what it finds. Workflows are cheaper and easier to debug; agents handle tasks you cannot script in advance.

What are the most common AI agent design patterns?

Routing, parallelisation, orchestrator and workers, tool use, reflection (also called evaluator optimiser) and planning. Anthropic also lists prompt chaining, which is simply running fixed steps in sequence.

When should I use a multi agent system?

Only when the task is large, its parts are genuinely independent, and a single model with good tools has clearly fallen short. Multi agent systems use many times more tokens and are harder to debug.

What is durable execution for AI agents?

It means a multi step run survives failures: each step is checkpointed, failed steps are retried on their own, actions are safe to repeat, and the run resumes where it stopped instead of starting over.

Do I need a framework to build an AI agent?

No. An agent loop is a model call, a tool call and a condition, in a loop. Writing one by hand first is the best way to understand what frameworks are doing for you.

Ask your own question

If your situation is different from the ones above, the career questions library has honest answers to the questions students and engineers ask me most.

Want a learning roadmap built around you, written answers to your own questions and a place to discuss your FYP? Create your free Sefism account. Members can also book a one to one session when they want to talk it through.

Stay in touch

• LinkedIn: where I share roadmaps, career advice and honest takes on hiring. Follow, or message me.
• X (Twitter): short practical thoughts on engineering and careers.
• Instagram: quick tips and a more personal side.
• Sefism Discord: meet other students and engineers working through the same job market and share what is working.
• Sefism on YouTube: walkthroughs and talks.