Choosing the Right Agent Architecture

Introduction

In our previous lesson, we established the 'agent-as-employee' mental model, using it to write a "job description" that defines what an agent needs to know, do, and escalate. This 'job description' is your primary tool for translating a business problem into a set of system requirements.

Now, we move to the next logical step: deciding on the agent's "cognitive architecture." How should the agent think and operate to best perform its job? An agent hired for a simple, repetitive task has different cognitive needs than one hired to manage a complex, multi-stage project.

This lesson directly addresses this question. Your learning outcome is to select the optimal agent architecture (e.g., reactive, plan-and-execute) for a given business problem by analyzing its requirements. We will explore the fundamental architectural patterns for single agents and discuss when to scale up to a team of agents. Your choice of architecture is one of the most critical design decisions you'll make, dictating your system's reliability, cost, and overall effectiveness.

The Fundamental Divide: Reactive vs. Planning Agents

At the highest level, agent architectures are divided by a primary trade-off: adaptability versus predictability. This divide gives us two main families of agents: Reactive agents and Planning agents.

Reactive Agents: The Adaptive Improviser

A reactive agent operates on a tight, iterative loop: Thought -> Action -> Observation. It decides on its next single step, acts, sees what happens, and then uses that observation to decide on the next step. The most well-known reactive pattern is ReAct.

• Strengths: Highly flexible and adaptive. They excel in dynamic environments where the path to a solution is unknown and must be discovered through trial and error.
• Weaknesses: They can suffer from "short-term thinking," losing sight of the overall goal. This can lead to inefficient paths, getting stuck in loops, or failing on complex tasks that require foresight.

Planning Agents: The Strategic Project Manager

A planning agent, by contrast, separates strategy from execution. It first creates a comprehensive, multi-step plan to achieve the objective and then carries out that plan. The most common pattern here is Plan-and-Execute (P-t-E).

• Strengths: Highly predictable, controllable, and auditable. Because the entire plan is generated upfront, you know exactly what the agent intends to do. This is critical for reliability and security. They are also often more efficient for complex tasks.
• Weaknesses: The basic form is rigid. If the environment changes unexpectedly or a step fails, the agent can't adapt without a specific mechanism for re-planning. There's also an initial latency while the plan is being generated.

To formalize these concepts, let's turn to a research paper that provides a rigorous comparison.

A Framework for Architectural Selection

The choice between ReAct and P-t-E is not arbitrary; it's an engineering decision based on the requirements of the "job" you defined in the last lesson. The paper you just reviewed contains a concise table that serves as an excellent decision-making aid.

Based on this table, you can establish some clear heuristics:

• Choose a Reactive (ReAct) architecture for:

  • Simple, conversational tasks: A chatbot answering user queries.
  • Exploratory tasks: An agent browsing the web to find an answer to a question where the search path is not obvious.
  • Highly dynamic environments: An agent that needs to react in real-time to changing data.

• Choose a Planning (P-t-E) architecture for:

  • Complex business processes: Automating a multi-step workflow like employee onboarding or processing an insurance claim.
  • High-stakes domains: Financial reporting, logistics, or code generation, where predictability and auditability are non-negotiable.
  • Cost-sensitive, long-running tasks: When many steps are involved, the single upfront planning cost of P-t-E is often cheaper than the cumulative cost of many ReAct cycles.

Beyond the Basics: A Spectrum of Architectures

ReAct and P-t-E are foundational families, but many variations and optimizations exist. The following video provides a practical tour of several prominent architectures, showing how they build upon these core ideas.

The progression shown in the video, especially on the planning side, is significant. Moving from a simple sequential plan (P-t-E) to a dependency-aware plan (ReWOO) and finally to a parallelizable task graph (LLM Compiler) is analogous to the evolution from simple shell scripts to sophisticated build systems like make or task schedulers in an operating system. This architectural maturity is what enables agents to tackle increasingly complex problems efficiently.

Scaling Complexity: Single Agent vs. Multi-Agent Systems

So far, we've discussed the architecture of a single agent—one "employee." But what if the job is too big for one? Just as in a human organization, you can hire a team of specialized agents. The decision to move from a single, generalist agent to a multi-agent system is a key architectural choice.

Once you decide a multi-agent approach is necessary, you need an architecture for their collaboration. This is where orchestrators and routers come in.

A great example of a multi-agent system in practice is a "Plan-and-Execute" pattern where the Planner is one agent, and the Executor is a team of specialized tool-using agents, all managed by an Orchestrator.

A Methodology for Architectural Design

To bring all these concepts together, you can adopt a systematic approach to architecture selection. The paper "Architecting Agentic Communities using Design Patterns" proposes a formal methodology that aligns perfectly with our lessons. I've summarized its key steps for you:

1. Assess Use Case Characteristics: This is what you did in the previous lesson. Analyze the "job description" based on:

   • Autonomy Requirements: Does the task need simple execution (LLM Agent), strategic reasoning (Agentic AI), or team coordination (Agentic Community)?
   • Regulatory & Risk Environment: Does it require high predictability, auditability, and human oversight?
   • Data & Task Complexity: Is it a simple query or a multi-step process with dependencies?

2. Compose Patterns: Select and combine architectural patterns based on your assessment.

   • Start with a foundational pattern (e.g., P-t-E for a complex business process).
   • Layer on complementary patterns (e.g., add a Re-planning loop for resilience, as described in section 7.1 of the LINK paper).
   • Compose horizontally (e.g., have an Orchestrator manage multiple specialized agents).

3. Apply Scale-Appropriate Scoping: Don't build an enterprise-wide system for a simple task. Choose a complexity tier:

   • Simple Automation (MVP): A single ReAct or basic P-t-E agent to prove core value.
   • Departmental Application (Production): A more robust single agent or a small multi-agent system with orchestration.
   • Enterprise-Wide System (Regulated): A full multi-agent community with advanced planning, orchestration, and comprehensive governance patterns.

This three-step process—Assess, Compose, Scope—provides a repeatable framework for designing agentic architectures that are perfectly matched to the business problem at hand.

Conclusion

In this lesson, we dissected the fundamental architectural choices you must make when designing an agentic system. You learned to select the right cognitive architecture for the "job" an agent is hired to do.

Key Takeaways:

• Agent architectures involve a primary trade-off between adaptability (Reactive patterns) and predictability (Planning patterns).
• Reactive agents (ReAct) are best for simple, dynamic, or exploratory tasks.
• Planning agents (P-t-E) excel at complex, multi-step tasks requiring reliability and auditability. P-t-E itself exists on a spectrum of sophistication, from simple sequential execution to parallel task graphs (DAGs).
• Multi-agent systems are necessary when a task requires multiple distinct skills. They are typically managed by an Orchestrator or Router agent that delegates work to specialists.
• Your selection process should be systematic: Assess the problem's requirements, Compose the appropriate patterns, and Scope the implementation to the right level of complexity.

Preview of the Next Lesson

You've now defined an agent's "job" (Lesson 2) and chosen its "cognitive architecture" (this lesson). The next step is to define its operational boundaries. In our next lesson, we will cover the principle of least authority, applying it to an agent's tool access and decision-making capabilities. You will learn how to give an agent just enough power to do its job, but no more, ensuring your system is both effective and secure.