# AI Agents, Explained Visually: The Agent Loop, Tools, Memory, RAG, Multi-Agent | Koso Learn

> A visual guide to AI agents: the think-act-observe loop, tool and function calling, agent memory, ReAct and plan-and-execute, multi-agent teams, the full RAG pipeline, guardrails and evals, and when an agent is the wrong choice. Every architecture drawn as a diagram.

[](/)

[Services](/#services)[AI OS](/ai-os)[Training](/training)[Education](/education)[Agents](/agents)[Learn](/learn)

…

[Book a call ](/book)

1. [Home](/)
2. [Learn](/learn)
3. AI Agents

Chapter 03 · Builder

# AI agents.

Chapters 1 and 2 gave you an engine and the craft of steering it. This chapter puts the engine in a loop, hands it tools and memory, and builds it into systems that do real work. Then it covers the guardrails that make those systems trustworthy, and the honest test for when you shouldn't build one at all.

8 sections · about 26 minutes · a diagram in every section

In this chapter

1. [01The agent loop: think, act, observe](#loop)
2. [02Tool use: hands for the model](#tools)
3. [03Memory: what agents remember](#memory)
4. [04Planning patterns: ReAct and plan-and-execute](#planning)
5. [05Multi-agent teams](#multi-agent)
6. [06RAG: retrieval-augmented generation](#rag)
7. [07Guardrails, evals and humans in the loop](#guardrails)
8. [08Agent or workflow? Choosing honestly](#agent-or-workflow)

Chapters

[01 · How LLMs Work](/learn/how-llms-work)[02 · Prompt Engineering](/learn/prompt-engineering)[03 · AI Agents](/learn/ai-agents)

In this chapter
1. [01The agent loop: think, act, observe](#loop)
2. [02Tool use: hands for the model](#tools)
3. [03Memory: what agents remember](#memory)
4. [04Planning patterns: ReAct and plan-and-execute](#planning)
5. [05Multi-agent teams](#multi-agent)
6. [06RAG: retrieval-augmented generation](#rag)
7. [07Guardrails, evals and humans in the loop](#guardrails)
8. [08Agent or workflow? Choosing honestly](#agent-or-workflow)

03.1

## The agent loop: think, act, observe

An **agent** is a language model given a goal, a set of tools, and permission to keep going: decide a step, take it, read the result, decide again. The chat interface answers you once; the agent stays on the job until it's done, or until it hits the budget you gave it.

the goal“find me 3 venues under $2k”thinkengine picks the next moveactcall a toolobserveread the resultrepeat until done✓?done?goal met, or budget spentthe answer3 venues, booked links, noteswith a hard cap on loops,agents need budgets, not faith

Swipe the diagram sideways to see it all. A chatbot runs the engine once and stops. An agent puts the engine in a loop with the outside world: decide the next move, take it, look at what came back, decide again. The engine is still just predicting tokens. The loop and the tools around it are ordinary software. That's the entire secret.

Two things in this picture deserve respect. The **done gate**: an agent needs an explicit definition of finished, or it will happily keep looping. And the **budget**: caps on iterations, tokens and time are not pessimism, they're what makes autonomy deployable. Everything else in this chapter (tools, memory, planning, guardrails) is a refinement of this one loop.

03.2

## Tool use: hands for the model

The engine only emits text, so how does an agent **do** anything? **Tool calling**: you describe available functions in the prompt, and the model learns to reply with a structured call (a name and its arguments) whenever it needs one. Your code executes it and appends the result to the context.

the enginesees tool descriptions{ "tool": "crm.lookup","args": { "email":"lena@acme.co" } }the tool calljust structured textweb searchcrm.lookupcustomer recordsend\_emailrun\_codethe toolbox: described to the model, executed by your coderesult: Pro planresult appended to the context → the engine thinks again with new facts in view

Swipe the diagram sideways to see it all. The engine can't touch anything, it only emits text. So we describe the available tools in the prompt, and train the model to answer with a _structured call_ when it wants one (chapter 2's structured output, doing real work). Your code executes the call, not the model, and the result lands back in the context for the next think step. This is also why tool permissions belong in your code, not in the prompt.

Read that carefully, because it's a security boundary: **the model never executes anything**, your code does. Which means permissions, allow-lists and spending caps are enforced in ordinary software, where prompt injection can't reach. Good tool design is prompt engineering too: crisp names, typed arguments, and error messages written for the model to read, because the model is what reads them and decides what to try next.

The wider ecosystem

This picture is what standards like MCP (Model Context Protocol) formalize: a common way to describe toolboxes so any agent can pick them up. When you read “the agent has 200 tools”, it's this same diagram with a longer toolbox column.

03.3

## Memory: what agents remember

The engine forgets everything between calls; chapter 1's context window is all the “now” it has. Agents get two memories layered on top: **short-term** (this run's goal, tool results and notes, living in the window) and **long-term** (facts worth keeping, written to real storage and retrieved when relevant).

the agentthis run's loopshort-term · the context windowthe goal + system prompttool calls + results so farscratch notes for this taskperfect recall · gone when the run endslong-term storedb / vector index“Lena prefers Tuesdays”“vendor X was a dud”past run summariessave what matteredrecall into the window when relevant

Swipe the diagram sideways to see it all. Short-term memory is just chapter 1's context window: perfect recall, brutal eviction. Long-term memory is ordinary storage plus retrieval: the agent _writes down_ what matters and _looks it up_ next time. When an assistant “remembers” your name across sessions, that's a database row being retrieved into the window. Useful plumbing, not a bigger brain.

The craft is deciding what deserves to persist. Store everything and retrieval gets noisy; store nothing and the agent re-learns your preferences weekly. Good agents summarize a finished run into a few durable facts (outcomes, preferences, things-that-failed) and pull them back through retrieval, which is why the RAG section below is really also the memory section.

03.4

## Planning patterns: ReAct and plan-and-execute

Inside the loop, when does the agent decide what to do? Two schools. **ReAct** decides one step at a time, letting each observation steer the next thought. **Plan-and-execute** writes the whole plan up front, then works through it, replanning only when reality objects.

ReAct: reason + act, interleavedthinkactobservethinkactobserve…answereach observation steers the very next thought, nothing is decided in advanceplan-and-execute: commit, then run1\. search venues2\. check budgets3\. email top 34\. summarizeplannerwrites the whole plan firststep 1 ✓step 2 ✓step 3 ✗a step failed → replan from what's now known, don't push throughrevised plan…

Swipe the diagram sideways to see it all. ReAct improvises: every observation can change the next move. That's resilient in messy, unpredictable environments, but it can wander. Plan-and-execute commits: a plan you can show a human before anything runs, cheaper per step, easier to audit. It just has to notice when reality disagrees and replan. Production agents usually blend both: plan the milestones, ReAct inside each one.

Improvisation buys adaptability and pays in tokens and drift; commitment buys auditability. A plan is something a human can approve **before** the agent acts, and it pays in replanning overhead when reality doesn't cooperate. Production systems tend to commit more often than not, since a plan drawn out as a flowchart is something a person can sanity-check before anything runs. For long tasks, blend them: plan the milestones, improvise within each.

03.5

## Multi-agent teams

One agent with forty tools and a hundred-thousand-token context becomes unfocused. The fix mirrors how humans scale: **split the job**. An orchestrator breaks the goal into briefs and hands each to a specialist with a small prompt and a clean context; a critic reviews the merged result before it ships.

orchestratorsplits the job, sets the briefresearcherweb + docsanalystnumbers + claimswriterthe deliverablespecialists run in parallel, each with its own small contextsynthesismerge, dedupe, resolvecriticchecks claims + gapsrejected sections go back with notes

Swipe the diagram sideways to see it all. Why split one model into many agents? Focus and the context window. Each specialist gets a small, sharp prompt and only its own context, so the researcher's 40 pages of notes never crowd the writer's window. The orchestrator plans and routes; a critic reviews before anything ships, which is self-consistency from chapter 2, grown up into a team.

The wins:

* →**Focus.** Each prompt does one thing well.
* →**Parallelism.** Research lanes run simultaneously.
* →**Context hygiene.** The researcher's 40 pages never crowd the writer's window.

The cost is coordination: every hand-off can lose nuance, so the briefs and interfaces between agents matter as much as the agents. Start with one agent; split when a single context window demonstrably can't hold the job.

03.6

## RAG: retrieval-augmented generation

RAG, or **retrieval-augmented generation**, is grounding from chapter 2, built as infrastructure. Two lanes: an indexing pipeline that turns your documents into searchable vectors, and a query pipeline that finds the right chunks and hands them to the engine.

lane 1 · at index timeyour docspdfs, wikis, ticketschunk\~500-token piecesembedeach chunk → vectorvector indexthe map of meaninglane 2 · at question timequestion“leave policy?”embed querysame spacenearest chunkstop-k by similaritylooked up herehandbook §3 · 0.92faq #12 · 0.87memo 22 · 0.81prompt + enginegrounded, citedanswer: “20 days, plus carryover, see handbook §3.2” · chunking quality and retrieval hit-rate decide everything downstream

Swipe the diagram sideways to see it all. Retrieval-augmented generation, end to end. The top lane runs whenever your documents change; the bottom lane runs per question. Every piece is something you've already met: embeddings from chapter 1, prompt assembly and grounding from chapter 2\. When RAG disappoints, debug the lanes separately. Nine times out of ten the retrieval returned the wrong chunks, and no prompt can fix that.

It's the most deployed agent-adjacent architecture in industry, because it answers three complaints every company has:

* →The model doesn't know **our** data. Retrieval feeds it.
* →It makes things up. Citations make claims checkable.
* →Its knowledge is stale. Re-index the docs, no retraining needed.

When quality disappoints, resist the urge to rewrite the prompt first. Measure whether the right chunks were retrieved at all. They usually weren't.

03.7

## Guardrails, evals and humans in the loop

An agent that acts needs more than good intentions. Production systems wrap the loop in four checkpoints:

* →Filter what goes in.
* →Verify what comes out.
* →Gate what's risky behind a human.
* →Measure everything offline.

inputuser ask + datainput checksinjection? PII? scope?the agentloop + toolsoutput checksschema · policy · capslow-risk → just shipreply sentrisky actionhuman gateapprove · edit · rejectlogsevery run recordedeval suitenightly, on real casespass-rate drops → you know before your customers do

Swipe the diagram sideways to see it all. Trust is built outside the model. Input checks catch injection and strip what the agent shouldn't see. Output checks are code: schema, policy, limits. The riskiest actions wait for a human, an approval queue, not a leap of faith. And the logs feed an eval suite (chapter 2's test loop, automated) so you find out about drift from a dashboard, not from a customer.

The human gate deserves design attention, not guilt: approving an agent's drafted actions from a queue is still 10× faster than doing the work, and it's how trust gets earned. You widen autonomy as the eval numbers justify it.

The evals loop is chapter 2's debugging discipline running nightly: real cases, scored automatically, charted over time. Teams that skip it find out about regressions from their customers.

03.8

## Agent or workflow? Choosing honestly

The last skill is restraint. An agent is a loop whose path is decided at runtime by a probabilistic engine, and that's power you should **charge yourself for**. The honest first question is: could a human write the steps down?

the task“handle inbound leads”same stepsevery time?decision 1steps known in advance?yesbuild a workflowfixed pipeline, LLM steps insidedeterministic · cheap · testable,the right answer surprisingly oftenno, the path emerges at runtimejudgement worththe price?decision 2errors cheap to catch?yesbuild an agentloop, tools, budget, evalsnostay simplea form, a script, a humanhigh stakes? add a human gateapplies to every branch →

Swipe the diagram sideways to see it all. The most expensive sentence in AI right now is “let's build an agent for that”. If a human can write the steps down, write them down. A workflow with LLM steps inside it is cheaper, faster and debuggable. Reserve the agent loop for work where the path genuinely can't be known in advance. And when the stakes are high, the answer isn't agent _or_ workflow, it's either one, plus a human gate.

If yes, build the workflow: a fixed pipeline with LLM steps inside it where judgement is needed. It will be cheaper, faster, and debuggable at 2am. Build the full agent when the path genuinely can't be scripted: open-ended research, triage across messy systems, tasks where each step depends on what the last one found. Getting this decision right early, along with where the human gates go, saves a lot of rework later.

[← Previous chapterPrompt EngineeringThe techniques that reliably change model output: prompt anatomy, few-shot examples, chain of thought, self-consistency, structured output, the system-prompt stack, grounding and a debugging loop.](/learn/prompt-engineering)[NextSee it runningA few working agents you can open and read through, built on the same ideas covered in this chapter.](/agents)

A custom AI development agency. Bespoke agents, copilots and products engineered for teams that want a moat, not a subscription.

Ideanab Private Ltd is a company registered in England and Wales, no. [16344048](https://find-and-update.company-information.service.gov.uk/company/16344048). Registered office: 124 City Road, London, EC1V 2NX, United Kingdom.

### Company

* [Services](/#services)
* [Custom AI Agency](/custom-ai-agency)
* [AI Product Development](/ai-product-development)
* [AI OS](/ai-os)
* [AI Engineering](/ai-engineering-company)
* [AI Consulting](/ai-consulting-company)
* [AI Consulting Services](/artificial-intelligence-consulting-services)
* [Training](/training)
* [Education](/education)
* [Free AI Agents](/agents)
* [Learn AI](/learn)
* [Fractional CAIO](/caio)
* [About Us](/about)
* [Careers](/careers)

### Contact

* [Contact us](/contact)
* [Book a call](/book)
* [LinkedIn](https://www.linkedin.com/company/koso)
* [Instagram](https://www.instagram.com/okaashish)

### Legal

* [Terms of Service](/terms)
* [Privacy Policy](/privacy)
* [Cookie Policy](/cookies)
* [Acceptable Use Policy](/acceptable-use)

© 2026 Koso, a brand of Ideanab Private Ltd. All rights reserved.

[Terms of Service](/terms)[Privacy Policy](/privacy)[Cookie Policy](/cookies)[Acceptable Use Policy](/acceptable-use)

Crafted with care · Built to compound