AI agents — from answering to doing

01What makes an AI “agentic”

The word gets thrown around; here is the honest line. A normal LLM call is one shot: question in, answer out, done (Chapter 6). An agent is that same model placed inside a loop, given tools it can use and a goal to reach — and allowed to take several steps, deciding each one for itself, until the goal is met. The shift is from “answer this question” to “achieve this outcome, using whatever steps it takes.”

The everyday example: ask a plain model “what’s the fee plus the hostel deposit?” and it might do the arithmetic in its head and get it subtly wrong (Chapter 5 — it predicts tokens, it does not truly calculate). Give it a calculator tool and a loop, and it will choose to use the calculator, get the exact number, and answer correctly. It did not just respond — it acted.

02Tool calling — the key mechanism

How can a model that only outputs text do anything? Through a beautifully simple trick called tool calling (or function calling). You describe to the model, in words, a set of tools it may use — each with a name and what it does: “a tool called search_notices that takes a query and returns matching notices.” Now, instead of answering, the model can reply: “I want to use search_notices with the query ‘hostel fees’.”

And here is the part that surprises everyone: the model does not run the tool — your code does. The model only asks to use a tool; your program sees that request, actually runs the real function (this is Chapter 3 territory — your backend, your database), and hands the result back to the model. The model reads the result and continues. The model is the decider; your code is the hands. Once you see that split, agents stop being mysterious — they are your Chapter 3 backend, with an LLM choosing which functions to call.

03The loop — think, act, observe

Put tool calling in a loop and you have an agent. Step through the cycle it runs, over and over, until it has what it needs:

That is the entire engine: think (the model decides the next step), act (your code runs the chosen tool), observe (the result goes back to the model), repeat. RAG from Chapter 10 is really the simplest agent — one forced tool call (retrieve) before answering. A full agent just gets to choose its tools, and to loop. Same DNA, more freedom.

04What tools actually are

A tool is just a function your code exposes to the model — and it can be anything your backend can do. Search the web so the model escapes its knowledge cutoff (Chapter 5). Query your database (Chapter 4) to answer from live data. A calculator for exact maths. Send an email, create a ticket, book a slot — real actions in the real world. This is also where MCP from Chapter 2 clicks fully into place: MCP is a standard way to hand an AI a menu of tools, which is exactly what an agent needs. The same protocol that gave Claude Code its abilities gives your agent its abilities.

05Multi-agent systems — a team of specialists

One agent trying to do everything gets confused, the same way one giant 2000-line file does (Chapter 2). So a powerful pattern from Day 14: use several specialised agents that collaborate, each with a narrow job and its own small tool set.

A router (or orchestrator) reads the request and sends it to the right specialist — a “fees” agent, a “timetable” agent, a “general” agent. Each specialist has a focused system prompt and only the tools it needs, so each does its one job well. You can even add a reviewer agent that checks another’s work before it ships — automated quality control. It is the same idea that runs good human teams and good software (Chapter 1): break a big job into focused roles with clear handoffs. Architecture, all the way down.

06Agency raises the stakes — and the danger

Now the sober part, and it is the most important paragraph in this chapter. A model that only writes text can, at worst, write something wrong. A model that can act can do something wrong — delete data, send a bad email, spend money. Remember prompt injection from Chapter 7? On a text bot, the worst it does is produce a weird answer. On an agent with a “delete record” tool, a successful injection could make it actually delete records. Agency multiplies both usefulness and blast radius.

So the non-negotiable rules, all built from earlier chapters. Least privilege: give an agent the fewest, narrowest tools that do the job — never a raw “run any database command” tool when “look up a fee” will do. Human in the loop for anything dangerous: irreversible actions — sending money, deleting, emailing a customer — should propose and wait for a human’s yes, not fire automatically. And every tool validates its own inputs (Chapter 3), because now the “user” calling your function is a sometimes-wrong model. Build agents like you are handing car keys to a talented teenager: real capability, real supervision.

07Do this today

Give your notice board a tiny agent. Define two tools your backend already has — search_notices(query) and calculate(expression) — and describe them to the model. Then ask a question that needs both: “What’s the total if I pay the tuition fee and the exam fee?” Watch the loop: the agent searches the notices for each fee, calls the calculator to add them, and answers with the exact total — choosing those steps itself. Keep both tools read-only and harmless, exactly as section 06 preaches, and you have safely built a real agent.

You have now seen the whole ladder — a model that answers, that answers from your data, and that acts. One chapter remains, and it is the one that turns any of this from a clever demo into something you can actually put in front of real users without fear.