Google shipped a free one-hour "build an agent in 2026" course this month and it spread across every founder timeline, because the promise is real: the parts of an AI agent are few, and none of them are magic. Strip any framework — LangGraph, the Claude Agent SDK, whatever's trending — and the same five parts are underneath. Here they are, in the order you should build them, and the one almost everyone skips.

The five parts, in one screen#

  1. The loop — call the model, run the tools it asks for, feed the results back, and repeat until it stops. Mechanically, a while loop keyed on the response's stop reason. This is what makes it an agent and not a chatbot.
  2. Tools — the agent's hands: the actions it can take, exposed as function calls or an MCP server, each described well enough that the model reliably picks the right one.
  3. Context — what you put in the finite window every turn, plus the memory that lives outside it. The scarcest resource in the whole system, because a model's recall degrades as the window fills.
  4. Guardrails — defense-in-depth against prompt injection, runaway spend, and unsafe actions. An agent that can act can act wrongly, and at machine speed.
  5. Evals — the measurement that tells you whether any change you made left the agent better or worse. This is the one that gets skipped.

That list is the whole field. Everything below is detail on each part and why the last one is the one that decides whether you have a product or a demo.

1. The loop is five lines#

The core is genuinely small: send a message with a tools array, get back a request to call one, run it, send the result back, repeat until the model returns a final answer instead of another tool call. Every framework wraps exactly this. You can build it from scratch with no framework in an afternoon, and doing so once is the fastest way to understand what the frameworks are hiding. The interesting choices are architectural, not mechanical: a plain ReAct-style loop versus plan-and-execute versus reflexion, and deterministic versus model-driven orchestration once more than one agent is involved.

Start with one model, in one loop, with good tools. Add complexity only when an evaluation proves you need it — which means you need the evaluation first.

2. Tools are the agent's hands#

A model with no tools can only talk. Tools are what let it do — search, write a file, call your API, hit a database. The engineering that matters is description quality: the model chooses a tool from its name, its docstring, and its schema, so a vague tool is a tool the agent misuses. In 2026 the default way to expose them is the Model Context Protocol, which turns "my tools" into a server any agent can connect to — and raises its own question of when a capability should be an MCP server versus an Agent Skill. Whichever you pick, trace the tool calls — you can't fix what you can't see.

3. Context is the resource you're actually managing#

The single most consequential principle in agent engineering is that the context window is a finite budget you curate, not a bucket you fill. Recall rots as the window grows — the model gets worse at using information that's technically still in front of it — so the job is keeping the right things in and the noise out. That's three moving parts: the memory that lives outside the window and gets pulled in on demand, the caching and editing that keep the per-turn bill and the window under control, and the choice to isolate work in subagents instead of editing one growing transcript. Get this wrong and the agent gets dumber the longer it runs.

4. Guardrails, because an agent can act wrongly#

The moment an agent has tools, it has a blast radius. Guardrails are the defense-in-depth layer: input filtering against prompt injection, spend caps so a loop can't run your bill to zero, and a human in the loop on the actions you can't take back. This is a layer, not a checkbox — the guardrail libraries differ on where they enforce, and the cheapest one to skip is the one you'll wish you had after the first incident.

5. Evals — the part you can't see, so you don't build it#

Here's the pattern. The first four parts are visible in the demo: the loop runs, the tools fire, the context holds, the guardrails block the obvious attack. So they get built. Evals produce nothing in the demo — they're the harness that scores the agent against known cases and tells you whether your next prompt tweak, model swap, or tool change helped or hurt. Skip it and you're optimizing by vibes: every change is a guess, and you discover regressions when a customer does.

Anthropic's own guidance names this directly — start with the simplest architecture that works and add complexity only when evaluations prove it necessary. That instruction is impossible to follow without an eval harness, which is why "start simple" and "build your evals early" are the same advice. It doesn't have to be elaborate: a handful of scored test cases — judged by a model, by checking the agent's tool use, or by scoring the whole multi-agent run — plus the tracing to see why one failed, beats zero by an infinite margin. Zero is what most first agents ship with.

Build them in order#

The five parts are a build order, not a menu. Loop first, then one good tool, then the context discipline that keeps it sharp over a long run, then the guardrails its blast radius demands — and the eval harness alongside all of it, because that's the part that lets you improve the other four on purpose. A model in a loop with good tools is a demo you can build this week. The eval harness is what tells you, next week, whether you made it better.