The parts of an agentic app, mapped

Open up a real agentic app, not the demo, the thing actually running in production, and you will not find one big function that 'is' the agent. You will find seven separate parts, each with one job, each replaceable without touching the rest: a model call, a tool layer, a loop that drives the two together, a memory system, an approval gate, a way to observe what happened, and an interface a person actually uses. What an AI agent actually is covered the idea itself: model, tools, memory, and a loop. This guide goes one level down, into how each of those pieces is actually built, and what breaks when one of them is missing.

Part 1: The model, kept swappable

The model is the part everyone thinks about first, and it should be the easiest one to change. In a well-built agentic app, the model is a single call behind a thin interface: send a prompt and a list of available tools, get back either a plain answer or a request to call one of those tools. Nothing else in the app should know or care which provider answers that call.

Treat that boundary as load-bearing. Wire your tool-calling logic, your loop, and your memory system to the exact shape of one provider's API, and swapping models later means rewriting the parts that were never supposed to change. Keep the interface generic, a prompt in, a structured response out, and swapping the model becomes a config change, not a rebuild. This matters for reasons beyond taste: prices move, rate limits hit, and a newer model gets meaningfully better at the one task your app depends on. You want to test that without touching anything else.

Part 2: The tool layer: definition, executor, boundary

Tools are where an agent stops talking and starts doing, and they are also where a badly built app does the most damage. The tool layer is not one thing, it is three, and conflating them is where most tool bugs start.

• The definition: what the model actually sees, a name, a plain description of what the tool does and when to use it, and a schema for its inputs. This is the model's entire picture of the tool. It never sees your code.
• The executor: the real function or API call that runs when the model asks for the tool. Your code owns this step completely; the model requests, it never executes.
• The boundary: the sandbox, permissions, and scope around the executor, what filesystem paths it can touch, what network calls it can make, what it is flatly not allowed to do, no matter what the model asks for.

Anthropic's engineering guidance on agents calls the interface between a model and its tools an agent-computer interface, ACI for short, and argues it deserves the same design effort a team would put into a human-facing UI: clear naming, unambiguous descriptions, input formats that are hard to get wrong.¹ A vague tool description does not just confuse the model occasionally, it produces wrong tool calls on exactly the inputs you never tested. Tighten the description before you touch the code underneath it.

The boundary is the part that is easiest to skip and the most expensive to skip. Anthropic's own recommendation is direct: test agents extensively in sandboxed environments, with guardrails matched to what the agent is actually allowed to touch.¹ A tool that can read files should not, by construction, also be able to delete them. Scope each tool to the one thing it does, and the blast radius of a bad tool call stays small no matter how confidently the model asked for it.

Part 3: The orchestration loop

The loop is the part that turns a model call into an agent. Anthropic draws the line here precisely: a workflow is a system where the model and tools run through code paths a person wrote in advance; an agent is a system where the model directs its own next step, using the result of its last action to decide what to do next.¹ Framed plainly, agents are just models using tools based on feedback from the environment, in a loop.¹

That loop is orchestration code you write, not something the model does on its own. It sends the current state to the model, reads back a plain answer or a tool request, runs the tool if asked, appends the real result, and checks whether to continue. Anthropic also flags the part teams tend to forget: because a loop can spin, retrying a broken plan or a stuck tool without ever converging, it needs both a natural stopping condition, the goal being met, and a hard limit, a maximum number of iterations, so a broken run ends instead of running until someone notices the bill.¹

Part 4: Memory: what is in the window, and what is on file

An agent's memory is really two different systems wearing one name. Short-term memory is the context window, the fixed amount of text the model can see on any single call: the goal, the tool definitions, and the transcript of everything the loop has done so far. It resets to nothing between separate sessions, and it fills up fast, since every tool call and its result gets appended back in before the next step.

Long-term memory is a separate store outside the window entirely, a file, a database, a vector index, that the app writes to on purpose and reads from only when a step needs it. The two are not interchangeable. Stuffing everything into the context window does not scale past a handful of steps; a long-term store that nothing ever reads back is just a write-only log. A working memory system decides, deliberately, what stays in the window for this step and what gets written out and fetched later.

Part 5: The human-in-the-loop layer

This is the part that decides whether a mistake costs you a moment or costs you something real. Anthropic frames it as a checkpoint: agents should be able to pause for human feedback at defined points or when they hit a blocker, rather than running straight through to a completed action.¹ Structurally, that checkpoint sits in one specific place: between the model requesting a tool call and your executor actually running it.

• Gate anything irreversible: sending a message, spending money, deleting a record, pushing a change live.
• Show the real inputs at the checkpoint, not a summary of them. 'Send an email' tells a reviewer nothing; the recipient, subject, and body do.
• Leave read-only tools ungated. A tool that only looks and cannot change anything does not need a human standing in front of it every time.

Part 6: Observability: logs, traces, evals

This is the part most first builds skip, and the part whose absence is felt hardest once something breaks in front of a real user. Hamel Husain's widely cited write-up on evaluating AI products puts the failure mode bluntly: unsuccessful products almost always share one root cause, a failure to build a real evaluation system, not a weaker model.²

In practice this is three separate habits stacked on each other. The cheapest is fast, code-level checks on individual steps, the kind of assertion you would write in an ordinary test suite. Above that is logging full traces, a record of the sequence of events in a run, the messages, tool calls, and results, in a form a person can actually read back and judge, model output against a person's own read of the same run. Above that is comparing versions of the app against each other on real traffic before deciding one replaced the other.² Skip all three, and a failure in production tells you only that something went wrong, never where.

Part 7: The interface

The interface is the only part a user ever sees, a chat window, a Slack bot, a command line, an API another program calls, and it is also the part most decoupled from everything else. The same model, tool layer, loop, and memory system can sit behind any of these; the interface's only job is turning a person's request into the input the loop expects, and turning the loop's output back into something a person, or another system, can use. Build the loop so it does not know or care which interface is calling it, and adding a second interface later is wiring, not a rebuild.

How a request actually flows through all seven

Put together, a single request moves through the stack in a fixed order, looping back through the middle as many times as the task needs before it returns.

Most of that sequence repeats. Steps three through seven run again and again, one per tool call, until the model produces a plain answer or the loop hits its step cap. The interface only shows up at the two ends, once to open the request and once to close it.

What each part does, and what breaks without it

Same seven parts, laid out by failure mode. This is the fast way to spot which one is missing when something in an agentic app goes wrong.

What you can skip, at least at first

Not every part needs to be production-grade on day one. Building the smallest working loop first, one tool, one model, a plain print statement for logging, is the right call; that is the whole approach in Build your first agent. What you can trim early:

• A swappable model interface. Hardcode one provider until you actually need to switch. The abstraction is cheap to add later and expensive to guess right in advance.
• A long-term memory store. For a short task that finishes in a handful of steps, the context window alone is enough. Add external memory once a real run outgrows it, not before.
• A full evaluation system. A handful of real example runs you check by hand beats nothing, and it is enough until the app has real traffic to learn from.
• Approval gates on read-only tools. If a tool only looks and cannot change anything, a human does not need to sign off on every call.

What does not get to wait: a step cap on the loop, and an approval gate on anything that sends, spends, deletes, or otherwise touches something you cannot take back. Those two are cheap to build and expensive to have skipped the one time they mattered.