# How to Build an AI Agent: The Pieces You Have to Construct > How to build an AI agent: the pieces you have to construct, why the prototype is easy and the reliable system is not, and when not to build it yourself. - Canonical: https://arkatai.com/en/how-to-build-an-ai-agent/ - Site: Arkatai (https://arkatai.com) — agentic operations as a service - Language: en - Published: 2026-07-19 --- Building an AI agent that impresses in a demo takes an afternoon. Building one you would trust to touch your billing without watching it every day takes months and never quite ends. This page is about the second, which is the only one that matters in a company: which pieces you actually have to construct, why the jump from prototype to reliable system is so large, and how to decide whether that work is yours to do or not. This is not a code tutorial. It is the anatomy of the work, so an executive understands what they are buying — or what they are committing to maintain — when someone says "we'll build an agent". If you are coming in without the basics, start with [what is an AI agent](/en/what-is-an-ai-agent/) and the [business pillar](/en/ai-agents-for-business/). ## The pieces you have to construct An agent that operates is not a model with a good prompt. It is five pieces you have to construct, connect and maintain, and each one is a real front of work. **The instructions.** This is the most underrated piece and the most yours. A generic model does not know your rules: what counts as a valid case, what tolerance you apply, what to do with a deviation, when to stop. All of that has to be made explicit and written so the agent applies it the same way every time. If a process lives only in the heads of two people, the first job is not technical, it is getting it out of those heads. I have written about how that definition gets encoded in [operating model as code](/en/operating-model-as-code/). **The tools.** The concrete actions the agent will be able to execute: check stock, issue the invoice, read the inbox. Each has to be built and given explicit permissions for what it reads and what it writes. The ceiling on what an agent can do is set by the tools you gave it. **The integrations.** Connecting those tools to your real systems — your ERP, your CRM, your mail, your databases — is where much of the effort goes. It is not glamorous and it is where most projects get stuck, because a real company's systems have dirty data, fields that mean different things depending on who filled them in, and exceptions no one documented. **The evaluation.** Before the agent gets real work, you have to measure how it performs: test cases with known answers, quality thresholds, failure review. Without this you have no serious way to say it works, only an impression. And evaluations are not built once, they are re-run every time the model or the process changes. **The controls.** Where the agent stops, what it escalates to a person, what gets recorded of each decision. This piece is the one a board looks at before approving anything and the one that turns a powerful system into an approvable one. The full framework is in [AI agent governance](/en/ai-agent-governance/). These five pieces fit into a wider architecture as the system grows, which I break down in [AI agent architecture](/en/ai-agent-architecture/). The model, by the way, barely appears on this list: it is the piece you buy through an API and swap without drama. What you build is everything around the model. ## Why the prototype is easy and the reliable system is not The costliest misunderstanding is believing the distance between the demo and production is a matter of "polishing". It is not: they are two different things. A prototype only has to work on **the happy path**: the normal invoice, the well-formed order, the customer who asks what they are expected to ask. That is quick to put together today, which is why there are so many dazzling demos. The problem is that a real operation does not live on the happy path, it lives on **exceptions**: the new supplier, the odd amount, the missing delivery note, the customer asking three things at once and one of them as a complaint. The real work — and 80% of the effort — is making the agent handle that long tail of odd cases without breaking and without doing something foolish with full confidence. On top of that, an agent is probabilistic and can go wrong in ways a classic program cannot, producing a plausible but incorrect result. I explain that mechanic in [how do AI agents work](/en/how-do-ai-agents-work/). Containing that error demands the evaluations, the escalation and the trace above, which add nothing to the demo and everything to reliability. And there is a third trap. The system does not stand still. Models change, your processes change, your systems change. An agent without maintenance degrades like any machine without it. That is why building an agent is not a project with an end date, but a capability you have to sustain. It is exactly this underestimation that fills the shelves with dead pilots, a pattern I analyze in [why enterprise AI pilots fail](/en/why-enterprise-ai-pilots-fail/). ## Build it yourself or not: the real criterion This is where an experienced operator saves you money. The question is not "can it be built?" — it almost always can — but "does it make sense for you to build and maintain it?". And that turns on one thing, whether you do or do not have a product and technology function able to sustain agents, evaluations, integrations and model changes at the pace this field moves. Three paths, with their truth: - **Build in-house.** Full control in exchange for creating and retaining a technical team that maintains the system forever. For a company with real product capability and a very specific process, it makes sense. For most mid-sized firms, it is a new function with a fixed cost and a turnover risk that gets underestimated at the start. - **Buy platforms** per function. Solves bounded cases, but your process adapts to the product and integrating the pieces remains your job. - **Contract the operation.** Someone else operates and maintains the system and you buy the outcome, and the demand shifts to the contract: measurable outcome, permissions, traces and a clean exit. There is no universal answer, there is one that fits your case. The full analysis, with the criteria I use, is in [buy vs build for enterprise AI](/en/buy-vs-build-enterprise-ai/), and who executes each option — in-house team, consultancy or boutique — in [that comparison](/en/inhouse-consultancy-or-boutique/). One test settles it fast. If the answer to "who will re-run the evaluations when the model changes in three months?" is silence, you are not ready to build in-house yet. Before deciding, it is worth the look at your own house I gather in [prepare your company for agents](/en/prepare-your-company-for-agents/). ## Frequently Asked Questions ### What do you need to build an AI agent? Five pieces built and connected: instructions with your rules and limits, tools to act on your systems, integrations with your ERP and other platforms, evaluations that measure quality, and controls that set where it stops and what it escalates. The model barely counts, it is bought through an API. What you build is everything around it. ### Is it hard to build an AI agent? A prototype that works on the normal case is not hard, it comes together fast. A reliable agent for production is, because the effort goes into handling exceptions, measuring quality, integrating with real systems, and maintaining it all when the model and the process change. The demo is the easy part, sustained reliability is the actual job. ### How long does it take to build an AI agent? A prototype, hours or days. A system that operates reliably on a real process, months, and then it never ends. It needs continuous maintenance because models, processes and systems change. Treating it as a project with a closing date is the mistake that kills the most pilots. ### Should I build the agent myself or contract it? It depends on whether you have a product and technology function able to maintain agents, evaluations and integrations at the pace of the field. If you have it and the process is very much yours, building in-house makes sense. If not, buying platforms or contracting the operation avoids creating a technical function you cannot sustain.