Prompt-Based Agent Architectures
From agent builder to autonomous systems architect. Learn to design architectures that define the limits of autonomy.
The Masterclass-Level Difference
In the Path 3, you learned to implement agents. Here, you learn to design agent architectures — deciding between single-agent and multi-agent, defining autonomy limits, designing coordination, and taking responsibility for technical responsibility by autonomous systems in production.
Types of Agent Architectures
Agent architectures vary in complexity, autonomy, and control structure. Understanding the fundamental types makes it possible to choose the right architecture for each problem.
Architecture Taxonomy
Simple Reactive Agent
Responds to stimuli with predefined actions. No memory, no planning.
Stateful Agent
Retains memory of previous interactions. Can adapt behavior to historical context.
Goal-Based Agent
Plans a sequence of actions to achieve a goal. Breaks down complex tasks.
Utility-Based Agent
Evaluates trade-offs among multiple objectives. Optimizes the utility function.
Learning Agent
Improves performance over time. Learns from feedback and results.
Architectural Decision
The architecture's complexity should be proportional to the problem. A reactive agent is sufficient for simple chatbots; an agent with planning is necessary for complex workflow automation. Over-engineering is just as problematic as under-engineering.
Choosing Between a Single Agent and Multiple Agents
One of the most important architectural decisions is choosing between a single-agent system or a multi-agent architecture.
Approach Comparison
| Aspect | Single Agent | Multi-agent |
|---|---|---|
| Complexity | Less | Major |
| Specialization | Generalist | Coordinated specialists |
| Scalability | Limited | High |
| Debugging | Direct | Complex |
| Cost | Predictable | Variable |
Use a Single Agent when:
- • Well-defined and limited domain
- • Critical latency
- • Cost needs to be predictable
- • Team has limited experience
Use Multi-Agent when:
- • Problem requires multiple specialties
- • Tasks can be parallelized
- • Quality matters more than speed
- • System needs to evolve modularly
Coordination, Supervision, and Delegation
In multi-agent architectures, the coordination mechanism is critical. It defines how agents communicate, who resolves conflicts, and how work is distributed.
Coordination Patterns
Centralized Orchestration
A "conductor" agent coordinates all the others. Full control, a single point of failure.
Decentralized Choreography
Agents coordinate through events/messages. Resilient, but difficult to debug.
Supervision Hierarchy
Agents are organized in a tree. A supervisor delegates to and aggregates results from subordinates.
Shared Blackboard
Agents read and write to shared space. Collaboration happens implicitly through state.
A delegation must have a clear scope. The supervising agent needs to know exactly what it is delegating, what the success criteria are, and when to step in.
Delegation Contract
- • Objective: what the subordinate agent should accomplish
- • Context: information needed to execute
- • Constraints: scope of action and resources
- • Callback: how and when to report the result
- • Escalation: when to ask the supervisor for help
Autonomy Limits
Define autonomy limits is one of the most important and most overlooked architectural decisions. Too much autonomy creates risk; too little eliminates the agent’s value.
Autonomy Spectrum
Criteria for Defining Autonomy
Increase autonomy when:
- • Action is reversible
- • Domain is well-defined
- • Feedback is quick
- • Cost of failure is low
Reduce autonomy when:
- • Action is irreversible
- • Domain is ambiguous
- • Impact on other systems
- • Compliance/security involved
⚠️ Required Guardrails
Regardless of the level of autonomy, every agent needs: rate limiting (maximum actions per period), budget caps (cost limit), scope boundaries (resources it can access) and kill switch (how to stop immediately).
Emergent Failures in Agent Systems
Multi-agent systems exhibit emergent behaviors — system properties that don’t exist in any individual agent. Some emergent behaviors are desirable; others are catastrophic failures.
Emergent Failure Patterns
Infinite Delegation Loop
Agent A delegates to B, which delegates to C, which delegates back to A.
Error Amplification
A small error in one agent is amplified as it passes through other agents.
Resource Deadlock
Agents wait for resources that other agents are holding.
Consensus Failure
Agents can’t agree on the state or next action.
Runaway Costs
Agents generate tokens/calls exponentially, causing costs to skyrocket.
Architectural Mitigations
- • Circuit breakers: when the error rate exceeds the threshold
- • Global timeout: maximum time limit for any operation
- • Depth limits: maximum delegation depth
- • Idempotency: actions can be repeated without side effects
- • Observability: complete trace of all interactions
Real-World Case Studies
Analyzing production agent architectures provides practical insights that theory can’t capture. Let’s examine architectural patterns in well-known systems.
Case 1: Coding Assistants (Copilot, Cursor)
Case 2: Customer Support Automation
Case 3: Data Pipeline Orchestration
Case Study Lessons
There is no "right" architecture. Every system makes trade-offs based on its specific requirements. The architect's role is to understand the trade-offs and make conscious choices, documenting the reasons for future reference.
Module Key Takeaways
Architectures range from simple reactive systems to learning agents
The choice between a single agent and multiple agents depends on specialization and scalability
Coordination can be orchestrated, choreographed, or hybrid
Autonomy limits should be proportional to risk
Emergent failures require proactive architectural mitigations
Real-world cases show that trade-offs are inevitable and contextual