Agentic AI Patterns: Chatbots to Autonomous Agents

The most important shift in enterprise AI isn’t a new model. It’s a new verb. We’ve gone from AI that answers to AI that acts. A chatbot waits to be asked a question. An agent has a goal, makes decisions, uses tools, and checks its own work. That’s a different thing entirely.

I’ve been watching this transition closely, both through my work at Akamai and across the broader EMEA technology landscape. The patterns that make agentic AI work in production are becoming clear. They’re not complicated — and that’s the point. The single most consistent finding across the practitioner literature, from Anthropic’s “Building Effective Agents” to the LangGraph production guides to the cloud vendors’ architecture centres, is that the successful implementations use simple, composable patterns rather than elaborate frameworks. Most teams reach for complexity too early.

So this is a decision guide, not a catalogue. For each pattern I’ll show the shape, then tell you when to use it, what it costs in latency and tokens, and how it fails. The governing principle throughout: start simple, and add agentic structure only when a simpler solution demonstrably falls short.

First distinction: workflows vs agents

There’s an architectural line worth drawing before anything else.

Workflows orchestrate LLMs and tools through predefined code paths. They’re predictable, testable, and cheaper to operate.
Agents let the LLM dynamically direct its own process and tool usage, deciding how to accomplish a task.

Most “agentic” production systems are actually workflows, and that’s a feature, not a failing. Reach for true dynamic agency only where the task genuinely can’t be expressed as a predefined path.

Second distinction: single-agent vs multi-agent

Start with a single agent. A model with memory and tools, running in a loop — think, act, observe, repeat. It’s the simplest thing to build, debug, and monitor, and it should be your default. Most things people build as multi-agent systems should be a single well-prompted agent with good tools.

One agent, one loop. Think → act → observe → repeat, using whatever tools it needs until the goal is met.

The difference from a chatbot is the difference between text and outcomes. “Summarise this document” is a chatbot task. “Find all overdue invoices, draft follow-ups, and send the ones under $10,000” is an agent task.

Multi-agent architectures become valuable when you need specialisation, concurrency, or stronger verification — and when you have data showing the single agent is the bottleneck. They introduce coordination overhead, multiplied cost, and harder debugging. The widely-cited claim that most enterprise agent project failures come down to orchestration design rather than individual agent capability matches what I’ve seen: coordination, not competence, is where these systems break.

The orchestration patterns

The taxonomy below synthesises Anthropic’s workflow patterns with reflection and hierarchical patterns from LangGraph and the cloud vendors’ architecture guides. The terminology varies between sources — routing is sometimes “handoff,” evaluator-optimiser is sometimes “maker-checker” or “generator-verifier” — so the shapes and behaviour matter more than the names.

1. Sequential / prompt chaining

The simplest workflow: decompose a task into a fixed sequence where each step’s output feeds the next. Each step gets scoped context, which makes it cheap and easy to reason about. The trade-off is rigidity.

Sequential chaining. Cheapest and most predictable — and the most brittle to an early error.

When to use: well-defined, decomposable tasks (extract → analyse → flag → report).
Fails by: error propagation — a mistake early cascades. Add validation gates between stages if a step can go wrong silently.
Cost/latency: lowest and most predictable; cost is the sum of steps, latency is serial.

2. Parallelisation

Independent subtasks run concurrently, and their outputs are aggregated. Two variants: sectioning (split work into independent chunks) and voting (run the same task several times and combine via consensus to raise confidence).

Parallelisation. Latency drops toward the slowest worker; cost multiplies by worker count.

When to use: speed matters and subtasks are independent, or voting improves accuracy.
Fails by: aggregation quality, partial failures (one worker errors), and cost multiplication.
Cost/latency: latency falls toward the slowest worker; cost multiplies by N. Fan-out multiplies cost proportionally to agent count.

3. Routing

A classifier evaluates the input and dispatches it to a specialised handler, tool, or sub-agent. This avoids overloading one prompt with every possible case — and lets you send simple requests to cheaper models.

Routing. The headline risk is misrouting — write a routing-accuracy eval before you build the second handler.

When to use: distinct input categories with different handling (customer-service triage is the classic).
Fails by: misrouting. This is the one to instrument first.
Cost/latency: adds a classification step, but can cut overall cost substantially by routing easy requests to cheaper models — commonly reported in the 30–60% range.

4. Orchestrator-workers (hierarchical)

A central orchestrator dynamically decomposes a task, delegates subtasks to workers, and synthesises their results. The difference from parallelisation: the subtasks are not predefined — the orchestrator determines them from the specific input. This is the pattern behind most “lead agent coordinates specialist subagents” research systems.

Multi-agent orchestration. The orchestrator is the project manager; specialists do the work.

When to use: complex tasks where you can’t predict the subtasks in advance (code changes spanning an unknown number of files; open-ended research).
Fails by: runaway cost and loops; context loss during synthesis; the orchestrator hallucinating or omitting detail when it compresses large worker outputs. A multi-agent system without a recursion or handoff guard is a production incident waiting to happen.
Cost/latency: high and variable. Instrument handoff counts and set hard iteration ceilings.

5. Evaluator-optimiser (maker-checker)

One LLM generates a candidate; a second evaluates it against explicit criteria and feeds back; the generator revises. The loop repeats until the evaluator approves or a maximum-iteration limit is hit. It resembles a writer-editor collaboration — and it’s distinct from single-LLM reflection because the roles are explicitly separated.

Evaluator-optimiser. Powerful where quality criteria are checkable — dangerous without an iteration cap.

When to use: tasks with clear, checkable quality criteria where iteration measurably improves output (code generation with tests, translation, structured drafting).
Fails by: near-infinite loops without a cap; weak or inconsistent acceptance criteria that make the checker useless.
Cost/latency: the review step multiplies cost — commonly 1.5–3× depending on iteration frequency — and adds latency per loop.

6. Reflection (single-agent self-critique)

A lighter relative of evaluator-optimiser: one agent generates, critiques its own output, and refines — without a separate evaluator. Cheaper, but weaker, because the same model’s blind spots affect both generation and critique.

Reflection. A quick quality lift — but the model tends to rationalise rather than catch its own errors.

When to use: quick quality lifts where a full second-agent evaluator is overkill.
Fails by: self-consistency bias.
Cost/latency: modest multiplier, bounded by your refinement cap.

Pattern comparison

Pattern	When to use	Key trade-off	Complexity	Cost / latency
Sequential / chaining	Well-defined, decomposable tasks	Rigid; error propagation	Low	Low, predictable (serial sum)
Parallelisation	Independent subtasks; voting	Aggregation quality; cost × workers	Low–Medium	Latency ↓ to slowest worker; cost × N
Routing	Distinct input categories	Misrouting risk	Medium	Adds classifier; can cut cost 30–60%
Orchestrator-workers	Unpredictable subtasks; research, multi-file coding	Runaway cost/loops; hard to debug	High	Highest; variable
Evaluator-optimiser	Checkable quality criteria	Loop risk; needs clear criteria	Medium–High	1.5–3× for the review loop
Reflection	Quick single-agent quality lift	Self-consistency bias	Low–Medium	Modest multiplier

The cross-cutting pattern: human-in-the-loop

This one isn’t a topology — it’s a constraint you apply to any of the above, and it’s possibly the most important. The agent works autonomously for routine tasks but pauses at defined checkpoints: before sending a customer email, before executing a payment, before deleting data. A human reviews, approves or rejects, and the agent continues.

Human-in-the-loop. Tight guardrails at first; widen the auto-approved lane as trust is earned by measured performance.

The boundaries need to be explicit: below this threshold, act freely; above it, ask. A revenue-recovery agent might autonomously chase invoices under $5,000 but escalate anything above. The mistake organisations make is designing for full autonomy from day one. That’s not brave, it’s reckless. The path is: tight guardrails, measure error rates, widen gradually, measure again. The goal isn’t full autonomy — it’s appropriate autonomy.

Tool use via MCP

An agent without tools is just a chatbot with extra steps. The Model Context Protocol standardises how agents connect to tools: expose a tool once, and any MCP-compatible agent can use it. Without it, 5 agents and 10 tools means up to 50 custom integrations; with it, 5 + 10 = 15. The protocol is the multiplier that makes agentic AI practical at enterprise scale — I’ve written a fuller strategic reference on MCP, and there’s an interactive MCP explainer too. The short version: connect once, use everything — but govern those connections through a gateway, because tool descriptions loaded into a model’s context are an attack surface.

MCP turns N×M custom integrations into N+M implementations. The protocol is the multiplier.

Worked example: the revenue recovery agent

Here’s a concrete example that ties the patterns together. I use it because it’s real, measurable, and applies to almost any B2B organisation.

The job: monitor overdue invoices, assess context, send appropriate follow-ups, escalate when needed, log everything.

The revenue recovery agent. Single agent + tool use + human-in-the-loop, all in one flow.

It’s a single agent handling the flow sequentially, using tools (CRM, email, finance system, logging — all via MCP), with a human-in-the-loop gate for high-value accounts and a clear success metric: recovered revenue, measured in pounds. The structure generalises to any process where humans currently chase status and send follow-ups — onboarding, compliance checks, vendor management, IT provisioning. Detect the trigger, gather context, draft the action, gate if high-stakes, execute, log.

Failure modes architects must design for

Demos are easy. Production breaks on a predictable set of issues, and these are the ones I’d design for explicitly:

Silent semantic failure. The one that bites hardest. An agent can loop, call the wrong tool, or drift off-task and still return HTTP 200 with normal latency and token counts. It runs for 18 steps, calls the same search six times, never finds the file, and reports success. The trace is green; the dashboard shows a healthy agent; the product is broken. Structural tracing cannot see this.
Runaway cost and loops. An agent that loops silently for 20 minutes, burning a few hundred dollars in API calls before anyone notices. Always set hard iteration limits and recursion guards.
Context overflow and information loss. In orchestrator patterns, single observations can exceed hundreds of thousands of characters, forcing compression where the orchestrator hallucinates or drops critical detail.
State corruption under concurrency. Sharing state between threads or requests causes interleaving. Isolate per-request state with unique thread IDs.
Error propagation. In sequential chains, an early error contaminates everything downstream unless you insert validation gates.

Observability and cost control

You cannot operate agentic systems on single-call LLM monitoring. Agent observability has to handle multi-turn sessions where each step conditions the next, tool calls and their interpreted responses, non-deterministic execution paths, and failures that only show up when you trace the whole causal chain. In practice that means:

Instrument from day one — traces, cost tracking, evaluation. Debugging multi-agent failures without observability is close to impossible.
Track the agent-specific metrics — handoff/recursion count, routing accuracy, per-session token cost, tool-call success rate, loop detection — not just latency and status codes.
Add a semantic evaluation layer — a per-turn classifier or LLM-as-judge to catch the silent semantic failures the trace can’t see.
Checkpoint state transitions so a crash at step 7 resumes from step 6 rather than re-running, and so runs are auditable.
Govern cost — pattern choice has a 2–5× impact on inference cost. Route easy requests to cheaper models, scope context tightly per agent, and cap evaluator-optimiser loops.

The decision framework

Before deploying an agent, I ask four questions:

Is the task well-defined with clear success criteria? If you can’t measure whether the agent succeeded, it’s not an agent task — it’s a copilot task. Agents need goals, not vibes.

Can a failure be safely reversed? If a wrong email can be apologised for, that’s reversible. Deleting production data is not. Irreversible actions always need human-in-the-loop gates.

Does it need access to multiple systems? If yes, use MCP for tool connectivity. Custom integrations for each tool are the path to unmaintainable spaghetti.

Is the volume high enough to justify the investment? Calculate (time saved per task) × (frequency) versus (build + maintain cost). An agent that saves 2 hours a week is 100 hours a year — worth automating if the build is under 40.

The organisations succeeding with agentic AI aren’t the ones building the most sophisticated systems. They’re the ones picking the right tasks — well-defined, high-frequency, tool-connected, with clear escalation paths — choosing the simplest pattern that solves the problem, and adding structure only when the evidence demands it. Match the pattern to the bottleneck, instrument everything, cap your loops, and never trust a green trace to mean a working agent.

Explore the interactive Agentic AI Patterns framework for the patterns as a visual decision tool, or the MCP strategic reference for the integration layer underneath.