How to Build an AI Agent in 2026: The Five Parts Nobody Explains

Toolradar data: we track 341 MCP servers, 83% published by vendors on their own domains and 30% free. That matters here because tools are one of the five parts of any working agent, and in 2026 tools means MCP.

Every working AI agent is the same five parts, and most tutorials only cover two of them. This is the full list, in the order that produces something deployable rather than a demo, plus the three mistakes that produce demos instead of products.

The five parts

1. A bounded job. The single best predictor of whether an agent ships is whether its job fits in one sentence with a verifiable outcome. "Answer refund questions using our policy docs" ships. "Handle support" does not. Write the sentence first; it is the spec, and if you cannot write it, you are not ready to build.

2. Tools, which now means MCP. An agent acts through tools, and in 2026 the standard way to expose them is the Model Context Protocol: write one server, and every MCP-speaking client can use it. Of the 341 servers we track, 83% are official vendor implementations, so check whether the tool you need already has a server before writing glue. If you need your own, our tutorial covers it.

3. Memory, decided deliberately. The default is no memory beyond the conversation, and for many jobs that is correct. Add state only when the job requires it, and prefer boring storage: a database row the agent reads and writes beats a vector store you cannot inspect. Retrieval is for knowledge; state is for work in progress; conflating them is the classic architecture mistake that produces agents which forget what they are doing and hallucinate what they knew.

4. A loop with an exit. The agent plans, acts, observes, and repeats. The part tutorials skip is the exit: a maximum step count, a budget ceiling, and an explicit "escalate to human" action. An agent without an exit condition does not fail loudly, it fails expensively, looping until it hits a rate limit or an invoice.

5. Evaluation, before launch, not after. Build a test set of twenty real cases while you build the agent, and score every change against it. Promptfoo, DeepEval and Langfuse make this mechanical; the discipline of maintaining the cases is the actual work. Our evaluation guide compares the tooling.

The build order that works

Job sentence, then the tools, then the loop with its exits, then evaluation, then memory last and only if needed. Teams that start with memory and orchestration build infrastructure for an agent that never ships. Teams that start with the job sentence ship in weeks and add sophistication only where the eval scores say it is needed. The order is not stylistic, it is what keeps you from building capacity for a product that does not exist yet.

The three mistakes that produce demos

Unbounded scope. Impressive-in-a-demo and reliable-in-production are opposite optimisation targets. A demo rewards breadth; production rewards a narrow job done every time. The agent that wows a stakeholder meeting is usually the one that cannot ship.

No approval gate. The first irreversible action your agent takes wrongly is the last day anyone trusts it. Any action that sends, charges, deletes or publishes needs a human in front of it until the eval scores earn the gate being removed.

Skipping evals. Without a test set, every model update is a gamble on your product, and model updates now arrive monthly. The twenty-case test set is what turns "the new model broke something" from a customer report into a pre-deploy red line.

When not to build

If the job is a fixed sequence of steps, you want workflow automation, not an agent: cheaper, deterministic, debuggable. If the job is "be generally helpful", you want an existing assistant with MCP servers attached, not a build. The build is justified only when the job is bounded, judgement is genuinely required inside it, and volume makes a human loop expensive. Two of three is not enough.

FAQ

Which model should the agent use?

The one your eval set says is sufficient, which is usually smaller and cheaper than the one you assumed. This is precisely what the test set is for: it lets you buy the cheapest model that passes rather than the most capable one you can afford.

How long does this take?

A bounded agent with tools, exits and evals: two to four weeks to production for a small team. Anything promising faster is describing the demo, not the product.

Build or buy?

Buy when a knowledge-work agent already does the bounded job. Build when the job is specific to you and no product fits it.

Related

See AI agent orchestration for when one agent becomes several, and the infrastructure stack for what production needs underneath.