AI Agent Design

AI Agent Design

Core Philosophy

Agents are not magic — they are systems with inputs, outputs, memory, tools, and decision logic. Design them with the same rigor as any production software. Every agent should have a clear purpose, defined boundaries, and explicit failure modes.

Agent Design Principles

1. Clarify Intent Before Acting

An agent must ask clarifying questions when the user's intent is ambiguous — before executing any irreversible action. Use this pattern:

• Is the goal clear? If not, ask one focused question.
• Are the constraints known? (scope, output format, data sources)
• What does success look like?

2. Specification Before Code

Before writing agent logic, generate a spec or task list file:

1. Define the agent's role and responsibilities
2. List all tools it needs access to
3. Define input/output contracts
4. Identify failure modes and fallback behavior
5. Then write the code

3. Single Responsibility

Each agent should do one thing well. Prefer a team of specialized agents over one general-purpose agent.

Orchestration Patterns

Framework Selection Guide

LangChain vs LangGraph — Which to Use

The LangChain team now explicitly recommends this split:

• LangGraph → for agents: stateful, cyclical, multi-agent, long-running tasks
• LangChain → for RAG and linear pipelines: simple document Q&A, step-by-step transforms

LangGraph is built on top of LangChain — you can use both together, starting with LangChain and dropping to LangGraph when you need more control.

RAG Pipeline Design

Standard RAG Flow

User Query → Embed Query → Vector Search → Retrieve Chunks → Augment Prompt → LLM → Response

Chunking Strategy (2026 Best Practice)

• Use semantic chunking — break on meaning, not character count
• Chunk size: 256–512 tokens for precision; 1024 for narrative content
• Always include metadata: source, page, section, timestamp

Hybrid Search (Recommended)

Combine dense vectors (semantic) + sparse vectors (keyword) for best recall:

Final Score = α × Dense Score + (1 - α) × Sparse Score

Vector Database Selection

Agent Memory Architecture

Context Rot Warning: Long context windows degrade agent quality over time. Implement a summarization step every N turns to maintain relevance.

Tool Use & Function Calling

Tool Definition Pattern

Every tool needs:

name: descriptive_tool_name
description: When to use this tool and what it does (be explicit)
parameters:
  - name: param_name
    type: string
    description: What this parameter expects
    required: true

Tool Use Best Practices

• Tools should be idempotent where possible
• Always validate tool outputs before passing to the next step
• Implement timeouts and retries for external tool calls
• Log all tool invocations for debugging

Agent Communication Patterns

Intent Clarification Protocol

When an agent receives an ambiguous request:

1. Identify the ambiguity — what specifically is unclear?
2. Ask one question — the most important one, not all of them
3. Propose a default — "I'll assume X unless you tell me otherwise"
4. Confirm before irreversible actions — always ask before deleting, publishing, or sending

Progress Reporting

For long-running tasks, agents should report:

[Step 1/4] Fetching documents... ✓
[Step 2/4] Chunking and embedding... ✓
[Step 3/4] Querying vector store...

Error Communication

✗ Tool failed: [tool_name]
Reason: [specific error]
Fallback: [what I'm doing instead]

MCP (Model Context Protocol)

MCP is the open standard for connecting agents to external tools and data sources. Use it when building portable, interoperable agent tools.

MCP Server Structure

my-mcp-server/
├── server.py (or index.ts)
├── tools/
│   └── my_tool.py
└── README.md

When to Use MCP vs Direct Integration

• Use MCP when the tool needs to be reusable across multiple agents/platforms
• Use direct integration for project-specific, one-off tool implementations

See mcp-builder skill for detailed MCP server implementation guidance.

Security & Safety

• Never allow agents to execute arbitrary code without sandboxing
• Implement rate limiting on all LLM API calls
• Validate and sanitize all inputs before passing to tools
• Log all agent decisions for auditability
• Implement guardrails to prevent runaway token costs or recursive loops
• Use system prompt injection protection — separate user input from system instructions with clear delimiters

Resilient Agent Design (Self-Healing)

Agents fail in production. Design for recovery from the start.

Validate-and-Retry Loop (LoopAgent Pattern)

Generate output → Validate output → If invalid: feedback + regenerate
Max iterations: 3  ← circuit breaker to prevent infinite loops

Plan–Validate–Execute–Observe–Replan

PLAN:     Generate plan, check feasibility before acting
EXECUTE:  Take action
OBSERVE:  Did it succeed? Check outputs, run tests
REPLAN:   If observation shows failure → adjust and retry
STOP:     If max retries hit → report failure clearly, ask for help

Agent Fallback Hierarchy

Primary approach fails → Try alternative approach
Alternative fails     → Request clarification from developer
Clarification absent  → Safe default action or graceful stop

Output Validation Before Presenting

• Run tests/lint on generated code before presenting
• Verify output format matches requirements
• Use a separate validator step (different model or prompt) to check generator output
• Never present unverified output as done

Circuit Breaker for Agents

Set hard limits to prevent runaway behavior:

• Max tool call iterations per task (e.g. 10)
• Max token spend per session
• Max retries per failing step (e.g. 3)
• Timeout per tool invocation

See self-healing-mindset skill for the full resilience philosophy and code patterns.