Claude Agent Architecture: How the Pieces Fit Together

When an enterprise says it is "driving AI transformation with Claude," what ships to production is rarely a single chatbot. It is a layered system: a model loop that decides, a context window that remembers, a set of tools reached through Model Context Protocol servers, skills that teach Claude how to use those tools, and often a tree of subagents doing parallel work. Most teams adopt these pieces one at a time and never see how they connect. This post draws the whole map — the architecture and internals of a Claude agent, end to end, the way a staff engineer would whiteboard it before committing to a design.

Key takeaways

• An agent is fundamentally a loop: Claude reasons, optionally calls a tool, reads the result, and repeats until the task is done or a stop condition fires.
• The context window (up to 1M tokens with Claude Code) is the agent's working memory — what you put in it, and what you deliberately leave out, drives behavior more than any prompt trick.
• MCP servers are the standardized doorway to external systems; skills are the instructions that tell Claude when and how to walk through that door.
• Subagents isolate context: an orchestrator spawns children with clean windows, each returning a compact summary instead of raw output.
• Every production agent needs three cross-cutting layers the demo never shows: permissioning, observability, and cost control.

The core loop is simpler than it looks

Strip away the marketing and an agent is a while loop. Claude receives a prompt plus a list of available tools. It produces either a final answer or a structured request to call one or more tools. Your harness executes those calls, appends the results to the conversation, and sends everything back. Claude reads the new state and decides what to do next. The loop ends when the model emits a stop signal, a turn limit is hit, or a guardrail intervenes.

What makes Claude effective inside this loop is that it does not need you to script the branches. You describe the goal and the tools; the model plans the sequence. That inversion — from imperative steps to declarative goals plus capabilities — is the architectural heart of every Claude agent. Your job shifts from writing the algorithm to curating the environment the model reasons inside.

An agent is, precisely, a system in which a language model is given tools and autonomy to decide which tools to call, in what order, until a goal is reached. Hold that definition in mind, because everything below is just making that loop reliable, observable, and safe at enterprise scale.

How the pieces fit end to end

The diagram below shows a single user request flowing through a realistic Claude agent: gated, reasoned over, dispatched to tools through MCP, possibly fanned out to subagents, and reassembled into an answer.

flowchart TD
  A["User request"] --> B{"Permission gate & policy check"}
  B -->|Denied| C["Refuse & log"]
  B -->|Allowed| D["Claude model loop"]
  D --> E{"Tool needed?"}
  E -->|No| F["Compose answer"]
  E -->|Yes| G["MCP server executes call"]
  G --> H["Structured result back to context"]
  H --> D
  D --> I["Spawn subagents for parallel work"]
  I --> J["Summaries return to orchestrator"]
  J --> F

Read it as one turn that may iterate. The permission gate runs before any model token is spent. The model loop is the engine. MCP is the standardized I/O bus. Subagents are an optional scale-out branch. The arrows back into the loop are the part beginners forget: an agent is iterative, not a single request-response.

The context window is the real architecture

Everything the model knows in a turn lives in its context window. With Claude Code that window reaches roughly a million tokens, which is enough to hold a system prompt, conversation history, tool definitions, retrieved documents, and large file contents at once. But capacity is not the same as wisdom. A window stuffed with marginally relevant material degrades reasoning and inflates cost on every turn, because the entire window is re-processed each time.

So the architectural discipline is curation. You decide what is always present (the system prompt, the tool schemas), what is loaded on demand (skills, retrieved docs), and what is summarized away (old turns, raw tool output). A well-built agent treats the window like a hot cache with a budget, not a junk drawer. This is also where subagents earn their keep: by giving a child its own fresh window, you keep the parent's window small and focused while the child churns through noisy intermediate steps.

MCP servers and skills: the capability layer

Model Context Protocol is an open standard, introduced in late 2024, that defines how Claude connects to external tools and data through MCP servers. A server advertises a set of tools — each with a name, a description, and a JSON input schema — and the host application surfaces those to the model. When Claude decides to call get_invoice, the host routes the structured call to the server, which talks to your real system and returns structured data.

Skills are the complement. A skill is a folder of instructions, scripts, and resources that Claude loads dynamically when a task looks relevant. Where MCP answers "what can I call," a skill answers "when should I call it, in what order, and what does good output look like here." A finance agent might have an MCP server exposing ledger tools and a skill named close-the-month that encodes the firm's actual closing procedure. The server is the hands; the skill is the playbook.

{
  "name": "get_invoice",
  "description": "Fetch a single invoice by ID from the billing system.",
  "input_schema": {
    "type": "object",
    "properties": {
      "invoice_id": { "type": "string", "description": "Canonical invoice ID, e.g. INV-2026-00481" }
    },
    "required": ["invoice_id"]
  }
}

That shape is the literal contract Claude reads. A tight description and a constrained schema are doing real architectural work: they tell the model exactly when this tool applies and reject malformed calls before they reach your backend.

Cross-cutting layers the demo never shows

A prototype skips three things that production cannot. Permissioning decides which tools an agent may use, on whose behalf, and whether a human must approve a sensitive action before it executes. Observability captures the full trace — every tool call, every input, every result, token counts per turn — so you can debug and audit later. Cost control caps turns, throttles subagent fan-out, and uses prompt caching so the static prefix is not re-billed on every iteration.

Layer	Responsibility	Failure if missing
Permission gate	Authorize tools & actions	Agent takes unsafe action
Context curation	Choose what enters the window	Drift, high cost, bad answers
MCP + skills	Capabilities & playbooks	Hallucinated or wrong tool use
Observability	Trace every step	Unauditable, undebuggable

Common pitfalls

• Treating the agent as stateless. The loop is stateful across turns; if you drop tool results from context, the model forgets what it just learned and loops forever. Always thread results back in.
• Over-stuffing the window. Dumping entire databases or every file into context looks thorough but degrades reasoning. Retrieve narrowly and summarize aggressively.
• Vague tool descriptions. A tool named do_thing with a one-word description forces the model to guess. Treat descriptions and schemas as part of the prompt.
• Reaching for multi-agent first. Multi-agent runs commonly burn several times more tokens than a single agent. Use one agent until a clear parallelism or isolation need justifies the cost.
• No human-in-the-loop on writes. Read tools can run freely; irreversible writes (refunds, deletes, emails) should pass a confirmation gate.

Map your own architecture in 5 steps

1. Write the goal as one sentence and list the tools the agent genuinely needs — no more.
2. Decide the context budget: what is always present, what loads on demand, what gets summarized.
3. Expose tools through an MCP server with precise schemas; add a skill for any multi-step procedure.
4. Add the permission gate in front of the loop and a confirmation step before irreversible writes.
5. Wire tracing for every tool call and set hard caps on turns and subagent fan-out before you ship.

Frequently asked questions

What is the difference between an MCP server and a skill?

An MCP server exposes callable tools with schemas — the raw capability. A skill is loaded instructions that tell Claude when and how to use those tools for a specific task. You typically need both: the server provides the action, the skill provides the judgment.

Do I always need subagents?

No. Subagents help when work is parallelizable or when a noisy subtask would pollute the main context window. They cost significantly more tokens, so start single-agent and add them only where isolation or parallelism clearly pays off.

How big should my context window actually be?

As small as the task allows. Even with a million-token ceiling, the goal is relevance, not volume, because the whole window is reprocessed every turn — bloated context means higher latency, higher cost, and weaker reasoning.

Bringing agentic AI to your phone lines

CallSphere runs this exact architecture — model loop, MCP tools, curated context — on voice and chat, so an agent can answer every call, pull data mid-conversation, and book the work without a human waiting on the line. See it live at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.