Skip to content
matthewcm.dev

    ↑ ↓ move · ↵ open · tab scopeopen graph →

    Agentic System Design Checklist

    Before drawing boxes, pin down the decision boundary, actions, tools, guardrails and memory; then design the architecture and plan for latency, hallucination, scale and integration.

    Seedtended planted 2 min read

    🌱 A rough idea, planted recently. Expect rough edges — it will grow.

    On this page

    When I design an agentic system, the temptation is to start drawing boxes. The boxes come out better if I pin down six things first, then say the trade-offs of each new component out loud.

    What to explore first

    1. Decision boundary: what the agent decides on its own, and what it hands back to a human or another system.
    2. Actions: the smallest useful set for version one.
    3. Tools: which APIs and clients it connects to.
    4. Guardrails: see Guardrails and Human Oversight for AI Agents.
    5. Memory and state: short-term (the conversation, the current task) vs long-term (profile, history).
    6. Architecture: which components, how they fit, and the order of operations. Draw a diagram.

    Per agent, I write it up as Interface → Reasoning → Tools → Memory, then choose an orchestration style (ReAct vs Plan-and-Execute). Smart Parking Multi-Agent System - Case Study is a worked example.

    Why agency at all?

    Use an agent when the system has to be proactive (anticipate needs), do complex reasoning over many signals, personalise, or recover from errors creatively. Encoding all of that as rules means thousands of lines that are still reactive. If none of those apply, you probably want a workflow, not an agent (What Makes an AI Agent).

    Decompose and specialise

    Split the monolithic agent into an architect (planner) and specialists (workers):

    • Manageability: smaller, well-defined tasks.
    • Accuracy: each worker has a focused prompt.
    • Modularity: a new capability is a new worker.

    It’s the same shape as an ETL pipeline: a planner, workers that extract, connectors that assemble the stream. ChainBuddy - Two-Phase Agents and Model Tiering is a good published example.

    Challenges to design for

    Latency

    • Don’t default to the biggest model; smaller, faster ones are often enough (model tiering).
    • Optimise models: quantisation, pruning, distillation.
    • Cache common LLM responses and idempotent tool outputs.
    • Parallelise, and go asynchronous wherever the user doesn’t need to wait.
    • Consider hardware and placement: edge, GPU/TPU.

    Hallucination

    • RAG: fetch context and relevant documents first.
    • Output validation: fact checks, regexes, JSON schemas.
    • Ensembling or voting across models.
    • Confidence scores for transparency.
    • Clear prompts with an explicit output format and constraints.

    Scale: modular, independent components; multi-agent orchestration; load balancing across LLM endpoints and tools; batching tool calls and cutting duplicate API calls.

    Integration: balance rapid prototyping with robust connections; standard tool definitions (JSON Schema); an API abstraction layer separating agent logic from third-party APIs; fallbacks; clear protocols between agents. Clear contracts are what make this work (Contract-Driven Development).

    The two habits underneath

    • Optimise the system, not just the model, especially as token use rises. Ablations, as in MACRS - Multi-Agent Conversational Recommender, show what each component is worth.
    • Make failures observable. If you can’t see what an agent perceived and why it acted, you can’t iterate on it (Observability).
    • #ai-agents
    • #agentic-systems
    • #system-design
    • #checklist
    • #llm

    ↪ Links to (8)