The Four Parts of a Production AI Agent (Most Teams Ship Only Three)

A production-grade AI agent has four parts: a reasoning loop that decides what to do next, a tool layer that lets it act on the world, a memory layer that carries state across steps, and an evaluation-and-observability layer that tells you when it is wrong. Most teams build the first three, demo them, and ship. The fourth part is the one that separates a convincing demo from a system you can run in a regulated business for eighteen months. Skip it and you join the statistics: Gartner predicts over 40% of agentic AI projects will be cancelled by the end of 2027 (Gartner, June 2025).

This post walks through all four, in the order they tend to fail.

Why does the demo work and the deployment die?

The gap between a working prototype and a running agent is measurable, and it widened through 2025. S&P Global's Voice of the Enterprise survey found that the share of companies abandoning most of their AI initiatives before production rose from 17% to 42% year over year, with the average organization scrapping 46% of its proof-of-concept projects (S&P Global, October 2025).

The reason is structural. A demo runs once, on a happy path, watched by the person who built it. Production runs thousands of times, on inputs nobody anticipated, while everyone who built it is asleep. The first three parts of an agent are enough to pass a demo. The fourth part is what keeps the other three honest at scale. Teams under-invest in it because it produces no visible feature, and that under-investment is exactly what shows up later as a cancelled project.

Let me take the parts one at a time.

Part one: the reasoning loop

The reasoning loop is the control flow that sits around the model. It takes a goal, decides on the next action, observes the result, and decides again until the task is done or a stop condition fires. This is the part people mean when they say "agent," and it is the part they most often over-build.

The mistake is handing the model too much freedom. A loop that can call any tool, in any order, for any number of steps, is easy to write and hard to trust. In regulated work, clinical intake, compliance checks, claims, the space of allowed action sequences is small and known. Encode it. A reasoning loop that can only move through states you have defined is easier to test, cheaper to run, and far easier to defend to an auditor.

Three decisions define this part. First, the stop condition: an agent without a hard step budget and a clear definition of "done" will loop, burn tokens, and occasionally spiral. Second, the planning strategy: a single pass with tool calls handles most real workflows, and you should reach for multi-step planning only when the task genuinely branches. Third, the handoff rule: the loop must know when to stop and pass control to a human, and it must do so before it acts, rather than after. Treat autonomy as a dial you turn up with evidence, starting low.

Part two: the tool layer

Tools are how the agent reads and changes the world: a database query, an API call, a lookup against a patient record, a booking. Without them a model can only talk. With them it can act, which is the entire point and also the entire risk.

The engineering here is contract design. Each tool needs a typed, narrow interface, a description the model can actually reason about, and validation on every input and output. A vague tool signature is the single most common cause of an agent that "hallucinates" a call: the model is guessing because the contract left room to guess. Constrain the arguments, return structured results, and make failures explicit so the loop can react to them.

Two things earn their keep in production. Idempotency: an agent will retry, so a tool that books an appointment twice on retry is a defect waiting to happen. And permission scoping: the agent should hold the narrowest credentials that let it finish the task, so that a bad plan cannot become a bad outcome. Under India's DPDP Act 2023, where a tool touches patient or personal data, that scoping is a legal obligation as much as an engineering one, and the tool layer is where you enforce purpose limitation in code.

Part three: memory and context

Memory is what the agent carries between steps and between sessions: the running state of the current task, retrieved documents, prior interactions, and the durable facts it is allowed to keep. Get this wrong in one of two directions and the agent degrades.

Too little memory and the agent forgets what it decided three steps ago, repeats tool calls, and contradicts itself. Too much, and you stuff the context window with stale detail, drive up cost, and bury the signal the model needs. The discipline is deciding what deserves to persist. Short-term working state belongs in the loop. Task-relevant knowledge belongs in retrieval, fetched fresh when needed rather than carried forever. Durable memory, the handful of facts worth writing back, belongs in a store with the same access controls as any other sensitive record.

For regulated deployments the retention question is not optional. If the agent remembers a patient interaction, someone has to answer how long it keeps that, on what basis, and how a data-principal request to erase it is honoured. Design memory as governed storage from the first commit, because retrofitting consent and retention into a system that already remembers everything is painful and sometimes not possible.

Part four: evaluation and observability (the one that gets skipped)

Here is the part most teams leave out, and the numbers confirm it is the last thing built. In LangChain's State of Agent Engineering 2025 survey of 1,340 practitioners, 89% reported some form of observability, but only 52.4% ran offline evaluations on test sets and 44.8% ran online evals against production traffic (LangChain, December 2025). Roughly half of teams are shipping agents they cannot systematically grade.

This layer has two jobs. Observability answers "what did the agent just do," through tracing that captures every step, tool call, input, and output so you can reconstruct any run after the fact. Evaluation answers "was that good," through test sets that catch regressions before release and online scoring that flags drift after it. You want both, because an agent that fails silently is worse than one that crashes: a crash pages someone, a wrong answer that looks right ships to a customer.

Build it with three habits. Trace everything from day one, because you cannot debug a multi-step failure you did not record. Keep a golden set of real cases and run it on every change, so a prompt edit that fixes one thing and breaks two others gets caught in CI rather than in the field. And use a mix of automated and human grading: LLM-as-judge scales the breadth, human review holds the line on the high-stakes calls where a confident wrong answer carries clinical or regulatory cost. This is the compliance-aware backbone that makes an agent accountable, and it is why we treat it as a first-class part of the system rather than a dashboard bolted on at the end.

How do the four parts fit together?

Think of them as one accountable unit. The reasoning loop decides, the tool layer acts, memory keeps the thread, and the evaluation layer watches all three and reports the truth. Remove any one and you still have something that runs. Remove the fourth and you have something that runs blind, which is the same thing as something you will eventually turn off.

The order matters too. Errors compound across steps, so a small mistake in the tool layer becomes a wrong final answer three hops later, and only tracing lets you find where it started. Building the fourth part last is defensible. Building it never is the pattern behind the cancellation rate.

At Nextdot we build agents this way for regulated industries, and our voice-first customer-experience agents run in production at Narayana Health and Gleneagles on exactly this four-part shape, with a further deployment in build at Fortis Mulund. Clients rarely ask for the evaluation layer in the first meeting. They tend to thank us for it around the twelfth.

Frequently asked questions