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.
🌱 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
- Decision boundary: what the agent decides on its own, and what it hands back to a human or another system.
- Actions: the smallest useful set for version one.
- Tools: which APIs and clients it connects to.
- Guardrails: see Guardrails and Human Oversight for AI Agents.
- Memory and state: short-term (the conversation, the current task) vs long-term (profile, history).
- 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
↩ Linked from (7)
These slot straight into the decompose-and-specialise and latency advice in Agentic System Design Checklist.
Agents work best against explicit interfaces and constraints: tool schemas, typed APIs, validated outputs (Agentic System Design Checklist). Platforms that encode constraints once let teams adopt new technology faster (P…
Related: Agentic System Design Checklist for where guardrails sit in the overall design, and Don't Read the Code for verifying what an agent produces.
Each removal shows that component's individual value. It's a cheap way to justify (or delete) a box on your architecture diagram, and it echoes the evaluation advice in Agentic System Design Checklist.
…notices when the page looks wrong even though the DOM is fine. It's another case for the design questions in Agentic System Design Checklist, especially guardrails on anything the agent can submit.
…uddy - Two-Phase Agents and Model Tiering, and it pairs naturally with the decompose-and-specialise advice in Agentic System Design Checklist.
A practice design I use to make the Agentic System Design Checklist concrete. The starting point is an ordinary set of parking microservices that are purely reactive. Agents make the system proactive, using a hybrid mana…
↪ Links to (8)
Related by topic
- Seed
Kubernetes
Platform engineering - Seed
Scaling Model Serving on Kubernetes
Platform engineering - Seed
Agentic Development Platforms
Platform engineering - Growing
AI Before the LLM Boom: Notes from 2019
AI, machine learning