Where Skills Fit: Agent Architecture

Nine Stages, One Request

People struggle to place skills correctly in a real system because they’ve only ever seen the format in isolation — a SKILL.md file, on its own, with no picture of everything happening around it. This lesson draws that picture: a single request, traced through every stage between “user types a message” and “user sees a response.”

LLM → Planner → Discovery → Loader → Skill → MCP → Tool → Memory → Response

Walk through what each stage actually does, using a concrete request: “Check this expense report against policy and route it for approval.”

1. LLM

The underlying model receiving the request. At this point, nothing skill-specific has happened yet — the model has the raw user message and whatever system-level context it starts every session with.

2. Planner

Reasoning about what the request actually requires. For a simple, single-step request, this stage might be nearly instantaneous. For “check this expense report and route it,” the planner recognizes this needs validation against policy, then a routing decision — two different kinds of work, which is a hint (from Skill Design Patterns) that more than one skill might be relevant, or that one skill spans both a Validator and a Decision pattern.

3. Discovery

The mechanism from the free course’s Skill Discovery lesson: the agent already scanned its installed skills’ name and description fields at session start. This stage is where that catalog gets checked against the planner’s understanding of the request — does anything in the catalog match “expense report,” “policy,” “approval routing”?

4. Loader

Once a matching skill is identified, the loader is what actually pulls its full SKILL.md body into context — progressive loading’s tier 2, made concrete as a pipeline stage rather than an abstract token-budget model.

5. Skill

The loaded instructions now shape everything that happens next: what counts as compliant, what routing rule applies at what amount, what to do if a receipt is missing. This is the skill’s entire authority — it tells the pipeline what should happen, but critically, it doesn’t have direct access to anything outside the conversation. To actually check the expense against a live policy database, or to actually route it, the skill’s instructions have to hand off to something else.

6. MCP

Where the skill’s instructions call for reaching an external capability — a company’s expense-policy database, an approval-routing system — MCP is the connection layer that makes that capability reachable, per the definition from From Prototype to Production. The skill doesn’t need to know the database’s internals; it just needs to know which MCP-exposed tool answers “what’s the approval limit for this category.”

7. Tool

The actual function call — get_approval_limit(category, department) — executes and returns a result. This is the only stage in the pipeline with a fixed, non-negotiable interface; everything before it involved judgment, and this stage is pure execution.

8. Memory

The result gets folded back into what the agent is tracking for this task — which is exactly the state and context concern from the previous lesson. If the expense report spans multiple turns (the user provides receipts one at a time, say), memory is what carries “we’ve already validated line items 1 and 2” forward correctly.

9. Response

Everything resolves into what the user actually sees — the validation result and the routing decision, not the internal mechanics of how the pipeline got there.

Diagnosing Where Something Went Wrong

The value of having this full picture isn’t academic — it’s diagnostic. When an agent misbehaves, “which stage is actually responsible” is usually answerable, and the fix is completely different depending on the answer:

A team that doesn’t have this model tends to blame the skill for everything — rewriting SKILL.md repeatedly when the actual bug lives in the MCP-exposed tool’s data, or in how memory carries state across turns. Placing the failure at the correct stage is often most of the fix.

Where a Skill’s Authority Actually Ends

The most common misunderstanding this diagram corrects: a skill does not do anything by itself. It tells the pipeline what should happen — which tool to call, under what conditions, with what fallback — but the actual doing happens at the Tool stage, reached via MCP. A skill with excellent instructions and no working MCP connection to the systems it depends on is a skill that can reason correctly about an expense report and still fail to route it anywhere, because reasoning correctly was never the part that was missing.

Summary

• A single request moves through nine stages: LLM, Planner, Discovery, Loader, Skill, MCP, Tool, Memory, Response
• Discovery and Loader are the progressive-loading mechanics from the free course, made concrete as pipeline stages
• A skill’s authority is entirely instructional — it shapes what should happen, but the actual execution happens at the Tool stage, reached through MCP
• Diagnosing a misbehaving agent means identifying which stage is actually responsible, since the fix differs completely by stage — a bad decision might be a skill problem, a wrong data problem might be an MCP/Tool problem, and an inconsistent multi-turn result might be a memory problem

You now have a complete map of where one skill sits in one agent’s pipeline. Next, you’ll compose multiple skills together — the first step toward systems where more than one skill, and eventually more than one agent, work on the same problem.