Why do AI agents work in demos but fail on real tasks?

Because reliability compounds across steps. A demo task is short and hand-picked, so it rarely trips a failure, but a real task runs many steps and their error rates multiply: even 95 percent reliable steps give roughly a one-in-three chance of a correct result over twenty steps. Production tasks are also longer, hit flaky tools, and face adversarial input that a demo never sees. Making agents reliable means verification, retries, bounded scope, and decomposition, not a better single prompt.

What is the agent loop?

The agent loop is the cycle of decide, act, observe that a language-model agent runs until it finishes. The model looks at the goal and history and requests an action, an orchestrator executes that action as a tool call, the result is appended to the context, and the model is called again with the new information. The model never runs anything itself; the orchestrator owns the loop and enforces the budgets and stopping rules the model cannot be trusted to enforce on its own.

Why is prompt injection worse for agents than for chatbots?

Because an agent can act, not just speak. A chatbot tricked by injected text might say something wrong; an agent tricked by text hidden in a tool result (a web page, a document, a ticket) might send money, delete data, or leak files, since the model cannot reliably separate instructions from the untrusted data in its context. The defenses are layered: least-privilege tools, human approval for irreversible actions, credentials scoped to the user, and never treating tool output as trusted instructions.

How do you stop an agent from looping forever or costing too much?

You put limits outside the model, because the model decides its own next action and cannot be trusted to stop. A budget manager caps steps, tokens, time, and money per task and halts the run at the ceiling, a loop detector notices the agent repeating a failing action and breaks the cycle, and termination combines the model's done signal with those hard limits. This turns an open-ended risk into a known worst case, which is what makes an agent shippable rather than a runaway bill.

Should I build one agent or a team of agents?

Default to one agent with a good set of tools, because it is simpler, cheaper, and far easier to debug, and it handles most tasks. Reach for multiple agents when the work genuinely splits into independent subtasks that can run in parallel, or when isolating a role like a planner or a critic measurably improves reliability, which is now common for long-horizon research-style work. Multi-agent systems add coordination overhead, more failure points across handoffs, and a multiplied token bill, so the task's structure has to earn that cost.

Which framework should I use to build an AI agent?

For an interview, the framework is the least interesting part of the answer, and naming one is not a design. The options cluster into graph-based orchestrators like LangGraph, vendor SDKs like the OpenAI Agents SDK and Anthropic's tooling, role-based frameworks like CrewAI, and durable-execution backends like Temporal that several agent platforms build on. What they differ on is how much of the control loop, the state persistence, and the tool contract they own versus leave to you. Since the loop, the budgets, the recovery, and the guardrails are where the real engineering lives, pick whichever framework gets out of the way of those, and be ready to explain the loop yourself rather than pointing at a library that hides it.

System design interview guide

Design an AI Agent: Agentic System Design Interview

in this guide

Design an AI Agent, part by part

7 parts open to everyone · 3 with a free account · 3 with the course

Requirementsopen
Scale estimatesopen

Why this question is asked

Agents are where the industry is spending its attention right now, and the question separates people who have wired up a demo from people who have run one in front of real users. The demo works because a short, happy-path task rarely trips the failure modes; production breaks because real tasks are long, tools fail, models hallucinate a wrong action, and an adversary can feed the agent poisoned input through a tool. An interviewer can watch whether a candidate reaches for the uncomfortable truths: that reliability degrades geometrically with the number of steps, that an agent run is a stateful long-lived process that needs the same durability guarantees as a payment workflow, that giving a model the ability to act turns prompt injection from an annoyance into a security incident, and that the cost of a task is a loop you have to bound rather than a fixed number. It is also a good test of judgment, because the strongest answer is often to constrain the agent: fewer tools, tighter scope, a human in the loop for the dangerous step, rather than a maximally autonomous system that is impressive and unshippable.

This page is the free part.

The course goes deeper on the AI Agent design

₹499 in India$49 everywhere elseonce, for the whole course

The System Design course covers the AI Agent design across a run of lessons, not one page. These 4 alone are about 172 minutes of step-by-step reading, 2 of them with code you run in the browser, all with a quiz.

Live from the course bench

Before you design AI Agent, try the questions it rests on.

Real interview questions, live diagrams and measured lab results, pulled at random from the lessons. A new set every time you come back.

Two engineers sketching a system design on a whiteboard

where the work happens

Stuck on a card?

Ask the course tutor. It answers with a real diagram, drawn for your question.

Ask the tutor

Laying out the cards…

Requirements

Always clarify these in the first 5 minutes of the interview. Do not start drawing boxes until both lists are agreed.

Functional requirements

Take a natural-language goal and pursue it over multiple steps, deciding each action from the results of the previous ones
Call tools (search, code execution, database queries, third-party APIs) and incorporate their results into the next decision
Maintain working state across steps and, where useful, remember facts across separate sessions

Go deeper

This guide is built on these 5 lessons. Each one teaches one piece of the AI Agent design above, step by step.

Practice with 770 system design lessons

Lifetime access for ₹499 in India or $49 elsewhere. Interactive diagrams, quizzes, and 20 capstone projects to practise on.

Get lifetime access See all interview problems

An AI agent is a language model put in a loop: it looks at a goal, decides on an action, calls a tool, reads the result, and repeats until it thinks it is done. That loop is the whole difficulty. A single model call either works or it does not, but an agent chains dozens of calls, and the failure modes multiply rather than add. If each step is 95 percent reliable, a twenty step task finishes correctly only about a third of the time, so an agent that feels magical in a demo can be unusable in production for the exact same task. On top of that, every step is a full LLM call over a transcript that keeps growing, so both the latency and the dollar cost of a task climb with the number of steps, and a single agent run can take minutes and make a hundred model calls. Designing an agent is mostly about controlling that loop: keeping it reliable, keeping it bounded, keeping it safe when it can take real actions, and keeping it recoverable when it inevitably crashes halfway through.

Wire a model to a few tools and you have something that looks like an agent; run it on a real task and the loop is where every hard problem surfaces. The model does not execute anything itself; it emits a request to call a tool, an orchestrator runs the tool, and the result is fed back for the next decision, over and over. The first thing that bites is reliability, because a chain of steps multiplies its per-step error rate, so the design has to add verification, retries, and bounded scope to stop a long task from almost certainly failing. The second is state, because an agent run is long enough to outlive the process running it, which turns it into a durable-execution problem closer to a workflow engine than to a web request: you record each step so a crash resumes instead of restarting. The third is memory, since the growing transcript is both the agent's working memory and its biggest cost, so you decide what to keep in the context window, what to push to a store and retrieve later, and what to summarize. The fourth is safety, and it is sharper than in a plain chatbot because the agent can act: a tool can send money or delete a file, and the untrusted text a tool returns can carry a prompt injection that hijacks the next decision, so tools run with least privilege and irreversible actions wait for a human. Cost ceilings, loop detection, parallel tool calls, and trajectory-level evaluation ride on top of all of it. Get the control loop and its guardrails right and the agent ships; get them wrong and no starting prompt will save it.

Bounded Context
Draw clear boundaries around domain models, where 'Customer' means one thing inside and something different outside.
25 min · diagrams · quiz
Design an AI Agent Platform
Design a production AI agent orchestration platform - MCP, A2A protocol, tool calling, memory systems, multi-agent workflows, cost management, and safety guardrails.
70 min · diagrams · code you run · quiz
Principle of Least Privilege
Granting the minimum permissions necessary to perform a task, nothing more, nothing less.
11 min · diagrams · quiz
Lakehouse Architecture: What a Folder of Parquet Files Gets Wrong
What is a lakehouse, and what breaks if a table is just a folder of Parquet files? Warehouse, lake and lakehouse in plain words first. Then a lab on 7,052,769 real NYC taxi trips: while a writer added February as 8 files, a reader that listed the folder saw every half-written state, 9 different row counts; a Delta Lake reader saw only 3,475,226 rows or 7,052,769, never anything between. During an overwrite, the folder reader counted 6,806,334 trips for one month that held 3,331,108. In a real race, 5 runs per case, the folder reader saw a half-written table 7 to 9 times per run and failed 955 to 5,003 reads; the Delta reader saw 0 half-written tables and 0 failures.
66 min · diagrams · code you run · quiz

Back-of-envelope scale estimates

Show your math. Pulling numbers from thin air signals you have not thought about the load.

Steps per task

~5 to 50 model calls per task

A simple lookup finishes in a couple of steps; a real research or coding task runs tens of iterations of decide-act-observe, and each iteration is a full LLM call, so a single task is not one inference but dozens.

Reliability compounding

0.95^20 is about 0.36

If each step succeeds 95 percent of the time and a task needs twenty correct steps, the task finishes correctly only about a third of the time. This one number is why per-step verification and bounded scope are not optional.

Cost per task

Sum over steps of a growing prompt

Step k resends the accumulated transcript, so token cost grows roughly with the square of the step count unless you prune or summarize. A hundred-step task without context management can cost far more than a hundred single calls.

Task duration

Seconds to many minutes

Because steps are sequential and some tools are slow (a web fetch, a build, a human approval), an agent task is long-lived by nature, which is what forces durable execution rather than a single request-response.

High-level architecture

At the center is the control loop, and it is worth being precise about who does what because the split is the whole design. The model is a stateless function that, given the goal and the history so far, returns either a final answer or a structured request to call a tool. It never runs anything itself. An orchestrator owns the loop: it sends the current context to the model, parses the tool call the model asked for, validates and executes that tool, appends the result to the running transcript, and calls the model again, until the model signals completion or a budget is exhausted. Because that loop can run for minutes and make many calls, the orchestrator is built as a durable state machine rather than a plain function: every step is persisted to a log so that if the process dies, the run resumes from the last completed step instead of starting over, which is the same guarantee a workflow engine gives a long business process. Tools live behind a registry with typed schemas the model is shown, and each tool runs in a sandbox with only the permissions it needs, so a code tool cannot touch the network and a payment tool cannot be called without an approval gate. Memory has two tiers: the working context is the transcript the model sees each step, kept within the context window by pruning or summarizing old steps, and a long-term store (usually a vector database) holds facts the agent can retrieve across sessions. Wrapped around the loop are the guardrails that make it shippable: a budget manager that counts steps, tokens, time, and money and stops the run at a ceiling; a loop detector that notices the agent repeating the same failing action; an input and output safety layer that treats tool results as untrusted; and a human-in-the-loop checkpoint that pauses the run and waits for approval before an irreversible action. Everything the loop does is emitted as a trace, because the unit you debug and evaluate is not a single answer but the entire trajectory of steps that led to it.

In a real interview, sketch this on the whiteboard before diving into any single box.

Core components

Walk through each service. The interviewer wants to hear what each one owns, not just the names.

Orchestrator (the control loop)

Drives decide-act-observe: prompt the model, parse the requested tool call, execute it, append the result, repeat. It is the brain stem of the system and it is where budgets, retries, and termination conditions are enforced, because the model cannot be trusted to stop itself.

Durable execution layer

Persists every step so a run can survive a crash and resume rather than restarting. The important subtlety is that a model call is not deterministic, so recovery cannot re-run step 40 and expect the same result. Instead you record the output of every model and tool call as it happens and, on recovery, replay those recorded outputs to rebuild state up to the last completed step, then continue live from there. That plus retries with backoff for flaky tools is the durability a long-running agent needs, not the statelessness of an HTTP handler.

Tool registry and sandbox

Holds the typed schema of every tool the model may call and runs each in an isolated environment with least privilege. The schema is what the model is shown so it can form valid calls; the sandbox is what stops a hallucinated or injected call from doing damage. The isolation boundary is a real decision rather than a detail: a container is cheap but shares a kernel, a microVM or gVisor buys stronger separation for untrusted code, and an egress policy is what stops an allowed tool from becoming an exfiltration path. The Model Context Protocol (MCP) has become the common way to expose tools to a model in a uniform, discoverable schema instead of hand-rolling one per integration.

Memory system

Two tiers. Working memory is the transcript the model sees each step, kept inside the context window by summarizing or dropping old turns. Long-term memory is an external store, often a vector database, that the agent writes facts to and retrieves from across sessions so it is not amnesiac between runs.

Planner

Decides the strategy: plan the whole task up front and then execute, interleave thinking and acting one step at a time, or decompose into subtasks handled by separate agents. The choice trades foresight against adaptability, and it decides how the agent recovers when a step surprises it.

Budget and loop control

Counts steps, tokens, wall-clock time, and money against a per-task ceiling and terminates when any is hit, and detects when the agent is stuck repeating an action that keeps failing. Without this an agent can loop forever and cost an unbounded amount on a single task.

Safety and approval layer

Treats every tool result as untrusted input that may carry a prompt injection, screens the agent's proposed actions, and pauses for human approval before anything irreversible. This is heavier than a chatbot's moderation because the agent can act on the world, not just speak.

Tracing and evaluation

Records the full trajectory (every prompt, decision, tool call, and result) so a run can be replayed, and scores agents on whether they reached the goal and how efficiently, not just on a final string. The trajectory, not the answer, is the unit of debugging and evaluation.

the deep dive

Deep dives

Reliability compounds, so long tasks fail unless you fight it. This is the fact everything else reacts to. Steps in an agent chain are roughly independent trials, so their success rates multiply: a 95 percent reliable step run…

free with an account

11 deep dives on the parts that break at scale: Reliability compounds, so long tasks fail unless you fight it; An agent run is a durable workflow; Tool calling is a contract, and the model will break it.

One tap with Google. Free, no card.

the deep dive

Trade-offs to discuss

Constrain the agent rather than maximize autonomy. A narrower agent with fewer tools, tighter scope, and human gates on dangerous actions is more reliable, cheaper, and safer than a maximally autonomous one, and it is…

free with an account

5 decisions an interviewer expects you to defend, each with the alternative and why it loses here.

One tap with Google. Free, no card.

How an AI Agent actually does it

The reasoning-and-acting loop at the core of most agents was named by the ReAct paper (Yao et al., 2022), and the reflection pattern where an agent critiques and retries its own work comes from Reflexion (Shinn et al., 2023). The tool-calling contract is documented directly in the function-calling and tool-use guides from OpenAI and Anthropic, and the emerging standard for exposing tools to models in a uniform way is the Model Context Protocol. The durable-execution framing is not speculative: production agent frameworks have converged on checkpointing and replay, and the pattern is the same durable-execution approach Temporal popularized for long-running business workflows, which several agent platforms now build on directly. Prompt injection as the central agent security risk is documented by OWASP, which lists it as the top risk for LLM applications, and the confused-deputy framing of an agent acting with borrowed authority is standard security reasoning applied to a new setting. Anthropic's own engineering writing has made the point that most reliable production agents are single agents with good tools rather than elaborate multi-agent systems, and that constraining scope beats maximizing autonomy. Treat the specific architecture here as a synthesis of these public patterns rather than any one vendor's internal design, since the systems that run at scale are not fully published.

Sources

the question most readers have next

The agent worked in the demo. Why does it fail one long task in three in production, and what happens when it crashes at step 40 after it has already sent an email?

Step success rates multiply: 95 percent per step over 20 steps finishes correctly only about 36 percent of the time, so you check each step, retry, and keep tasks short. A run that lasts minutes is a workflow, so every step is recorded and a crash resumes from the last finished step instead of sending the email again. Text that tools return can carry instructions, so dangerous actions need narrow permissions and a human check.

Where this is used in industry

Anthropic: Reports that the most successful agent builds it saw used simple, composable patterns rather than complex frameworks, and warns that autonomy brings higher cost and compounding errors.
Anthropic: Building Effective Agents
Temporal: Positions its durable execution engine for AI agents: the full execution history is recorded, so an app that goes down picks up where it left off and failed calls are retried.
Temporal: Durable execution meets AI
OWASP: Lists prompt injection as LLM01, the first risk in its top 10 for LLM applications, including indirect injection hidden in websites or files the model reads.
OWASP GenAI: LLM01 Prompt Injection

Build it yourself: what you would have to solve

Twenty steps at 95 percent each leave a long task more likely to fail than succeed. You need levers that raise the whole-task rate.
The Agent Loop: Why AI Agents Fail as Tasks Get Longerfree lesson42 min
The process dies at step 40. Replaying from the start would resend emails and repeat payments, so each step must be persisted and replayed from its recorded result.
Durable Execution: An Agent Run Is a Workflow, Not a RequestAI Engineering course

Stuck on a step? Every lesson has an AI tutor beside it. Ask it your question and it answers from the lesson you are reading. Try the tutor

Get the free AI Engineering cheat sheet (PDF)

Where this is taught

AI Engineering

210 lessons · about 219 hours · 10 free to read

₹999 in India by UPI$49 elsewhere by PayPal, once, for life

See the AI Engineering course

You own this course

Also by the same author

Design an AI Agent: Agentic System Design Interview

Design an AI Agent, part by part

Why this question is asked

The course goes deeper on the AI Agent design

Before you design AI Agent, try the questions it rests on.

Requirements

Functional requirements

Go deeper

Practice with 770 system design lessons

Non-functional requirements

Back-of-envelope scale estimates

High-level architecture

Core components

Orchestrator (the control loop)

Durable execution layer

Tool registry and sandbox

Memory system

Planner

Budget and loop control

Safety and approval layer

Tracing and evaluation

Data model

Deep dives

Trade-offs to discuss

What the interviewer asks next

How an AI Agent actually does it

Lessons to study before this interview

The agent worked in the demo. Why does it fail one long task in three in production, and what happens when it crashes at step 40 after it has already sent an email?

Where this is used in industry

Build it yourself: what you would have to solve

Frequently asked questions

Are you ready for Design an AI Agent?

Design an AI Agent: Agentic System Design Interview

Design an AI Agent, part by part

Why this question is asked

The course goes deeper on the AI Agent design

Before you design AI Agent, try the questions it rests on.

Requirements

Functional requirements

Go deeper

Practice with 770 system design lessons

Non-functional requirements

Back-of-envelope scale estimates

High-level architecture

Core components

Orchestrator (the control loop)

Durable execution layer

Tool registry and sandbox

Memory system

Planner

Budget and loop control

Safety and approval layer

Tracing and evaluation

Data model

Deep dives

Trade-offs to discuss

What the interviewer asks next

How an AI Agent actually does it

Lessons to study before this interview

Related system design interview questions

The agent worked in the demo. Why does it fail one long task in three in production, and what happens when it crashes at step 40 after it has already sent an email?

Where this is used in industry

Build it yourself: what you would have to solve

Frequently asked questions

Why do AI agents work in demos but fail on real tasks?

What is the agent loop?

Why is prompt injection worse for agents than for chatbots?

How do you stop an agent from looping forever or costing too much?

Should I build one agent or a team of agents?

Which framework should I use to build an AI agent?

Are you ready for Design an AI Agent?