Architect multi-agent systems with appropriate collaboration...

Q: In the context of multi-agent system architecture, what makes a component an agent (as opposed to a one-off tool call)?

An agent is a system that: Maintains state across steps It carries information forward rather than acting as a single, stateless call. Decides what to do next It chooses actions over time, not just producing one output. Pursues a goal Its behavior is oriented toward achieving an objective. Can change its environment through actions It can take actions that affect external state or outcomes, not only generate text.

Q: What distinguishes a true multi-agent architecture from a system that merely makes multiple LLM calls?

A multi-agent architecture requires meaningful interaction between agents over several steps , not just many calls. In a multi-agent system, agents: Divide work into roles/subtasks. Exchange information (observations, plans, intermediate results). Contribute to a shared outcome through coordination, cooperation, negotiation, or challenge. By contrast, a one-shot chatbot answer is a tool-like interaction, and an LLM that classifies an email once is a classifier, not a multi-agent system.

Q: List the elements a complete multi-agent architecture answer should explain (i.e., what you would include when describing your design).

A complete answer explains: The system’s overall goal and environment The role and responsibility of every agent How subtasks are divided How agents share observations, plans, and results Whether coordination is centralized, distributed, or hybrid How collaboration, debate, or negotiation improves the result How the system handles uncertainty, dependencies, failure, and changing conditions How a final decision is verified or approved

Q: What is not required by this learning objective, and what is the focus instead?

This objective does not require: Reproducing the internal mathematics of an LLM Treating every system containing an LLM as an agent Instead, the focus is the architecture of interaction among autonomous or semi-autonomous components : how multiple agents coordinate, cooperate, negotiate, challenge one another, and produce a checked final outcome.

Q: In system architecture, what conditions indicate that a problem should be treated as a multi-agent problem rather than handled by a single agent?

A problem is multi-agent when one agent is not sufficient or when different roles require different perspectives, skills, or permissions . In such settings, multiple actors (e.g., AI assistants, CI/CD bots, human developers) operate on the same environment , and their actions can affect one another , so the architecture must include coordination rather than treating each actor as independent.

Q: In a multi-agent code-editing environment, give two concrete failure modes that occur when agents do not coordinate, and state the architectural implication.

Two coordination failures are: Conflicting edits : if two agents edit the same file without communicating, their actions can conflict. Obsolete plans : if one agent makes a plan using outdated information, another agent may need to re-evaluate it. Architecturally, this implies the system needs mechanisms for communication and coordination so agents share state/intent and trigger re-evaluation/verification when conditions change.

In the context of multi-agent system architecture, what makes a component an agent (as opposed to a one-off tool call)?

An agent is a system that:

Maintains state across steps
- It carries information forward rather than acting as a single, stateless call.
Decides what to do next
- It chooses actions over time, not just producing one output.
Pursues a goal
- Its behavior is oriented toward achieving an objective.
Can change its environment through actions
- It can take actions that affect external state or outcomes, not only generate text.

What distinguishes a true multi-agent architecture from a system that merely makes multiple LLM calls?

A multi-agent architecture requires meaningful interaction between agents over several steps, not just many calls. In a multi-agent system, agents:

Divide work into roles/subtasks.
Exchange information (observations, plans, intermediate results).
Contribute to a shared outcome through coordination, cooperation, negotiation, or challenge.

By contrast, a one-shot chatbot answer is a tool-like interaction, and an LLM that classifies an email once is a classifier, not a multi-agent system.

When moving “from a task to an interaction architecture” for a multi-agent system, what design decisions must you explicitly make?

You must decide the system’s interaction structure, including:

Who does what
- Define agent roles and responsibilities.
How agents communicate
- Specify how they exchange observations, plans, and results.
Who coordinates them
- Choose a coordination approach (e.g., centralized, distributed, or hybrid).
How disagreement is handled
- Define collaboration, debate, or negotiation patterns.
How the final result is checked
- Specify verification/approval of the final decision.

List the elements a complete multi-agent architecture answer should explain (i.e., what you would include when describing your design).

A complete answer explains:

The system’s overall goal and environment
The role and responsibility of every agent
How subtasks are divided
How agents share observations, plans, and results
Whether coordination is centralized, distributed, or hybrid
How collaboration, debate, or negotiation improves the result
How the system handles uncertainty, dependencies, failure, and changing conditions
How a final decision is verified or approved

What is not required by this learning objective, and what is the focus instead?

This objective does not require:

Reproducing the internal mathematics of an LLM
Treating every system containing an LLM as an agent

Instead, the focus is the architecture of interaction among autonomous or semi-autonomous components: how multiple agents coordinate, cooperate, negotiate, challenge one another, and produce a checked final outcome.

In system architecture, what conditions indicate that a problem should be treated as a multi-agent problem rather than handled by a single agent?

A problem is multi-agent when one agent is not sufficient or when different roles require different perspectives, skills, or permissions. In such settings, multiple actors (e.g., AI assistants, CI/CD bots, human developers) operate on the same environment, and their actions can affect one another, so the architecture must include coordination rather than treating each actor as independent.

For architecting multi-agent systems, explain the environment properties that make coordination necessary (name each property and what it means).

Key environment properties that drive the need for coordination include:

Partially observable
- No agent sees the complete state (e.g., a coding agent must choose which files to inspect; runtime behavior may only be visible after executing code).
Stochastic
- The same input may produce different LLM outputs, and even deterministic code can behave unexpectedly.
Sequential
- Earlier actions change the state for later actions (e.g., editing one file may break another).
Dynamic
- The environment can change independently (e.g., another developer pushes a commit).
Multi-agent
- Several agents or humans may act on the same environment.

Why do partial observability, stochasticity, sequential dependencies, and independent environmental changes imply that multi-agent architectures must include communication, coordination, and verification?

These properties mean agents cannot reliably act in isolation:

Observations are incomplete or can become outdated, so one agent’s plan may be based on missing or stale information.
Outcomes are uncertain (stochasticity), so results often need checking rather than assuming repeatability.
Actions interact over time (sequential), so earlier edits change what later steps should do.
The world changes independently (dynamic), so another actor’s update can invalidate a plan.

Therefore the architecture must add communication (share state/intent), coordination (avoid conflicting actions), and verification (re-check assumptions and results) so the system functions as a coherent multi-agent system.

In a shared codebase workflow, what distinct agent roles can be separated, and what is the orchestrator’s responsibility?

A shared codebase can be decomposed into specialized roles:

Analysis agent
- Reads an issue and identifies likely files.
Coding agent
- Edits those files.
Testing agent
- Runs the test suite.
Review agent
- Checks whether the change solves the issue without introducing new problems.
Orchestrator
- Decides whether the work is complete or whether another cycle is needed.

In a multi-agent code-editing environment, give two concrete failure modes that occur when agents do not coordinate, and state the architectural implication.

Two coordination failures are:

Conflicting edits: if two agents edit the same file without communicating, their actions can conflict.
Obsolete plans: if one agent makes a plan using outdated information, another agent may need to re-evaluate it.

Architecturally, this implies the system needs mechanisms for communication and coordination so agents share state/intent and trigger re-evaluation/verification when conditions change.

In a multi-agent system, what is a role, when is specialization useful, and what four elements should each role definition include?

A role is the responsibility an agent has within the larger system. Specialization is useful when a task contains distinct activities (e.g., searching, planning, implementation, criticism, verification). Each role should be defined by:

Input: what the agent receives to work on
Responsibility: what it is accountable for doing
Output: what it must produce for other agents/system
Limits: what it should not do (to prevent unintended behavior)

How should a review agent be architected in terms of its input, responsibility, output, and limits, and what is a key failure mode to avoid?

A review agent can be specified as:

Input
- A proposed code change
Responsibility
- Check the proposed change against the requirements
Output
- Identified problems and a recommendation
Limits
- It should not silently replace the implementation unless that behavior is explicitly part of the architecture

Name the example specialized roles in a multi-agent system and state the core function of each.

Example roles and their functions include:

Coordinator
- Decomposes the goal, assigns subtasks, and tracks progress
Researcher
- Gathers relevant information or evidence
Planner
- Constructs a sequence of actions
Executor
- Performs an assigned action using available tools
Critic
- Searches for errors, unsupported assumptions, or alternative interpretations
Verifier
- Checks whether the final result satisfies explicit criteria

Why should roles in a multi-agent architecture be complementary rather than redundant, and what can go wrong if every agent performs the same task with the same information?

Roles should be complementary so the system gains a real division of labor (different kinds of work, not repeated work). If every agent performs the same task with the same information, adding agents may:

Increase cost (more computation/communication) without improving results
Increase disagreement (conflicting recommendations) without adding new capability

What does it mean to separate proposal from verification in a multi-agent system, and why is this separation especially useful with LLM-based agents?

Separating proposal from verification means:

One agent generates a solution (proposal)
Another agent independently checks that solution (verification)

This is especially useful because:

LLM outputs are probabilistic
Errors may be difficult for the original agent to notice, so an independent checker can catch issues the proposer misses

For system design, compare a single-agent loop to a multi-agent system on simplicity/speed, specialization/control, communication failures, and overhead/conflicts.

Comparison:

Simplicity and speed
- Single agent: simpler and often faster
- Multi-agent: divides responsibilities (less simple)
Specialization and control
- Single agent: planning and execution in one loop
- Multi-agent: specialization, independent criticism, clearer control
Communication failures
- Single agent: fewer communication failures
- Multi-agent: more communication/hand-offs to manage
Overhead and conflicts
- Single agent: less coordination overhead
- Multi-agent: added coordination overhead and can produce conflicting recommendations

You must design collaboration so the system can generate, challenge, execute, and verify a solution rather than relying on one unverified response. Which distinct roles would you assign, and how do their outputs connect into one process?

Assign distinct roles such as:

Planner: produces a sequence of actions
Executor: takes assigned actions and performs them using available tools
Critic: examines outputs for errors, unsupported assumptions, or alternative interpretations
Verifier: checks the final result against explicit criteria

Their outputs connect into one process by exchanging outputs: the planner’s plan guides execution; execution outputs are reviewed by the critic; the refined/accepted result is then checked by the verifier. This division of labor enables both proposal and verification rather than a single unverified response.

In a multi-agent system, what is orchestration, and what three decisions does it determine during execution?

Orchestration is the control structure of a multi-agent system: the mechanism that coordinates agent activity into a single process.

It determines which agent acts next.
- This selects the next contributor in the workflow.
It determines what information that agent receives.
- This controls the agent’s context/inputs for its step.
It determines when the overall task is complete.
- This defines the stopping/approval condition for delivering a final result.

For a centralized orchestration design, what is the coordinator’s end-to-end workflow from goal to final output?

In centralized orchestration, a coordinator/orchestrator manages the workflow:

Interpret the global goal.
Decompose the goal into subtasks.
Have specialized agents execute the subtasks.
Collect and compare agents’ outputs.
Request revision or verification when the result is incomplete.
Deliver or approve the final result.

This makes the system’s flow easier to inspect and control because responsibility is concentrated in the coordinator.

Contrast centralized, distributed, and hybrid orchestration patterns in terms of communication style and typical coordination trade-offs.

Centralized
- A coordinator manages the workflow (decompose/assign/collect/iterate).
- Trade-off: easier to inspect and control; clearer responsibility.
Distributed
- Agents communicate more directly and make local decisions.
- Trade-off: flexible, but can create ambiguity about responsibility and make global progress harder to track.
Hybrid
- Combines a coordinator with limited direct communication between specialists.
- Trade-off: coordinator maintains overall control while specialists can exchange information directly.

You are architecting a multi-agent workflow. Which orchestration pattern best fits each situation, and why? (1) Progress, permissions, and final responsibility must be clear. (2) Agents need flexible negotiation or rapid local responses. (3) A coordinator must control the overall goal, but specialists should exchange information directly.

(1) Use centralized orchestration.
- It is recommended when progress, permissions, and final responsibility must be clear.
(2) Use distributed interaction.
- It is recommended when agents need flexible negotiation or rapid local responses.
(3) Use a hybrid design.
- It is recommended when a coordinator should control the overall goal while agents exchange specialist information directly.

When architecting orchestration, when should you add explicit verification, and what risk is it intended to reduce?

Add explicit verification when incorrect actions can propagate through the system.

The purpose is to reduce the risk that an early mistake (or an unverified output) is passed along and amplified by downstream agents, harming global results.

Why is selecting centralized, distributed, or hybrid orchestration “not a cosmetic choice” when architecting multi-agent collaboration?

Because orchestration determines how separate agent actions become one coordinated process, affecting whether collaboration yields a coherent outcome.

Centralized orchestration creates a visible dependency structure by having a coordinator decompose work, assign tasks, collect results, and trigger revision.
Distributed communication supports negotiation when local decisions must be made jointly, but can make global progress harder to track.
Therefore, the pattern chosen influences whether the system produces a coherent result or disconnected actions.

In the course framing of multi-agent systems research, which three themes are explored, and what are three example platforms mentioned?

Multi-agent systems research is described as exploring:

coordination
negotiation
cooperation

Example platforms mentioned include:

JADE
CrewAI
AutoGen

In a multi-agent system, how do collaboration, debate, and negotiation differ in what agents do to reach an outcome?

Collaboration: agents contribute different pieces toward a shared goal.
- Focus is complementary contributions that combine into one result.
Debate: agents present competing analyses and challenge one another.
- Focus is surfacing errors, conflicts, and alternative interpretations.
Negotiation: agents adjust their proposals until they reach an acceptable agreement.
- Focus is iterating proposals toward a mutually acceptable endpoint.

When is debate particularly valuable in a multi-agent architecture, and what role does an independent perspective play?

Debate is valuable when the task contains ambiguity or when an independent perspective can expose errors. An independent agent can deliberately search for weaknesses (e.g., one agent proposes a solution while another searches specifically for counterexamples), creating meaningful challenge rather than reinforcing the same assumptions. A final synthesizer/coordinator can then combine useful parts into a more justified outcome.

Why can debate fail to improve quality in a multi-agent system, and what decision rules can the architecture add to prevent unproductive debate?

Debate may not improve quality because agents can

repeat the same mistake,
agree due to the same misleading information, or
create long discussions without reaching a decision.

To convert discussion into an outcome, the architecture should include a decision rule, such as

coordinator selection,
explicit criteria,
voting, or
human approval.

In the research debate pattern, what are the roles and what does each contribute to the final output (including how uncertainty is handled)?

Research agent: gathers evidence.
Two analysis agents: independently interpret the evidence.
Critic: identifies unsupported claims and disagreements.
Synthesizer: produces a conclusion that preserves uncertainty where evidence is insufficient.
Supervisor: approves the final report for a high-impact use.

If you must architect debate or negotiation with LLM agents, what design principle ensures “meaningful interaction” rather than several identical runs, and what architectural elements turn disagreement into a justified joint outcome?

Use independent proposals plus criticism so agents expose different assumptions and actively challenge one another, enabling a coordinator to compare alternatives rather than aggregating identical outputs. Then add a decision rule and a verification stage (verification against the original goal) to convert disagreement into a justified joint outcome.

In the BDI framework, what are beliefs, desires, and intentions, and how do they differ in what they represent for an agent?

Beliefs: what the agent currently thinks is true (its current view of the world/state).
Desires: the goals the agent wants to achieve (what it is trying to bring about).
Intentions: the plans the agent has committed to executing (what it has decided to do next, not just what it wishes).

Key distinction: beliefs describe current perceived truth, desires describe preferred outcomes, and intentions describe committed action plans.

In a modern LLM agent, what can beliefs, desires, and intentions map to (one mapping for each), based on the BDI-to-LLM correspondence?

Beliefs may correspond to the agent’s current context and retrieved information.
Desires may come from the user’s request and system instructions.
Intentions may be represented by the current plan that guides the next tool call or action.

A coding-team coordinator agent follows BDI. Given this situation: it thinks a reported bug affects a particular module, it wants a tested fix, and it plans to ask an analysis agent to inspect the module and then ask an implementation agent to edit it. Identify the coordinator’s belief, desire, and intention.

Belief: the reported bug affects a particular module (what it currently thinks is true).
Desire: produce a tested fix (the goal it wants to achieve).
Intention: ask an analysis agent to inspect the module, then ask an implementation agent to edit it (the committed plan it will execute).

In BDI terms, what should happen when a test fails and the agent’s belief changes, and why is that relevant to orchestration in multi-agent systems?

When the test fails, the agent’s belief about what is true changes, and therefore its intention must be revised (the committed plan should be updated to fit the new believed state). This matters for orchestration because multi-agent coordination depends on agents acting on current beliefs; outdated beliefs can lead to committing to the wrong plan and misdirecting other agents’ work.

Why is BDI useful for multi-agent architecture, specifically for preventing coordination failures?

BDI is useful because it clarifies for each agent:

What it knows (beliefs),
What it wants (desires),
What it has committed to doing (intentions).

Coordination failures can occur if agents have incompatible goals (conflicting desires) or outdated beliefs. In those cases, coordination must resolve the conflict and align agents before they act.

When explaining why agents coordinate in a multi-agent system, what BDI-based distinctions should you make about differences between agents, and what architectural implication follows?

You should distinguish that different agents may:

possess different information (different beliefs),
pursue role-specific goals (different desires),
commit to different plans (different intentions).

The architectural implication is that their actions can conflict unless they exchange state and align their intentions, so explicitly mapping beliefs/desires/intentions supports coordinated behavior rather than isolated reasoning.

In agent design, what distinguishes a reactive agent from a deliberative agent, and why are many real systems hybrid?

Reactive agent: responds directly to an observation or new event, emphasizing fast response over deep analysis.
Deliberative agent: maintains an internal model and typically plans before acting, emphasizing analysis and goal-directed planning.
Hybrid agent: combines both because practical environments often require
- quick reactions to urgent or unexpected changes, and
- deliberation for complex tasks where planning and dependencies matter.

For modern LLM agents, which part of behavior is described as reactive, and which prompting method is described as adding a more deliberative planning layer?

Reactive component: next-token generation, because it depends on the current context and produces an immediate continuation.
More deliberative planning layer: Chain-of-Thought prompting methods, which can add a structured reasoning/planning step before producing the final response.

In a multi-agent architecture, how can the reactive vs deliberative distinction be distributed across roles? Provide a concrete role split consistent with the material.

A multi-agent architecture can assign different cooperating agents to different behavioral functions:

Monitoring (reactive) agent: reacts to a new event as it occurs (fast response to urgent changes).
Planning/coordination (deliberative) agent: reasons about the broader response by analyzing dependencies and future actions, forming a plan before committing complex actions.

This distribution supports quick responsiveness without abandoning global planning.

When selecting agent roles for a dynamic multi-agent environment, what design rationale supports combining quick reaction with global planning?

Combining reactive and deliberative behaviors matches the architecture to dynamic environments because:

Reactive behavior enables the system to respond quickly to immediate events and urgent changes.
Deliberative behavior enables planning for complex tasks by reasoning about dependencies and future actions.
Combined (hybrid or distributed across agents) ensures fast response without abandoning broader, coordinated planning.

When architecting a multi-agent system, what is the correct starting point and how should that drive decomposition and agent boundaries?

Start from the global goal and success criteria, not from a preferred framework or a fixed number of agents. Then:

Decompose the goal into subtasks
- Pick subtasks with distinct responsibilities or that require independent verification.
- Subtasks may be dependent or parallel.
Assign ownership
- Decide which agent owns each subtask.
- Specify what information must cross the boundary between agents (messages/outputs/state).

What agent interaction loop should a multi-agent architecture specify, and what does each stage mean?

The architecture should specify the loop: observe → reason or plan → communicate or act → observe result → update state.

observe: obtaining relevant information.
reason or plan: selecting the next step.
communicate or act: interacting with another agent or the environment.
observe result: seeing what happened after the action/communication.
update state: incorporating the result into later decisions.

In a complete multi-agent architecture, how should planning, memory, tool use, and action relate to each other (phases vs interleaving)?

They should be interleaved rather than isolated phases:

Planning needs information from memory, so memory must be accessible during planning.
Tool use depends on planning, so tool calls are chosen based on current plans.
Actions update what the system knows, so results must feed back into memory/state and influence subsequent planning.

This supports an ongoing loop where agents repeatedly observe, coordinate, act, and update decisions.

Given a need to design a complete multi-agent application, what are the main steps of the architecture design process from objective to validation?

A complete process is:

State the shared objective and success criteria.
Identify the environment and its uncertainties.
Decompose the objective into dependent or parallel subtasks.
Assign each subtask to a specialized agent.
Define the messages, outputs, and state each agent receives.
Choose an orchestration pattern: coordinator, peer-to-peer, or hybrid.
Add criticism, verification, and escalation where needed.
Define reactions to failure or environmental change.
Test whether the complete workflow reaches the original objective.

Which orchestration patterns are explicitly named for multi-agent systems, and what additional mechanisms should be added “where needed” to strengthen outcomes?

The explicitly named orchestration patterns are:

Coordinator
Peer-to-peer
Hybrid

Where needed, strengthen the system by adding:

Criticism
Verification
Escalation

These are chosen based on the task’s requirements for checking work and handling difficult cases.

Why does the summary argue a multi-agent architecture should be adaptive and goal-directed rather than a fixed sequence of unrelated LLM calls?

Because in a multi-agent application:

Each action changes the shared state and may reveal new information.
Therefore agents must repeatedly observe, coordinate, act, and update their plans.
Design should start from success criteria and derive roles, messages, orchestration, and verification mechanisms from the task.

This makes the architecture responsive to outcomes rather than pre-scripted.

In a multi-agent coding workflow, what specialized agents can be used, and what does each one contribute to the end-to-end process from bug report to accepted patch?

Issue-analysis agent
- Perceives the codebase to find relevant code and infer the likely cause of the issue.
Implementation agent
- Plans and applies changes by modifying the appropriate files to produce a patch.
Test agent
- Runs checks (e.g., compilation/tests) and reports failures to provide verification feedback.
Review agent
- Evaluates the patch for correctness and unintended effects beyond what tests catch.
Orchestrator
- Routes outputs between agents and uses test/review results to accept the patch or trigger another iteration.

Describe the orchestration loop for coordinating multiple coding agents when a patch may need iteration. Include what the orchestrator sends where, and what conditions trigger another cycle.

The orchestrator sends the issue analysis to the implementation agent so it can produce a patch.
After the patch is produced, the orchestrator sends it to both the test agent and the review agent.
The test agent executes checks and reports failures; the review agent evaluates correctness and unintended effects.
The orchestrator uses these results to accept the patch or request another iteration.
Another cycle is triggered if tests fail or if the review finds a problem.

Why is coding described as “especially suitable” for agentic multi-agent systems, and how does that affect the system’s verification/orchestration design?

Coding is especially suitable because compilation and tests provide relatively clear success criteria. That clarity supports an architecture where verification is a first-class stage in orchestration:

agents can modify files and then verify the result with tests, producing actionable pass/fail signals.
the orchestrator can use those test outcomes (and review feedback) to accept changes or trigger iterative improvement when checks fail.

Explain the perception-action loop illustrated by a coding-agent system (e.g., Claude Code). What are the key stages of the loop?

A coding-agent perception-action loop consists of repeated stages that connect the shared environment (the codebase) to decisions and verification:

Observe the codebase (perception of current state).
Reason about changes needed to address the issue.
Edit files to apply the intended changes (action on the environment).
Verify with tests to check whether the result meets success criteria and to detect failures.

How does a permission system implement human-in-the-loop control in a coding-agent tool-using workflow, and what policy split is described?

Human-in-the-loop control can be implemented by a permission system that distinguishes between operation types:

Safe operations may be performed autonomously by the system.
Potentially destructive commands require human approval before execution.

In a coordinated coding-agent architecture, what is the five-step coordination chain from initial diagnosis to a final accept/iterate decision, and what does each step accomplish?

Analysis agent: identifies the relevant code and the likely cause.
Implementation agent: changes the appropriate files to create a patch.
Test agent: executes checks and reports failures.
Review agent: evaluates correctness and unintended effects.
Orchestrator: uses test/review results to accept the patch or request another iteration.

In a multi-agent system, how should you architect permission boundaries and human oversight to keep autonomy controllable (especially when actions can be irreversible)?

Bind autonomy to explicit permissions and responsibility
- Allow agents to do lower-risk work (e.g., inspect files, propose changes) while constraining high-impact operations.
Require approval before irreversible/high-impact actions
- Examples include deleting data, deploying software, or running destructive commands.
Place strongest oversight at the recommendation → irreversible action boundary
- This is where the system transitions from proposing an action to executing an action that is hard to undo.
Justification
- Agent outputs can be variable/probabilistic, and multiple agents can amplify one another’s mistakes, so supervision must be tightest before irreversible operations.

An architect is deciding what a multi-agent system may do autonomously versus what must require confirmation. What specific oversight decisions should be made?

Which actions are safe to automate?
Which actions require confirmation?
Which agent can authorize a high-impact action?
What evidence must be provided before approval?
How does the system recover after failure?
Can a human inspect intermediate reasoning, tool results, and the final decision?

Why does a multi-agent architecture typically need stronger supervision than a single-agent setup, and where should that supervision be concentrated?

Why stronger supervision is needed
- Agents can produce variable outputs, and when multiple agents interact they can amplify one another’s mistakes, increasing the chance of harmful or unexpected actions.
Where to concentrate supervision
- Put human oversight at the point where the system moves from recommendation to irreversible action, so the most consequential steps require the strongest control.

When implementing a human approval gate for high-impact actions in a multi-agent system, what must the architecture enable the human to inspect?

Intermediate reasoning
- The reasoning that leads from the task and constraints to the proposed action.
Tool results
- The outputs from any tools the agents used to support their recommendation.
Final decision
- The final recommended action that is being presented for approval.

In a bounded-autonomy multi-agent system, which kinds of actions are appropriate to allow automatically, and which should require approval? Provide the distinction with examples.

Appropriate to allow automatically (lower risk)
- Let an agent inspect files or propose changes automatically.
Should require approval (high-impact/irreversible)
- Require confirmation before deleting data, deploying software, or running destructive commands.
Reason for the split
- These boundaries help keep responsibility clear and limit damage from variable outputs or amplified errors across multiple agents.

In an exam architecture question about a multi-agent system, what are the first two things you should identify and state before proposing agents and workflows?

Global objective + measurable success condition
- State what the system is trying to achieve and how success will be measured.
Environmental properties
- Classify the environment (e.g., partially observable, stochastic, sequential, dynamic, and where relevant, multi-agent) so later architectural choices are motivated by constraints.

For an exam answer proposing a multi-agent architecture, what elements must you include to show why multiple agents are needed (not just list them)?

Explain why one agent is insufficient
- Connect the insufficiency to the system goal and environmental properties.
Define specialized roles with distinct responsibilities
- Assign agents different tasks rather than duplicating the same function.
Describe interactions
- Explain collaboration, debate, or negotiation (not just the agent names).
Describe communication/orchestration
- State the orchestration pattern and justify why it fits.

When describing each agent in a multi-agent design, what input/output details should you specify to make the design assessable?

What the agent receives
- Specify the information/observations or messages the agent takes as input.
What the agent returns
- Specify the agent’s output (e.g., decisions, analyses, actions, or messages) that other agents or the orchestrator use.
Responsibility boundary
- Keep inputs/outputs aligned to the agent’s distinct responsibility.

What orchestration options should you consider in a multi-agent architecture exam answer, and what must you do beyond naming one?

Centralized orchestration
Distributed orchestration
Hybrid orchestration
Required: justify the choice
- Explain why the selected centralized, distributed, or hybrid orchestration is appropriate for the goal and environment.

In an architecture exam answer, what reliability and assurance elements should you include after describing collaboration/orchestration?

Verification
- Explain how outputs/actions are checked before final action.
Failure handling
- Explain what happens when an agent fails or returns unusable results.
Human approval
- State where human approval is required in the workflow.

What two “completion checks” should you include to strengthen a multi-agent architecture answer and demonstrate the full workflow and tradeoffs?

Trace one complete example
- Walk through the end-to-end flow from observation to final action, showing how agents interact under the chosen orchestration.
Compare against a simpler single-agent alternative
- Explicitly contrast your multi-agent design with a single-agent approach to clarify what is gained and why your choices are appropriate.

In an exam, why is it incomplete to (a) list agents without more detail or (b) name a framework without more detail, and what must you add in each case?

Listing agents alone is incomplete
- You must also describe their interactions (communication plus collaboration/debate/negotiation) and how those interactions achieve the goal.
Naming a framework alone is incomplete
- You must explain the workflow: what each agent receives/returns and the orchestration pattern that moves from observation to final action.
Overall requirement
- A strong answer explains why each architectural choice is appropriate.

In architecting a multi-agent system, what distinguishes an agent from “an LLM call,” and why is “LLM = agent” a common mistake?

An agent is defined by

Architecture (how components are arranged to act)
Autonomy (can make and execute choices)
State (maintains relevant memory/context over time)
Goal-directed decisions (selects actions to pursue objectives)
Environmental action (can affect the world via tools/interaction)

The mistake is thinking agency depends on whether the system uses GPT-4, Claude, or another model; instead, agency depends on these system-level properties and behaviors.

When describing a multi-agent architecture, what must you do to avoid the mistake “listing several agents without assigning distinct responsibilities”?

You must assign distinct responsibilities to each agent and make them functionally different within the architecture. A complete description explains

Who does what: specialized roles rather than multiple interchangeable agents
Why roles are separated: each role supports the shared goal in a different way
How responsibilities interact over time (not just a static list)

What information must be included when you describe agent-to-agent communication in a multi-agent system?

Do not describe communication vaguely; specify what information is exchanged. A sound description includes

The content of messages (what is passed)
The purpose of exchanging it (how it supports decisions)
The effect of exchanged information on other agents’ actions or a shared decision

Why are “parallel LLM calls” not necessarily a multi-agent system, and what condition makes it qualify as multi-agent?

Parallel LLM calls are not a multi-agent system if the outputs are independent. It qualifies as multi-agent only when outputs

Affect one another, or
Affect a shared decision

i.e., there is coordinated interaction rather than isolated responses.

In a multi-agent architecture, how should you handle disagreement, conflicting outputs, stale information, and environmental changes?

You should not ignore them. When agents disagree, include

A coordinator, decision rule, or explicit negotiation mechanism to resolve conflicts
Verification rather than assuming one agent’s output is correct
Architecture responses to uncertainty and change, including stale information and environmental changes

What should an architecture description include about human involvement for risky actions?

It must explain where human approval is needed for risky actions. This is part of demonstrating an architecture’s suitability: the design should make explicit when autonomous action is insufficient and human approval gates execution.

How can the historical progression (expert systems → BDI → multi-agent research → modern LLM agents) be used to justify design choices in a multi-agent system?

It provides justification by linking design needs to known limitations and advances:

Expert systems: explainable rules, but brittle and suffered from a knowledge bottleneck
BDI research: formalized beliefs, desires, and intentions
Multi-agent research: developed coordination and negotiation
Modern LLM agents: combine broad language-based knowledge with tools, memory, planning, and interaction

Apply the checklist “shared goal + specialized roles + coordinated interaction + verification → effective multi-agent architecture”: what must an exam-quality answer add beyond stating the formula?

The formula is a checklist, not a substitute for explanation. An exam-quality answer must show

How roles interact over time (dynamic orchestration)
How the architecture responds to uncertainty and change
Why the final design is suitable for the given application
A concrete end-to-end example that demonstrates the architecture works

How should partial observability and dynamic environmental change influence both (a) what agents must communicate and (b) which orchestration pattern you choose in a multi-agent system?

Partial observability and dynamic change imply agents will hold different, possibly stale views of state, so the architecture must enforce state-sharing and re-evaluation.

Communication content
- Share observations that others lack (e.g., inspected files, test results) and share current plans/results so another agent does not act on outdated assumptions.
Orchestration choice
- Centralized fits when progress, permissions, and final responsibility must be clear, and when a coordinator must detect staleness and trigger revision/verification.
- Hybrid fits when specialists need direct exchange of fresh local findings, while a coordinator still controls the global goal.

How do specialized roles and explicit verification together reduce the risk from stochastic LLM outputs in a multi-agent architecture?

Stochasticity means the same prompt can yield different (and sometimes wrong) outputs, so the architecture should separate “produce” from “check.”

Specialized roles
- A proposer role (e.g., planner/executor) generates a candidate solution or patch.
- An independent critic/reviewer/verifier role evaluates it for errors, unsupported assumptions, and whether it meets explicit criteria.
Explicit verification
- Add a decision rule (e.g., coordinator selection, explicit criteria, voting, or human approval) and a verification stage before acceptance, so variance becomes detectable rather than silently propagated.

How can BDI (beliefs, desires, intentions) be used to specify what must happen in orchestration when a verifier reports failure (for example, failed tests) in a multi-agent coding workflow?

A verifier’s failure report changes the system’s beliefs, which should force an update of intentions under the same desire.

Beliefs: incorporate the new evidence (e.g., “tests fail” or “patch breaks another module”) into shared state so other agents do not proceed on outdated assumptions.
Desires: typically remain the same (e.g., “produce a tested fix”).
Intentions: the orchestrator should revise the committed plan—triggering another cycle (new analysis → revised implementation → re-test → re-review) rather than proceeding to approval.

When a task is ambiguous, how should a multi-agent system combine the debate workflow with orchestration and final verification to avoid unproductive discussion?

Use debate to surface alternatives, but use orchestration plus decision rules to convert disagreement into a justified outcome.

Debate workflow
- Independent reasoned proposals, then critic agents search for errors/conflicts.
Orchestration
- A coordinator/synthesizer compares arguments and enforces a stopping/selection rule rather than letting discussion continue indefinitely.
Decision + verification
- Add explicit criteria, coordinator selection, voting, or human approval, and require verification against the original goal before accepting the result.

How can the reactive vs deliberative distinction be distributed across roles, and how does that connect to handling a sequential, changing environment?

In sequential, dynamic settings, the architecture benefits from both fast response and global planning, so distribute these behaviors across cooperating agents.

Reactive role
- A monitoring/response agent reacts quickly to new events (e.g., new commit, new failure signal) so the system notices change promptly.
Deliberative role
- A planner/coordinator reasons about dependencies and forms/revises the plan before further actions occur.
Connection to the environment
- Because earlier actions change state and the environment can change independently, the reactive agent detects changes while the deliberative agent updates intentions and re-coordinates work.

Architect multi-agent systems with appropriate collaboration, debate, and orchestration patterns

76 important questions on Architect multi-agent systems with appropriate collaboration, debate, and orchestration patterns