17 June 2026
AI ENGINEERING · UPDATED JUNE 2026
A practical breakdown of what actually goes into a production-grade AI agent, and where most first attempts go wrong.
An AI agent, in the sense engineers mean today, is a system built around a large language model that can take actions rather than just produce text. It decides what tools to call, retrieves information it doesn't already know, holds context across multiple steps, and in more advanced setups, coordinates with other agents to complete a task. The gap between a weekend prototype and something that survives contact with real users is almost entirely in four areas: retrieval, tool use, state, and evaluation. Each is worth understanding properly before you start writing code.
A language model's knowledge is frozen at training time and generic to the whole internet. RAG solves the obvious problem this creates for business use: the model has no idea what's in your contracts, your wiki, or your support tickets. The pattern is simple in outline and easy to get wrong in practice.
At a basic level, RAG works by splitting your documents into chunks, converting each chunk into a vector embedding, and storing those vectors in a vector database such as Pinecone, Weaviate, Qdrant, or simply Postgres with the pgvector extension. When a user asks a question, you embed the query the same way, search for the nearest chunks by vector similarity, and stuff the most relevant ones into the model's context window alongside the original question. The model then answers using that retrieved context rather than its own memory.
The part most teams get wrong is chunking strategy. Splitting documents by a fixed character count regardless of structure produces chunks that cut sentences in half or separate a heading from the content it introduces, which quietly degrades retrieval quality in a way that's hard to notice until you're debugging why the agent keeps giving slightly-wrong answers. Splitting by semantic boundaries, paragraph structure, or document section is more effort upfront but produces noticeably better results. The second common failure is retrieving too few or too many chunks: too few and the model lacks context, too many and the model dilutes its attention or runs into context window limits. Most production systems land between 3 and 8 retrieved chunks per query, tuned empirically against real questions.
More advanced RAG setups use re-ranking (a second, more precise model scores the initially retrieved chunks before they go to the main model), query rewriting (the model first rewrites a vague user question into something more retrievable), or hybrid search that combines vector similarity with traditional keyword search — useful because pure vector search sometimes misses exact terms like product codes or names that don't carry strong semantic meaning.
Tool use, sometimes called function calling, is what turns a chatbot into an agent. You define a set of functions — query a database, call an internal API, send an email, search the web — and describe each one to the model in a structured format. The model decides, based on the user's request, which function to call and with what arguments. Your code then executes that function and returns the result to the model, which incorporates it into its next response.
The reliability of tool use depends heavily on how well you describe each tool. A vague description (“searches stuff”) produces unreliable tool selection; the model genuinely cannot tell when to use it. A precise description with a clear purpose, well-typed parameters, and example use cases produces dramatically better tool-calling accuracy. This is one of the most underrated levers in agent reliability — most debugging sessions for “why does my agent keep calling the wrong tool” end with rewriting the tool description, not changing the model.
The second major design decision is how much autonomy to give the agent over chaining tool calls together. A simple agent calls one tool, gets a result, and responds. A more capable agent loops: call a tool, evaluate the result, decide whether another tool call is needed, and continue until the task is done or a limit is reached. This loop is where most production incidents happen — infinite loops where the agent keeps calling tools without making progress, usually because it can't tell the task is actually finished, or because a tool returned an error it doesn't know how to handle. Setting a hard maximum number of iterations and building explicit “give up gracefully” paths is not optional for anything you intend to run unsupervised.
As tasks get more complex, a single agent juggling research, writing, and verification in one context window tends to perform worse than several specialised agents each doing one thing well. A common pattern is an orchestrator agent that breaks a task into sub-tasks and delegates each to a specialist agent — one that's good at research, one that's good at drafting, one that checks facts — then assembles the results. Frameworks like LangGraph and CrewAI provide scaffolding for this, modelling the system as a directed graph of agents passing state between them rather than a single linear chain.
The trade-off is real: multi-agent systems are more capable but harder to debug, slower (more model calls), and more expensive to run. The right default for most teams is to start with a single, well-tooled agent and only split into multiple agents when you can point to a specific failure mode that decomposition would fix — not because multi-agent architectures sound more sophisticated.
Within a single conversation, state is usually just the message history passed back to the model each turn. The harder problem is memory that persists across sessions — remembering a user's preferences, a project's context, or facts established days earlier. The common approaches are storing structured facts in a database and retrieving relevant ones at the start of each session, or treating memory itself as a RAG problem: embedding past interactions and retrieving the most relevant ones when needed. Neither is solved cleanly yet industry-wide; expect to design something bespoke to your use case rather than reaching for an off-the-shelf answer.
The single biggest gap between hobby projects and production agents is testing discipline. Because LLM outputs are non-deterministic, traditional unit tests don't map cleanly onto agent behaviour. The practical approach is building a set of golden test cases — representative inputs with known-good outputs or acceptance criteria — and running them automatically whenever you change a prompt, a tool, or a model version. Tools like LangSmith, Langfuse, and Helicone exist specifically to trace agent runs, log every tool call and model response, and flag regressions. Skipping this step is the single most common reason agent projects that work in a demo fail in production: nobody is watching for the slow drift in behaviour that happens as prompts get tweaked over months.
MCP is an open standard, originating from Anthropic, for connecting agents to tools and data sources in a structured, secure way. Rather than every team inventing its own bespoke way for an agent to call a database or an internal API, MCP defines a common server architecture with built-in concepts for tool discovery, scoped permissions per tool, and audit logging. It's worth understanding even if you're not using Claude specifically, since the pattern of well-defined, permissioned, auditable tool access is good practice regardless of which model sits behind it, and is the direction much of the industry is converging on for production agent architecture.
If you're building this for yourself, the fastest path to competence is picking one real, narrow use case — not “build an agent that does everything” — and working through retrieval, tool use, and evaluation in that single context before generalising. If you'd rather have a structured, hands-on path with an instructor and immediate feedback on your specific implementation, JBI Training runs several courses that cover this ground directly:
JBI Training delivers instructor-led AI and technology training to corporate teams across the UK and internationally, virtually and face-to-face.
CONTACT
+44 (0)20 8446 7555
Copyright © 2025 JBI Training. All Rights Reserved.
JB International Training Ltd - Company Registration Number: 08458005
Registered Address: Wohl Enterprise Hub, 2B Redbourne Avenue, London, N3 2BS
Modern Slavery Statement & Corporate Policies | Terms & Conditions | Contact Us
POPULAR
AI training courses CoPilot training course
Threat modelling training course Python for data analysts training course
Power BI training course Machine Learning training course
Spring Boot Microservices training course Terraform training course
