Series · 55 parts
Inside AI agents
A plain-English walk through what an agent is made of and how it actually runs.
- 01What is actually inside an AI agentAlmost everything gets called an AI agent right now. A chatbot with a system prompt. A script that calls an API. A workflow with a language model somewhere in the middle. The word has stretched…Read
- 02How an AI agent actually runs: the agent loopThe previous piece covered what an AI agent is made of. This one covers how it runs, because the mechanism is simpler and stranger than most explanations suggest.Read
- 03Do you actually need an agent?Two questions settle this, and the order matters. Does the task need a language model at all? If it does, can you write the steps down in advance?Read
- 04Fix your yardstick before you build the agentBuilding an agent is a loop: ship a version, watch it fail, work out why, fix that, repeat. The loop only turns if you can tell whether the last change made things better.Read
- 05Why LLMs have no memory (and what that costs you)An agent is a loop that keeps asking a model what to do next. That was the previous piece. This one is about the strangest property of the thing sitting at the centre of that loop.Read
- 06Four things to test before you pick a modelModel comparisons usually come down to two numbers: a benchmark score and a context window. Both fit neatly on a slide, and both leave out what decides whether the thing can run an agent.Read
- 07How an agent remembers what you saidA chat with an AI feels continuous. You give your name, and ten messages later the assistant still uses it. The mechanism behind that feeling is one list that you keep on your own machine and send…Read
- 08One interface, many modelsEvery provider ships its own client library, its own message shape, and its own names for the same ideas. Write against one directly and the provider's vocabulary spreads through your codebase,…Read
- 09Two things separate a working demo from a working systemThe demo always works. One call, a good answer, everyone is impressed.Read
- 10Writing a prompt that makes an agent actAsk a chatbot with a search tool what the weather is in Dubai, and a well-behaved one might reply: "Would you like me to search for that?"Read
- 11Two numbers to record when you test a modelYou have twenty questions with answers you already know, each one labelled with the capability it needs. Most of them require looking something up: how many of last quarter's 412 tickets were…Read
- 12Why a language model needs tools to become an agentTwenty questions, tools switched off, and a ceiling of five. The first eleven posts in this series have been circling one claim without proving it: a model on its own cannot do the job, and tools…Read
- 13A tool schema is a user interface, and your user is the modelA tool is a function plus a schema. The function does the work, and the schema is the part that decides whether the work ever happens.Read
- 14Building your first real toolThe ticket question needs two capabilities: something that reads our export, and something that looks up a current price. Time to build the first one properly.Read
- 15The complete tool-calling loop, end to endPart 12 showed the shape of the loop to make a point about why agents exist. This post writes the whole thing out, including the parts that only matter once you run it.Read
- 16MCP, and the problem it actually solvesBuilding one tool takes an afternoon. The trouble starts later, and it arrives in four stages.Read
- 17Run one MCP server, write a client, then build your ownPost 16 covered what MCP is and why it exists. This one is the build, in three moves: run a server, write a client that talks to one, then turn our own function into a server.Read
- 18What ReAct actually isThe loop we built a few posts ago has a name. The pattern is called ReAct, short for reason and act, and it sits underneath most agents you will meet.Read
- 19Why an agent needs more than a message listFor a chatbot, the state is a list of messages. We built exactly that earlier in this series: you keep the list, append to it, and re-send it every turn.Read
- 20One interface for every toolBy now our agent has tools from a few different places. Plain Python functions we wrote. Tools from an MCP server. Provider built-ins. Each has its own shape.Read
- 21The LLM layer, in three objectsEarlier in this series we put provider differences behind one adapter, so switching model vendors is a config change. This post solves a different problem, and it is worth being clear about the…Read
- 22Assembling the agent: run, step, think, actWe have state, a uniform tool interface, and an LLM layer. Each was built to serve one small loop, and this is the post where they meet.Read
- 23Getting structured output out of an agentEarlier in this series we got a typed object out of a single model call by passing a schema as the response format. That worked because it was one call in, one shaped object out.Read
- 24Measuring the difference tools makeWay back in this series we built a yardstick: twenty questions with answers you already know, each labelled with the capability it needs. Then we ran a model against it with the tools switched…Read
- 25Why an agent needs a knowledge baseThe agent we built can search the web. Plenty of real questions have answers the web never held: an internal wiki, a project's code, a spreadsheet a customer attached to a ticket.Read
- 26Four ways to search, and when each one winsRAG is what its name says: retrieve the relevant data, then let the model generate an answer from it. The generate half we have. This post is about the retrieve half, which has more than one method.Read
- 27Embeddings and chunking, the two ideas behind vector searchVector search sounds like machine-learning machinery. Underneath it are two plain ideas, and once they click, the build in the next post is short.Read
- 28Building vector search, and why you need a vector databaseWe have the two ideas: embeddings turn text into points, chunking cuts documents into pieces worth embedding. Vector search is what you get when you put them together.Read
- 29Giving an agent a filesystem to exploreVector search is the right tool for a pile of unstructured text. Plenty of data is not a pile. A codebase, a folder of reports, an extracted zip already carries an index in its own layout.Read
- 30Extending an agent without touching its coreThe agent from chapter 4 runs tools and returns results. Real deployments keep asking for more: pause for approval before a risky tool, shrink a huge search result before it floods the context,…Read
- 31The two things an agent forgetsThe agent we built keeps a running list of everything that happens, sends it to the model each step, and throws it all away when the run ends. That works for a one-shot question.Read
- 32Storage versus presentation, the idea behind context managementBefore any trick for shrinking the context, one idea has to be in place, and everything else is built on it.Read
- 33Four ways to keep an agent's context smallThe record is safe and tokens are counted. Shrinking the view for a call is now a matter of strategy, and there are three that matter, plus a rule for choosing between them.Read
- 34Giving an agent sessions, so it remembers the last turnOur agent handles one question well and forgets it instantly. Ask "set the deadline for Project Alpha", then "update the progress", and the second call has no idea which project you meant, because…Read
- 35Pause and resume, a durable human-in-the-loopEarlier we built an approval gate: before a dangerous tool runs, ask a person y or n. That version blocks. The agent sits and waits on input() while the human decides.Read
- 36Long-term memory, what an agent keeps across sessionsA session carries a conversation from one turn to the next. Start a new conversation, with a new session, and the agent is a stranger again. Yesterday's "I work in marketing" is gone.Read
- 37Building long-term memory with a vector storeThe previous post extracted the durable facts from a run and shaped them. This post stores them and gets them back later, and the machinery is one you already built.Read
- 38Why a ReAct agent gets lost, and the fixThe agent we built is a ReAct agent: look at the situation, pick the next tool, read the result, pick the next tool. That loop is wonderfully adaptable. A search comes back thin, it tries…Read
- 39Planning, giving an agent a plan to followA plan is the map a ReAct agent lacks. This post gives the agent one, and the pleasing part is that it needs no new machinery at all.Read
- 40Reflection, teaching an agent to check its own workA plan sets direction. Reflection checks whether the agent is still on it.Read
- 41Putting planning and reflection togetherPlanning and reflection each help on their own. Together they form a loop, and the loop is the real subject of this chapter.Read
- 42Why give an agent a computerEvery tool we have built is a function you wrote in advance. The agent can search, read a file, run a query, because you anticipated those needs and coded them.Read
- 43Running an agent's code in a sandboxThe last post gave the agent the ability to write code. This post gives it a safe place to run it, because running model-generated code on your own machine is not something you do twice.Read
- 44Porting your tools into the sandboxThe agent can run code and it can call tools. This post joins the two, so the agent can call your tools from inside its code.Read
- 45Giving an agent a workspace, a filesystem and a command lineA sandbox runs a snippet of code and returns the output. A workspace is more: a sandbox with a filesystem that persists across steps and a command line, so the agent has a small computer to work on.Read
- 46Agent skills, and loading what you need when you need itWe started this chapter noting that too many tools make an agent worse: a long prompt, and a model overwhelmed by options. A workspace helped, but a capable agent still needs to know about many…Read
- 47When one agent should become manyEvery agent we have built is one agent: one system prompt, one set of tools, one loop. Push enough different work through it and the strain shows.Read
- 48Orchestrating agents in code, workflows of specialistsThe first collaboration pattern is the one you control completely. When the order of work is predictable, you write it in code rather than letting the model decide.Read
- 49Agent as a tool, calling one agent from anotherA workflow works when you know the order. When you do not, the orchestrator has to pick the specialist at runtime, and the cleanest way to let it is one you already know: make each specialist a tool.Read
- 50Agent transfer, handing off control instead of callingThe last pattern kept the orchestrator in charge: it called a specialist, got a result, and carried on. Transfer is the other choice. Control moves to the specialist, which takes over the…Read
- 51A2A, agents talking across the networkEvery pattern so far runs agents in the same process. A2A, agent-to-agent, is for when they do not: agents on different machines, in different systems, talking over the network.Read
- 52You can't evaluate what you can't see, agent observabilityThe final stretch of this series is about evaluation: knowing whether your agent is any good. That starts one step earlier, with being able to see what the agent did at all.Read
- 53What to actually evaluate in an agentEarly in this series we built a yardstick: a set of questions with answers you know, to measure whether a change helped. That works, and evaluating a full agent needs more, because an agent is…Read
- 54LLM-as-a-judge, grading agents with a modelYou have a dataset and rubrics. Grading every run against those rubrics by hand works for ten cases and collapses at a thousand.Read
- 55Evaluation-gated deployment, and the quality flywheelAn evaluation you run occasionally and glance at changes nothing. Evaluation earns its keep when it sits between a change and production, and decides whether the change ships.Read