import{c as e,Q as a,j as t,m as n}from"./chunks/framework.BPKcPtvA.js";const u=JSON.parse('{"title":"Module 2: Agent Architecture","description":"","frontmatter":{},"headers":[],"relativePath":"modules/m2-architecture.md","filePath":"modules/m2-architecture.md","lastUpdated":1780488246000}'),i={name:"modules/m2-architecture.md"};function l(o,s,r,p,d,h){return a(),t("div",null,[...s[0]||(s[0]=[n(`

Module 2: Agent Architecture

Lesson 2.1: The Four Pillars

Every agent system is built on four pillars:

┌─────────────────────────────────────────────────────────────┐
│                      AGENT SYSTEM                           │
├──────────────┬──────────────┬──────────────┬────────────────┤
│   TOOLS      │    LOOP      │   CONTEXT    │    MEMORY      │
│ Capabilities │  Autonomy    │  Awareness   │  Persistence   │
│              │              │              │                │
│ • Read/Write │ • Think→Act  │ • System     │ • Mental       │
│ • Bash       │ →Obs→Repeat  │   prompt     │   models       │
│ • Search     │ • Iteration  │ • Messages   │ • Expertise    │
│ • API calls  │   limits     │ • Tool       │   files        │
│ • MCP        │ • Terminate  │   results    │ • Scratch      │
│              │   conditions │ • Window     │   pads         │
│              │              │   mgmt       │ • Session logs │
└──────────────┴──────────────┴──────────────┴────────────────┘

Tools define what the agent CAN do
Loop defines WHEN the agent does it
Context defines WHAT the agent knows right now
Memory defines WHAT the agent remembers across sessions

Lesson 2.2: Tool Design Patterns

Tool Distribution Channels (from Beyond MCP research)

Channel	Context Cost	Portability	Auto-Discovery	Best For
MCP Server	High (full context per call)	High	Yes (MCP protocol)	Multi-client, standardized tools
CLI	Medium	High	No	80% of new tools, direct control
File System Scripts	Low (progressive disclosure)	Medium	No	Context-sensitive, portable
Skills	Low	Medium	Yes (skill dir)	Agent-native, behavior rules

Tool Design Rules

Single responsibility: One tool = one capability. Don't make a Swiss Army knife tool.
Descriptive names: search_web not sw. execute_sql_query not run.
Rich descriptions: Tell the LLM WHEN to use each tool and WHAT it returns.
Parameter validation: Schema-enforce types, required fields, and constraints.
Output limits: Cap returns (2KB for logs, 10 results for search) to avoid context overflow.

Advanced: Resource Mirror Pattern

Some MCP clients don't support Resources. The fix: every Resource gets a mirror Tool that returns identical data:

python

# Resource: datasets://loaded  →  may not work in all clients
# Mirror tool:
@tool
def list_loaded_datasets() -> str:
    """List all currently loaded datasets. Returns names and row counts."""
    return json.dumps(registry.list_datasets())

Lesson 2.3: Agent Loop Variants

Level 1: Simple Prompt → Execute

LLM call → command string → execute → output

No loop. Single API call generates a command, you run it. Good for: code generation, translation, summarization.

Level 2: Tool-Use Agent Loop

while not terminal_tool_called:
    LLM(invoke with tools) → tool call → execute → feed result back

Core pattern. 5+ tools, forced tool choice. Terminal tool (e.g., run_final_query) exits. Good for: data analysis, file editing, web research.

Level 3: Task-Completion Loop

while not complete_task_tool_called:
    LLM → tool call → execute → observe → continue or complete

Adds explicit complete_task terminal action. Clear success/failure conditions. Good for: multi-step workflows with defined finish criteria.

Level 4: Sub-Agent Orchestration

main_agent → spawns sub_agents → collects results → synthesizes

Main agent calls LLM sub-calls for parallel work (e.g., check 10 files for relevance in parallel batches). Good for: codebase analysis, parallel research, batch operations.

Level 5: Full Multi-Agent

orchestrator → team_lead → worker_agents → results bubble up

Depth-2+ delegation hierarchy. Each agent has domain, tools, memory. Good for: production systems, complex workflows.

Lesson 2.3b: Skills System Deep Dive

Skills are the building blocks of agent behavior. A skill is a self-contained instruction file that an agent loads and follows.

Path-Scoped Skills

Skills can be scoped to specific directories. The agent only loads skills relevant to the files it's working on:

repo/
├── .claude/skills/
│   ├── global/
│   │   ├── conversational-response.md
│   │   └── security-policy.md
│   ├── frontend/
│   │   ├── react-patterns.md
│   │   └── css-guidelines.md
│   └── backend/
│       ├── api-design.md
│       └── database-migrations.md

Subdirectory CLAUDE.md

One CLAUDE.md doesn't scale for large projects. Modern agents walk the directory tree and load the closest rules file:

repo/
├── CLAUDE.md                    # Root rules (all agents)
├── frontend/CLAUDE.md           # Frontend overrides
├── backend/CLAUDE.md            # Backend overrides
└── deploy/CLAUDE.md             # Deployment rules

Plugin Distribution Model

Skills and agent configs can be packaged as shareable plugins:

my-agent-kit/
├── agent.yaml                   # Agent definition
├── skills/                      # Skill files
├── tools/                       # Custom tools
├── hooks/                       # Lifecycle hooks
└── README.md                    # Usage instructions

This is how ClaudeFAST distributes their 280 skills and 16 agents as commercial kits.

LSP MCP Server Pattern

For large codebases, grep is too slow. An LSP (Language Server Protocol) MCP server gives agents symbol-level search:

Agent → MCP Client → LSP MCP Server → Language Server → Codebase

Tools exposed: find_definition, find_references, find_symbols, get_hover_info

Lesson 2.3c: Agent-Readable Workspace Design

An agent-readable workspace is organized so an agent can discover everything it needs without being told.

The Discovery Pattern

repo/
├── CLAUDE.md           ← Agent reads this FIRST
├── init.sh             ← Run this to set up environment
├── feature_list.json   ← What features exist, what's done
├── Makefile            ← Common commands (test, build, lint)
├── tests/              ← Expected outcomes (evidence)
└── docs/               ← Architecture decisions (ADRs)

Initialization as Its Own Phase

The first thing an agent should do is NOT start coding. It should initialize:

Read all instruction files (CLAUDE.md, AGENTS.md, skills)
Discover project structure (list files, read key configs)
Verify environment (check tool versions, API keys, dependencies)
Load state (mental models, session history, feature progress)
Plan before coding

Feature Lists as Harness Primitives

A feature_list.json gives agents a structured inventory of what to build and what evidence proves completion:

json

{
  "features": [
    {
      "id": "auth-login",
      "status": "done",
      "evidence": ["tests/test_auth.py::test_login", "src/auth/login.tsx"]
    },
    {
      "id": "auth-register",
      "status": "in_progress",
      "evidence": []
    }
  ]
}

Clean State Between Sessions

Every session must leave the workspace in a clean state:

No half-finished files
No dangling processes
No uncommitted changes
Session logs archived
Temporary files cleaned

The next agent (or the same agent on the next session) should find the workspace as if no one touched it.

Lesson 2.4: Context Window Management

The Problem

Context windows grow unbounded. Every tool result, every LLM response, every intermediate step gets appended. After 20 turns of file editing, your context contains thousands of lines of file contents and logs.

Solutions (from worst to best)

Approach	How	Trade-off
Sliding window	Keep last N messages	Lose early context
Summarization	Compress old messages into summary	Information loss
Structured outputs	Agents output structured data, not free text	Requires schema design
Multi-agent isolation	Each agent has focused context window	Complexity, coordination cost

Best Practice: Hybrid

[System prompt (always)] + [Recent N turns (full)] + [Summary of earlier turns] + [Current tool results]

Lesson 2.5: Memory Patterns

Mental Models (from multi-team system)

Every agent maintains a personal expertise file:

yaml

# .pi/multi-team/expertise/backend-dev-mental-model.yaml
expertise:
  - topic: "API patterns used in this project"
    notes: "We use tRPC for type-safe API calls. All endpoints follow /api/trpc/{router}.{procedure}"
    last_updated: "2026-04-20"
  - topic: "Database conventions"
    notes: "SQLite with Drizzle ORM. Migrations in packages/db/src/migrations/"
    last_updated: "2026-04-22"

Rules:

Agents own their mental models (they write them, not you)
Read-only expertise for critical domain knowledge (billing, deployment, security)
Self-improve commands validate expertise against actual codebase
Mental models compound across sessions

Scratch Pads

Ephemeral memory for a single session. Good for tracking:

What's been tried and failed
Current working state
Decisions made this session

Lesson 2.6: The Reasoning Parameter

Forcing the LLM to explain every tool call is the highest-ROI prompt engineering technique:

python

def search_documentation(query: str, reasoning: str) -> str:
    """
    Search documentation.
    
    Args:
        query: The search terms
        reasoning: WHY you are searching for this (required for audit)
    """
    ...

Why it works:

Forces the LLM to articulate intent before acting
Creates an audit trail of every decision
Catches hallucinated tool calls (if the reasoning is nonsense, the call is suspect)
Gives the LLM an extra "thinking step" without using chain-of-thought

Lesson 2.7: Codebase Architectures for Agents

From single-file-agents research, 4 patterns for scaling agent codebases:

Architecture	Structure	Best For
Atomic/Composable	atom/ → molecule/ → organism/	Reusable tool primitives across many agents
Layered	api/ → services/ → models/ → data/	Clear separation of concerns within one agent
Pipeline	steps/ → pipeline_manager/ → shared/	Data transformation flows
Vertical Slice	features/{feature}/{api,service,model}/	Multiple independent agent capabilities

Lab 2.8: Multi-Tool Agent

Objective: Add file operations + web search tools to the agent from Lab 1.

Starter: course/labs/L2-multi-tool/starter.py
Solution: course/labs/L2-multi-tool/solution.py

Lab 2.9: Context-Aware Agent

Objective: Implement sliding window + summarization for long sessions.

Starter: course/labs/L2-context/starter.py
Solution: course/labs/L2-context/solution.py

`,99)])])}const g=e(i,[["render",l]]);export{u as __pageData,g as default};

Module 2: Agent Architecture ​

Lesson 2.1: The Four Pillars ​

Lesson 2.2: Tool Design Patterns ​

Tool Distribution Channels (from Beyond MCP research) ​

Tool Design Rules ​

Advanced: Resource Mirror Pattern ​

Lesson 2.3: Agent Loop Variants ​

Level 1: Simple Prompt → Execute ​

Level 2: Tool-Use Agent Loop ​

Level 3: Task-Completion Loop ​

Level 4: Sub-Agent Orchestration ​

Level 5: Full Multi-Agent ​

Lesson 2.3b: Skills System Deep Dive ​

Path-Scoped Skills ​

Subdirectory CLAUDE.md ​

Plugin Distribution Model ​

LSP MCP Server Pattern ​

Lesson 2.3c: Agent-Readable Workspace Design ​

The Discovery Pattern ​

Initialization as Its Own Phase ​

Feature Lists as Harness Primitives ​

Clean State Between Sessions ​

Lesson 2.4: Context Window Management ​

The Problem ​

Solutions (from worst to best) ​

Best Practice: Hybrid ​

Lesson 2.5: Memory Patterns ​

Mental Models (from multi-team system) ​

Scratch Pads ​

Lesson 2.6: The Reasoning Parameter ​

Lesson 2.7: Codebase Architectures for Agents ​

Lab 2.8: Multi-Tool Agent ​

Lab 2.9: Context-Aware Agent ​