"These Are Not Edge Cases. These Are Tuesday."

Building an agent that works is a weekend. Building one that keeps working is the rest of the project, and almost nothing written about agents covers the second part.

Here is what the gap actually consists of.

Problem One: It Has No Memory

The agent you build first has amnesia. Every invocation starts from zero. It does not remember what you asked five minutes ago, cannot reference a tool result from three turns back, and if you corrected a mistake, the correction is gone next time.

This is not a defect. Language models are stateless functions — messages in, completion out, nothing persists. Memory is something you build.

And it decomposes into three separate problems that get conflated.

Conversation memory is keeping the recent exchange so follow-ups work. Straightforward until the context window fills, at which point you need a policy: drop the oldest turns, summarise them, or keep a rolling window with pinned essentials. Every option loses something, and choosing wrong produces an agent that mysteriously forgets the constraint you gave it eight turns ago.

Retrieved memory is pulling in relevant information from a larger store — embedding content, searching by similarity, injecting what matches. This is where most people reach for a vector database, and where most people over-engineer, because a great many agents need far less retrieval than the architecture diagrams suggest.

Persistent state is the facts that must survive across sessions, and it is the one that gets skipped. This is not conversation history; it is the record of what the agent has actually done. Which records it already processed. Which actions it took. Where it was when it crashed. Without this, an agent that dies mid-task and restarts will happily redo everything, which is fine for a summariser and catastrophic for anything that sends emails or moves money.

Problem Two: Everything Fails, Unhelpfully

A demo agent calls a tool, gets a result, reasons, answers. Production is different in specific and repetitive ways.

APIs time out at two in the morning because a third party is doing maintenance. The model invents a tool name that does not exist and calls it with confidence. A tool call succeeds and returns malformed JSON that crashes your parser. The agent gets stuck calling the same failing tool repeatedly, at a few cents per iteration, all night. A planning agent decomposes a simple request into forty-seven subtasks and spends twelve dollars completing them.

None of these are exotic. They are the normal operating conditions of a system that combines a nondeterministic component with network calls.

What makes them harder than ordinary error handling is that the agent will try to recover, and its recovery attempts are also nondeterministic. A conventional program that hits an error stops. An agent that hits an error reasons about the error and does something — which may be sensible, or may be calling the same broken tool with slightly different arguments, forever.

What the Defences Look Like

Four, in order of how much grief they save.

A hard iteration cap. Non-negotiable and trivially cheap. The loop terminates after N passes regardless of what the agent thinks. This alone prevents the most expensive failure mode.

A budget ceiling per task. Tokens or dollars, tracked, enforced, with the task failing loudly when exceeded. An agent without a spend limit is an open-ended financial commitment, and the failure that empties the budget always happens overnight.

Validated tool calls. Check that the requested tool exists and that its arguments match the schema before executing. When validation fails, return a structured error the agent can read — "no such tool; available tools are X, Y, Z" — because a useful error message lets it correct itself, while a crash does not.

Loop detection. Track recent tool calls and their outcomes. If the same call has failed three times, stop retrying it and tell the agent it is unavailable. This is the single most valuable defence and almost nobody builds it first, because the failure it prevents only shows up under conditions you cannot reproduce on your laptop.

The general principle underneath all of these: errors should be returned to the agent as information, not raised as exceptions — but the agent's ability to respond to that information must be bounded by mechanisms it does not control. Give it the chance to recover. Do not give it unlimited chances.

The Thing That Makes This Different

Ordinary software fails predictably. Given the same input and state, it fails the same way, which is what makes debugging tractable.

An agent that fails may fail differently on the next run with identical inputs. The failure may be a wrong decision rather than a crash — plausible, well-formatted, and incorrect. And the effects may already have happened, because the agent's whole purpose is to take actions.

This is why observability matters more here than in conventional systems. You need to be able to reconstruct not just that it failed but what it was reasoning about: every tool call, every argument, every result, every decision point. Without that record, debugging an agent is guesswork, because the thing you are trying to explain does not reproduce.

And it is why the blast radius of each tool matters so much. A tool that reads is safe to let an agent retry aggressively. A tool that writes, sends, or spends is not, and the design question — before any of the error handling — is which tools you are willing to have called by something that may be wrong and will not know it.

Where the Effort Actually Goes

The reasoning loop is the easy part and it is where all the tutorials stop. Memory design, state persistence, error boundaries, budget control, loop detection, and observability are the work.

That ratio is not a criticism of agents. It is the same ratio as any distributed system: the happy path is a small fraction of the code, and the value of an engineer is almost entirely in the rest.

The difference is that with agents, the demo is unusually convincing, which makes the gap between working and reliable easier to underestimate than it has ever been.

Build Your Own AI Agent From Scratch: A Python Guide to Tools, Memory, Reasoning, and Autonomous AI Systems builds up from the simplest possible agent — function calling, real tools, dynamic selection, MCP, conversation and vector memory, persistent state, ReAct, planning, error handling, agent-to-agent communication, and the move to production.