Lesson 1 · The whole stack · visual edition

AI Agents from first principles

~35 min · 10 levels · real use cases + interview questions · interactive recall

Published

AI agentsLLMsToolsLoopsMCP

Your bar: reconstruct the entire stack on a whiteboard from memory — to tell real capability from hype in pitches and reviews. So every level is built to be seen and redrawn, not read. Grounded in Anthropic’s Building effective agents 1 and the MCP spec. 3

One sentence holds the whole lesson. Each level just unpacks one chip of it:

An AI agent is a stateless text-prediction function

wrapped in a loop

given tools and a goal

run by ordinary code

User intent Agent LLM + loop Tool model asks Billing service Database state result flows back ↑ then the loop repeats THE REQUEST PATH — one pass of the agent loop
Memorise this banner. Every level below adds or explains one box or the loop arrow.
1

LLM — the brain in a jar

The only irreducible primitive. Everything else is plumbing around it.

text in LLM predict next text text out ✗ no memory  ✗ no hands  ✗ no state between calls
f(text) → text. A pure function: same call type, no side effects, nothing retained.

Is A stateless function: text in → predicted text out.

Why it exists Turn fuzzy natural-language intent into output with no hand-coded rules.

Like (world) A genius consultant who read the whole internet but has total amnesia — and can only talk.

Like (code) A pure POST /predict endpoint. A Lambda with no DB. RAM, no disk.

✗ “It looks things up / it remembers our chat”
✓ It predicts tokens; the app re-sends history each call

🧠 Memory rule: An LLM is a stateless text-prediction function — brain in a jar, no memory, no hands.

Memory check
  • What three things can an LLM not do alone? → remember, act, retain state
  • If it's stateless, how does a chatbot seem to remember? → the app resends the transcript
  • Closest SWE primitive? → a pure stateless endpoint, not a database
2

Tool & Tool calling — giving the brain hands

Two ideas, one critical line: the model requests; your code runs.

LLM only ASKS request runtime RUNS it get_invoice(id="42") Billing API → DB DB $90 result {amount: 90} → fed back to the LLM
Tool = a typed function (name + JSON schema). Tool calling = the model emitting the request your runtime fulfils.

Is A function the model may request (name + param schema); calling = it asks, runtime executes.

Why it exists Bridge text-prediction to real side effects — read a DB, hit an API, send mail — while keeping the model sandboxed.

Like (world) The amnesiac writes a work order; a runner does it and brings back the result.

Like (code) An API endpoint with an OpenAPI schema; the model emits a typed RPC your dispatcher routes.

✗ “The LLM ran the SQL / executed the tool”
✓ It only emitted a request — the runtime executed it

🛠️ Memory rule: A tool is a typed function the model may request but never run; calling is the model asking, your runtime doing.

Memory check
  • Who executes a tool call? → the runtime, never the model
  • What two things define a tool? → a name and a parameter schema
  • Why is "the LLM ran the SQL" wrong? → it only requested; code ran it
3

Agent — brain + hands + a goal

What you get when you let the model drive many tool calls toward an objective.

AGENT LLM + tools + loop + goal model picks each step get_order(42) → charged twice get_payments(42) → 2 charges refund(payment 2) → ok notify_customer(42) → done ✓
Same LLM as Level 1 — the intelligence added is structural: a loop, tools, and a goal.

Is An LLM in a loop with tools + a goal; the model chooses which tools, in what order, until done.

Why it exists You can’t pre-script open-ended work; steps depend on results. The agent decides the path at runtime.

Like (world) A capable employee handed an objective and systems access — no script.

Like (code) A long-running worker that orchestrates service calls dynamically, not a fixed cron job.

✗ “An agent is a smarter / bigger model”
✓ Same model — a loop + tools + a goal were added

🤖 Memory rule: Agent = LLM + Tools + Loop + Goal — the model picks the path, the loop keeps it moving.

Memory check
  • Four ingredients of an agent? → LLM, tools, loop, goal
  • Is it a better brain than an LLM? → no; structure was added, not IQ
  • Why not hardcode the dispute steps? → the path depends on what you find
4

Agent loop — Observe → Think → Act → Repeat

The heartbeat of every agent. You already run this loop in production.

OBSERVE last result THINK LLM picks ACT run a tool ↻ loop until goal / max-steps DONE ✓
≈ a Kubernetes reconciliation loop, but for intent: desired state = the goal.

Is Observe state → Think (LLM picks next step) → Act (tool) → observe → repeat, until goal or limit.

Why it exists The next action depends on the last result — you must react, not pre-plan.

Like (world) Debugging an outage: symptom → hypothesis → try one thing → observe → adjust.

Like (code) A K8s reconciliation loop / a REPL / an event loop.

✗ “The loop runs inside the model / it plans all steps first”
✓ The loop is code in the runtime; the model is called once per turn

🔁 Memory rule: The agent loop is a reconciliation loop for intent: observe, think, act, repeat until desired state.

Memory check
  • Four phases in order? → observe, think, act, repeat
  • Where does the loop live? → in the runtime code, not the model
  • What plays "desired state"? → the goal
5

Agent runtime — the app server around the brain

Plain code that hosts the loop. The layer leaders skip — and where reliability lives.

AGENT RUNTIME — your ordinary code LLM tools memory store holds state · calls LLM · dispatches tools · enforces max-steps, timeouts, retries, permissions
The model is a guest in this house; the house sets the rules.

Is The program running the loop: holds state, calls the LLM, runs tools, enforces guardrails.

Why it exists The stateless LLM can’t host a loop or stop itself; something must — and it’s code you own.

Like (world) The office around the employee: building, phones, badges, the manager who says “stop”.

Like (code) Laravel + web server + queue worker. Claude Code, Cursor, the Agent SDK are runtimes. 4

✗ “The model manages its own memory & limits”
✓ The runtime re-sends history and enforces every limit

⚙️ Memory rule: The runtime is the app server hosting the loop — it holds state, runs tools, and enforces the guardrails the model can’t.

Memory check
  • Three runtime jobs the LLM can't do? → hold state, run tools, enforce limits
  • Laravel analogy mapping? → LLM = logic fn, runtime = framework+server+worker
  • Agent loops forever — which layer failed? → the runtime (no max-steps)
6

Memory — because the brain forgets everything

Not a model feature — a runtime discipline. It’s just what gets re-injected.

CONTEXT WINDOW — RAM (bounded, refilled every call) system prompt + history so far + retrieved facts LLM short-termconversation history long-term · diskDB / vector store (RAG) runtime refills ↑
You solved this before: stateless HTTP → sessions + a database. RAG = a SELECT pasted into the prompt.

Is Whatever the runtime puts back into the prompt. Short-term = context window; long-term = external store.

Why it exists The model forgets between calls and the window is finite; relevant info must be re-injected.

Like (world) The employee’s notebook (today) + the company wiki (looked up on demand).

Like (code) Stateless HTTP + sessions + DB. Context = RAM payload; store = disk; RAG = a query injecting rows.

✗ “Bigger context window = memory”
✓ That’s more RAM per call; durable memory is the external store

💾 Memory rule: The model is stateless; memory is what the runtime reloads into the prompt — context is RAM, the store is disk.

Memory check
  • Short-term vs long-term? → context window vs database
  • Why isn't a bigger window "more memory"? → still volatile, re-sent each call
  • RAG in one backend line? → a query that pastes rows into the prompt
7

Workflow vs Agent — who writes the if/else?

The most important decision in the stack — and the one VPs over-engineer.

WORKFLOW — you write the path step 1 step 2 step 3 predictable · cheap · testable AGENT — the model writes the path LLM decides next step tool loop
Workflow = the if/else you wrote · Agent = the if/else the model writes at runtime.
DimensionWorkflowAgent
Controls flowYou (developer)The model, at runtime
PredictabilityHighLower (path emerges)
Cost / latencyLowHigher (many LLM calls)
DebuggabilityEasy (fixed paths)Harder (per-run traces)
Best forKnown, repeatable tasksOpen-ended, unpredictable tasks

Agentic workflow = the middle: a fixed workflow with a few model-decided steps (a runbook with “use your judgment here”).

✗ “Agents are the advanced / better default”

✓ Anthropic: start simple, use workflows, reach for agents only when flexibility pays 1

🧭 Memory rule: Workflow = you write the if/else; Agent = the model writes it; choose by how predictable the path is.

Memory check
  • Who writes the control flow in each? → developer vs model
  • What does a workflow buy you? → predictability, low cost, easy debugging
  • Safe default, and why? → workflow; agents add cost + unpredictability
8

MCP — USB-C for tools

One standard so you don’t hand-write glue for every external system.

WITHOUT MCP · N × M glue ABC gitdbslack every pair hand-wired WITH MCP · N + M ABC MCP gitdbslack build once, plug in
The client lives in the agent (the port); a server exposes each tool (the device); the registry is the catalog of what's plugged in.

MCP An open standard to discover & call tools/data from external systems. “USB-C for AI.” 3

Why it exists Kills the N×M bespoke-glue mess: expose a server once, any MCP agent uses it → N+M.

Server / Client Server = exposes tools (device). Client = connects from the host app (port).

Tool registry The catalog advertised to the model = service discovery for tools.

✗ “MCP is a Claude feature / MCP is the tool”

✓ Open multi-vendor standard; it’s the protocol to reach tools (≈ JDBC)

🔌 Memory rule: MCP is USB-C for tools — server = device, client = port, registry = catalog of what’s plugged in.

Memory check
  • MCP turns N×M into ___? → N+M
  • Agent vs GitHub integration — which is which? → agent=client, GitHub=server
  • Is a tool the same as MCP? → no; MCP is the protocol to reach tools
9

Single vs Multi-agent — monolith vs microservices

The same architecture call you’ve made a hundred times for services.

SINGLE — monolith agent tools simple · cheap · easy to trace MULTI — orchestrator-worker orchestrator subsubsub answer
Anthropic's research system: lead + 3–5 parallel subagents beat single-agent by 90.2% — at ~15× the tokens.2

Single One loop, one context, one tool registry, end to end. The monolith.

Multi Orchestrator plans & delegates to worker subagents (own context+tools), then synthesizes.

Like (code) Monolith vs microservices / map-reduce. Orchestrator = the dispatcher.

The cost Coordination, latency, partial failure, observability — and ~15× tokens.

✗ “More agents = better”

✓ Premature-microservices trap; split only when one context/role can’t cope

🧩 Memory rule: Single agent is a monolith; multi-agent is microservices — split only when one context/role can’t cope.

Memory check
  • Map both to an architecture you use daily. → monolith vs microservices
  • Orchestrator vs subagent? → plans/delegates vs scoped worker
  • The cost of multi-agent? → coordination + ~15× tokens
10

Archetypes — one engine, many job descriptions

The payoff: every “AI agent product” is the same engine + a different toolset + a different prompt.

SAME ENGINE LLM + loop + runtime + memory swap the tool registry + system prompt ↓ Coding files·shell· tests·git Exec-asst email·cal· browser Support KB·tickets· refunds SRE metrics·logs· deploy·rollback Billing invoices· payments·subs SW EngineerExec Assistant Support RepSRE EngineerBilling Ops SRE loop = Level 4 again: observe alert → diagnose → remediate → verify ↻
You don't build a new kind of agent — you hire one by choosing its tools and its job description.
✗ “Each agent type is different technology”
✓ Identical architecture; only tools + instructions differ

👔 Memory rule: Every archetype is the same engine + a different tool registry

  • a different job description.
Memory check
  • What changes vs stays between a coding and a billing agent? → tools+prompt change; engine same
  • SRE loop in four words? → observe, diagnose, remediate, verify
  • Three questions that cut through a pitch? → what tools? what loop? what guardrails?

Where each layer shows up — real use cases

Grounding for your hype filter: the concept, a concrete place it’s used, and the shape it usually takes (workflow / agent / infra).

ConceptReal use caseUsual shape
LLMClassify a ticket’s intent · draft a reply · summarise a PRsingle call
Tool calling”Book 30 min with Sam Thursday” → model calls the calendar APIworkflow / agent
AgentClaude Code fixes a failing test across several files on its ownagent
Agent loopCoding agent: edit → run tests → read failure → fix, until greenagent
RuntimeClaude Code · Cursor · the Agent SDK — the harness hosting the loopinfra
MemorySupport bot recalls a customer’s past tickets via RAG over the help centreworkflow + store
Workflow vs agentFixed “RAG Q&A over docs” pipeline vs open-ended “research this market”both
MCPConnect the agent to GitHub, Slack, and Postgres via MCP serversintegration
Single vs multiOne triage agent vs a “deep research” lead + parallel subagentssingle / multi
ArchetypesSWE copilot · support copilot · SRE on-call copilot · billing automationagent

Pattern to notice: most shipped value is a workflow with one or two tool calls; the loud demos are full agents. Your job in a review is to tell which one a pitch actually needs. 1

Retrieval practice — mix the levels

Reading builds fluency (feels familiar). Recall builds storage (lasts). Answer from memory — instant feedback.

Q1. Who executes a tool call?

Q2. "The model remembers our last message" is wrong because…

Q3. The difference between a workflow and an agent is…

Q4. MCP exists primarily to…

Q5. The agent loop is best compared to…

Q6. Single vs multi-agent maps cleanly onto…

Reconstruct the stack from a blank page

Write the ten levels in order, one line each, with nothing on screen. Then reveal and compare — gaps are your next drill.


1 LLM stateless text→text · 2 Tool: model requests, runtime runs · 3 Agent = LLM+tools+loop+goal ·4 Loop: observe→think→act→repeat · 5 Runtime: app server + guardrails · 6 Memory: runtime reloads (RAM vs disk) ·7 Workflow vs Agent: who writes the if/else · 8 MCP: USB-C; server/client/registry; N×M→N+M · 9 Single vs Multi: monolith vs microservices · 10 Archetypes: same engine + different tools + job.

I’m your teacher — ask me anything. Say “grill me on the agent stack” for mixed no-clue questions, or drop a real product and I’ll place it on the workflow↔agent & single↔multi spectrums with you. Want the next lesson — spaced, interleaved drills? Just ask.

Interview — pick your bar

Answer out loud in ~60s, then reveal. Core = recall · Senior = trade-offs & failure modes · Staff = synthesis under ambiguity · System Design = open design round (a different axis, not a harder level).

What is an LLM, and what are the three things it can't do on its own?
Hit these points: an LLM is a stateless text-prediction function — f(text) → text, the reasoning model, the brain → it can't remember between calls, can't act on the world, and holds no state → a chatbot only "remembers" because the runtime re-sends the transcript every call.
Walk me through exactly what happens when an agent "uses a tool".
Hit these points: a tool is a callable capability — a typed function (name + param schema) wrapping an API or function → the model only emits a request (tool name + args), it never executes anything → the runtime runs the real function and feeds the result back into the next call → red flag: "the LLM ran the SQL" — it only asked.
Define an agent and its agent loop.
Hit these points: an agent is an LLM using tools to accomplish a goal — LLM + tools + loop + goal → the loop is observe (last result) → decide (LLM picks next step) → act (run a tool) → observe, repeating until the goal is met or a cap is hit → same model as a bare LLM; what's added is structural, not IQ.
What is the agent runtime, and what is memory in this stack?
Hit these points: the runtime is the orchestration layer — ordinary code that hosts the loop, holds state, calls the LLM, dispatches tools, enforces retries/timeouts/max-steps/permissions → memory is persisted state the model can't see until the runtime retrieves it back into the context window → short-term = the window (RAM, re-sent each call); long-term = an external store, pulled in via RAG.
When would you NOT build an agent, and ship a workflow instead? Name the trade-off.
Hit these points: a workflow is a developer-defined path; an agent is a model-influenced path → if the steps are known and repeatable, write the workflow — you buy predictability, lower cost, lower latency, easier debugging → reach for an agent only when the path can't be predetermined and that flexibility is worth the autonomy tax → the named trade-off: predictability/cost vs flexibility/autonomy → the middle ground is an agentic workflow — a fixed path with a few model-chosen branches.
Your agent occasionally loops forever and burns huge cost. Where do you fix it, and why is it not "the model"?
Hit these points: the fix lives in the runtime, not the model — max-steps, timeouts, token budgets, and guardrails are the runtime's job → the stateless LLM can't stop itself or host a loop; the layer that owns the loop owns the limits → blaming "the model" misreads the architecture → add observability per turn so a runaway run is a traced, capped event, not a surprise invoice.
A team wants to add a second agent to "go faster." Talk them into it — or out of it.
Hit these points: same call as premature microservices → multi-agent costs coordination, latency, partial-failure handling, and roughly 15× the tokens (illustrative) → it only pays when the work is genuinely parallel and independent, or one context/role can't cope → start single-agent (the monolith); split with evidence, not vibes → "more agents" is not a capability, it's a bill.
Explain MCP to a skeptical exec in one analogy, and name the problem it solves.
Hit these points: MCP is a protocol for exposing tools, resources, and prompts to AI clients — "USB-C / JDBC for tools" → without it, every agent-to-tool pair is bespoke glue: N×M integrations → expose a server once and any MCP client uses it → N+M → a server exposes the capability, a client connects from the host app → it is an open multi-vendor standard, not a Claude feature, and not the tool itself — it's the way to reach tools.
A vendor pitches "fully autonomous agentic AI." Place it on the workflow↔agent spectrum and name the trade-off the pitch bought.
Hit these points: strip the buzzword to the engine — what tools, what loop, what guardrails? → "fully autonomous" sits at the far agent end: the model writes the path, so they bought flexibility and paid in predictability, cost, latency, and debuggability → ask what they gave up: can you reproduce a run, cap its spend, audit its actions? → for most real tasks the right answer is further left — an agentic workflow with autonomy only where the path truly can't be scripted → the senior read: autonomy is a cost you justify per use case, not a feature you brag about.
How does a "coding agent" differ from a "support agent" architecturally — and what does that tell you about every agent product?
Hit these points: architecturally they barely differ — same engine: LLM + loop + runtime + memory → what changes is the tool registry, the system prompt, and the guardrails — same employee, different job description → so "AI agent product" is rarely a moat in the engine; the moat is the tools you wired, the data you retrieve, and the guardrails you can stand behind → evaluate any pitch on those three, not on the model name.
Build vs buy: a team wants to adopt an off-the-shelf agent runtime/SDK instead of writing their own loop. How do you reason about it?
Hit these points: the loop itself is cheap to write; the hard, ongoing parts are state handling, retries, tool dispatch, permissions, observability, and evals — that's what a mature runtime buys you → buy when those are commodity and you want to spend your effort on tools, prompts, and domain guardrails → build when your control, latency, security, or audit requirements outgrow the SDK's seams → name the lock-in: how tools are defined, how memory is wired, how you trace a run → the reversible move is to keep your tools and guardrails portable and treat the runtime as swappable plumbing.
Design-round framework — for any "design an agent for role X," structure the answer like this:
  1. Goal & scope — what the agent is responsible for, and the explicit line where it must escalate to a human.
  2. Tools — the callable capabilities it needs (read vs write), each with a scoped permission boundary.
  3. Loop & runtime — observe→decide→act, with max-steps, timeouts, and token budgets in the runtime.
  4. Guardrails — approval thresholds, idempotency on writes, dry-run/rollback, and hard limits on destructive actions.
  5. Memory — per-task short-term context plus what's persisted to an external store and retrieved back.
  6. Workflow vs agent — script the common path, keep an agent escape-hatch only for the messy cases.
  7. Observability & eval — per-run traces, an audit log of every action, and how you'd measure success/regressions.
Design a support agent that's safe to ship for a SaaS billing product.
A strong answer covers: goal — resolve common billing questions and disputes, escalate the rest → tools: look up invoice/payments (read), issue refund and adjust subscription (write), notify customer, open a ticket → bounded loop in the runtime with max-steps and timeouts → guardrails: refund caps, human approval above a threshold, idempotent refunds so a retry never double-pays, full audit log, scoped permissions per tool → per-case memory plus retrieval of the customer's history → a workflow for the happy path with an agent escape-hatch for ambiguous disputes → eval on resolution rate and a hard zero-tolerance metric for wrong-amount refunds. Want to run this live? Ask me to grade your whiteboard answer.
Design an SRE incident-triage agent. What can it touch, and where does it stop?
A strong answer covers: goal — triage an alert, gather signal, propose (not silently execute) remediation → tools: read metrics/logs/traces and recent deploys (read-heavy), with write actions like rollback or scale gated behind explicit approval → observe→decide→act loop — an intent-level reconciliation loop — capped by max-steps so it can't thrash → guardrails: read-only by default, human-in-the-loop for any production-mutating action, blast-radius limits, idempotent and reversible operations, a full audit trail → memory of the current incident plus retrieval of similar past incidents/runbooks → workflow for the known runbook steps, agent autonomy only for the open-ended investigation → eval on time-to-diagnosis and false-action rate, and design so the worst failure is a no-op, never an outage.

★ Cheat sheet — buzzword → engineering

Mental models: LLM = brain · Tool = hands · Agent = brain+hands+loop+goal · Runtime = the app server · Memory = what’s reloaded · Workflow = you choose the path · Agent = the model chooses · MCP = USB-C for tools · Single = monolith · Multi = microservices.

Translation table

BuzzwordWhat it actually is
Agentic / autonomous AIAn LLM in a while-loop with tools + a goal
Function calling / toolsTyped RPC the model requests, you execute
Orchestration frameworkThe runtime (app server for the loop)
Context windowBounded RAM, re-sent every call
Memory / RAGExternal store + a query injecting text into the prompt
Workflow / chainA hardcoded pipeline / DAG you wrote
MCPStandard tool interface (USB-C / JDBC); N×M → N+M
Multi-agent / swarmOrchestrator-worker microservices for agents
Copilot / AI teammateAn archetype: the engine + one role’s toolset

Three rules for the VP chair

① Default to workflows; agents only when the path can’t be predetermined. ② Start single-agent; split like microservices — with evidence. ③ Judge any pitch by: what tools? what loop? what guardrails?

📄 Full printable version → agents-cheat-sheet.html

★ Review guides & what to read next

5-min (weekly) Don’t re-read — recall. Say the one sentence; redraw the request path

  • the loop from memory; recite the ten rules; translate three buzzwords blind.

30-min (when stalled) Blank-page reconstruct all ten levels; re-derive why each layer forces the next; then place one real product (workflow/agent? single/multi? which archetype? which tools?).

Read next, in order:①

Building effective agents — Anthropic

(Levels 1–7, read first) · ② Model Context Protocol docs (Level 8) · ③

Multi-agent research system — Anthropic

(Level 9) · ④ Claude Agent SDK (the loop as code). Full list → Resources.

📖 Primary source:

“Building effective agents” — Anthropic Engineering

— the highest-trust grounding for this lesson.

Was this lesson helpful? Thanks — noted.

These notes reflect my current understanding and are updated as I learn, build, and discover better explanations.