(Part 1 can be found here: https://gist.github.com/Blevene/0d5f74c70873ce2dbe356208f75c68fa)
There's a pattern in technology that repeats itself. First, we build powerful, all-in-one monoliths. Then, as we try to scale them for the real world, we discover their limitations and break them apart into specialized, collaborating microservices.
Agents are to artificial intelligence as containers and microservices were to the cloud.
We've treated Large Language Models like monolithic "brains-in-a-box," trying to solve every problem with a single, complex prompt. This approach is brittle, expensive, and nearly impossible to debug in production. To build robust, scalable systems, we need to think less like prompters and more like architects. We need a new mental model.
The most effective model I've found is to think of it like building with Legos. When you open a complex Lego set, you get two things: a box of highly specialized bricks, and an instruction manual showing how to combine them. The best part? That instruction manual is just a suggestion, you can reuse and dynamically adjust based on your specific goals.
In the world of agentic AI:
- The Bricks are the Agentic Archetypes: Each is a component with a single, specialized function—a Planner, an Executor, an Evaluator.
- The Manuals are the Collaboration Patterns: These are proven blueprints for connecting your bricks to build reliable systems, from simple pipelines to complex, self-correcting teams.
This framework is your guide to these intelligent Legos. It will help you move from being a mere "prompter" to becoming an architect of reasoning, choosing the right bricks and patterns to build truly capable applications.
Before we detail the archetypes, it's critical to understand there are two types of "bricks" you can use:
- Cognitive Agents (The "Brain" Bricks): These agents use a Large Language Model (LLM) as their core engine. They are designed for tasks that require reasoning, understanding, and flexibility, like planning or evaluating quality. They are powerful but come with higher latency and cost.
- Deterministic Agents (The "Tool" Bricks): These are simple, predictable agents that do not use an LLM. They are lightweight wrappers around a single function, like an API call or a database query. They are fast, cheap, and reliable. A mature agentic system uses these deterministic bricks wherever possible.
Here are the core archetypes, with their typical engine clarified:
| Archetype | Primary Function | Typical Engine |
|---|---|---|
| Planner | Decomposes a high-level goal into a structured plan of subtasks. | LLM (Cognitive) |
| Executor | Performs a specific, well-defined action using a tool. | Deterministic Code or LLM (if the tool itself requires reasoning) |
| Explorer | Gathers information from an environment to provide context for planning. | LLM (to generate queries) + Deterministic Tool (to execute search) |
| Memory-Keeper | Manages state by providing access to short-term and long-term memory. | Deterministic Code (Vector DB query, API call) |
| Evaluator/Critic | Verifies and validates an output against a set of quality criteria. | LLM (for qualitative critique) or Deterministic Code (for fixed checks) |
| Communicator | Formats data and manages hand-offs between agents. | Deterministic Code (This is often a function, not a full agent) |
Before you start building, you must internalize the fundamental trade-off of this architecture. Every "cognitive" (LLM-powered) agent you add to a workflow introduces significant cost and latency. A system with five LLM-to-LLM hand-offs will be slow and expensive.
This leads to the golden rule for building practical, real-world systems:
If a task can be done with deterministic code, always use a deterministic agent.
Don't use a powerful LLM to format a JSON object or perform a simple calculation. Wrap that function in a cheap, fast, deterministic "tool brick." Reserve your cognitive agents for the tasks that truly require reasoning: planning the workflow, evaluating the quality of an ambiguous output, or synthesizing disparate information. Your primary job as an architect is to solve the problem with the fewest cognitive steps possible.
Defining the bricks is the first step. The real power comes from assembling them using proven blueprints. These patterns are not mutually exclusive; a sophisticated system will often combine them.
1. The Hierarchy (Coordinator/Dispatcher) A primary "Coordinator" agent delegates subtasks to the appropriate specialists. It's a classic top-down approach.
graph TD
A[User Goal] --> B(Coordinator Agent);
B -- "Plan the work" --> C(Planner Agent);
C -- "Sub-task 1" --> D(Executor Agent A);
C -- "Sub-task 2" --> E(Executor Agent B);
2. The Sequential Pipeline A linear assembly line where the output of one agent becomes the input for the next. It’s reliable and easy to debug.
graph LR
A[Input] --> B(Agent A: Fetch Data);
B -- Fetched Data --> C(Agent B: Process Data);
C --> D[Final Output];
3. The Parallel Fan-Out / Gather A Coordinator dispatches multiple independent tasks to run concurrently, with a final step to synthesize their findings.
graph TD
A[User Request] --> B(Coordinator Agent);
subgraph Parallel Execution
B -- "Research Aspect X" --> C(Executor 1);
B -- "Research Aspect Y" --> D(Executor 2);
end
C & D --> F(Gather/Synthesizer Agent);
4. The Iterative Refinement Loop (Generator-Critic) The system's internal quality assurance. A "Generator" agent creates work, and an "Evaluator" agent reviews it, sending it back with feedback if it falls short.
graph TD
A[Initial Request] --> B(Generator Agent);
B -- "Generates Draft v1" --> C{Output};
C --> D(Evaluator/Critic Agent);
D -- "Passes Validation" --> E[Final Output];
D -- "Fails Validation w/ Feedback" --> B;
5. Human-in-the-Loop The essential safety valve. The system intentionally pauses and asks for human input, approval, or correction.
graph LR
A[Automated Process] --> B(AI Agent Generates Proposal);
B --> C{Pause for Human Review};
C -- "Approved" --> D[Resume Automated Process];
C -- "Needs Correction" --> E(Human Reviewer);
6. The Decentralized "Offline" or "Background" Agent Tasks are posted to a shared space, and autonomous agents claim them based on capability, promoting resilience and parallel experimentation.
graph TD
A[User Goal] --> B{Task Pool / Blackboard};
B -- "Task: Competitive Analysis" --> C(Google Search Agent);
B -- "Task: Competitive Analysis" --> D(Financial Filing Agent);
C & D --> F(Results Aggregator);
7. The Governor / Sidecar Agent A safety and compliance agent runs in parallel to the main workflow, observing all activity and intervening only if a rule is violated.
graph TD
subgraph Main Workflow
A[Start] --> B(Agent 1) --> C(Agent 2) --> D[End];
end
subgraph Monitoring
G(Compliance Governor Agent);
end
G -- Observes & Enforces Policy --> B;
G -- Observes & Enforces Policy --> C;
This step-by-step process helps you move from an idea to a functioning multi-agent system.
| Step | Action | Key Outcome |
|---|---|---|
| 1. Frame the Goal | Define the system's mission and its measurable KPIs (e.g., latency, cost, accuracy). | A one-paragraph mission statement. |
| 2. Sketch the Components | Whiteboard the high-level capability buckets needed to achieve the goal. | A capability map of functional components. |
| 3. Choose Your Blueprint(s) | Select the collaboration pattern(s) that best fit your workflow. | A high-level architectural diagram. |
| 4. Define the Agent Bricks | For each component, define its role, instructions, and tools. Decide if it's cognitive or deterministic. | A spec for each agent (name, instructions, tools, engine type). |
| 5. Design the Data Contract | Define how agents will pass data using shared state keys or message schemas. | A data contract table (key → type → producer → consumer). |
| 6. Select the Framework | This is a foundational choice. Pick your orchestration engine (e.g., a graph-based framework like LangGraph for explicit control, or a conversational one like AutoGen for emergent collaboration). | Your core orchestrator code and a clear rationale for the chosen framework. |
| 7. Add Guardrails | Implement validation hooks, human-in-the-loop steps, and observability logging from day one. | Callback functions, middleware for validation, and a logging schema. |
| 8. Test and Evaluate | Write unit tests for each agent and end-to-end simulations for the entire system. | A suite of test cases and baseline performance scores. |
A multi-agent system is a distributed system. Without observability, it's an impenetrable black box.
| Symptom | Likely Root Cause(s) | Key Observability Signal(s) to Check |
|---|---|---|
| High End-to-End Latency | A slow external tool; an inefficient agent loop; too many cognitive hops. | Trace Waterfall: Find the span with the largest duration_ms. |
| Silent Task Failure | An agent timed out; a message was lost between agents. | Counters & Logs: Monitor agent.task_timeout_total. Correlate logs by conversation_id. |
| Spiking Costs | An agent is stuck in an LLM loop; a cognitive agent is used unnecessarily. | Metrics & Logs: Track agent.token_cost_usd. Sample tool-call logs to spot repetition. |
| Poor Quality Output | Flawed logic in the Critic; poor prompt in the Generator; bad data from the Explorer. | Log Analysis & Replay: Persist and review the full I/O for each agent in a failing conversation_id. |
Returning to the Lego analogy, what interests me most is this: we are moving beyond simply trying to carve a sculpture out of one giant block. We are becoming architects who select specialized bricks and assemble them with intent. By being disciplined about the components we choose—especially when to use an expensive cognitive brick versus a cheap deterministic one—we build systems that are not only more capable, but also more predictable, efficient, and reliable.
This is a complex and rapidly evolving frontier, but it offers a much more robust and scalable path for building the next generation of intelligent applications. It's a thrilling time to be a builder.