Multi-Agent Orchestration

The orchestrator agent is the "conductor" of a multi-agent system.

Orchestrator agent responsibilities:

① Task decomposition — breaking a complex goal into discrete sub-tasks that can be delegated
② Agent selection — choosing which specialist sub-agent should handle each sub-task
③ Delegation — passing the sub-task to the chosen agent with full context
④ Result integration — collecting the sub-agents' outputs and combining them into a coherent final answer
⑤ Error handling — managing failures, retries, or re-delegation when a sub-agent cannot complete its task

Example: A "research report" orchestrator might delegate to:
• A web-search agent (fetches recent information)
• A data-analysis agent (runs statistical analysis)
• A writing agent (drafts the final narrative)

Key vocabulary:
• Top-level task — the original user goal; the orchestrator owns this
• Sub-task — a portion of the goal delegated to a specialist
• Task decomposition — breaking a complex goal into manageable sub-tasks
• Result synthesis — combining sub-agents' outputs into a coherent whole

Sub-agents (worker agents) are specialists — each is optimised for one type of task.

Sub-agent characteristics:
• Has narrow, deep expertise — optimised for one thing (code, analysis, writing, search)
• Receives tasks from the orchestrator via a handoff mechanism
• Works within its scope — doesn't need to know the broader goal
• Returns results to the orchestrator (not directly to the user)

Common sub-agent specialisations in technical systems:

Sub-agent type	Specialisation
Code agent	Writes, reviews, or executes code
Search agent	Retrieves and summarises web data
Data agent	Queries DBs, runs analysis
Communication agent	Drafts emails, messages, notifications

Key vocabulary:
• Worker agent — alternative name, emphasising the sub-agent executes tasks (works), not orchestrates
• Specialist agent — alternative name, emphasising domain expertise
• Agent delegation — the act of the orchestrator assigning a sub-task to a sub-agent

A "crew" models real-world collaborative teams in software.

In CrewAI (and similar frameworks), a crew is a configured group of agents where:

• Each agent has a role (e.g. "Senior Software Engineer", "QA Tester", "Technical Writer")
• Each agent has a goal (what they're optimising for)
• Each agent has a backstory (added context that shapes their perspective)
• The crew has a shared process: how agents collaborate (sequential vs hierarchical vs parallel)

CrewAI crew example:

crew = Crew(
  agents=[researcher, writer, reviewer],
  tasks=[research_task, writing_task, review_task],
  process=Process.sequential  # or hierarchical
)

Crew collaboration models:
• Sequential — agents work one after another; each gets the previous agent's output
• Hierarchical — a manager agent orchestrates specialists (classic orchestrator model)
• Parallel — agents work simultaneously on independent sub-tasks

Key vocabulary:
• Agent role — the functional identity of an agent within the crew
• Agent goal — what the agent is designed to achieve (shapes its decision-making)
• Crew process — the collaboration model (sequential, hierarchical, parallel)

Agent handoff is what makes multi-agent collaboration possible — it's the moment one agent passes the baton.

What a handoff includes:

① Task specification — what the receiving agent needs to do
② Current context — relevant information gathered so far
③ Intermediate results — any partial work the sending agent completed
④ Constraints/instructions — format requirements, time limits, quality criteria

Handoff mechanisms by framework:

Framework	Handoff mechanism
OpenAI Swarm	Agent returns a new Agent object as its response
LangGraph	State transitions between nodes in the agent graph
CrewAI	Task output becomes next task's input in the process

Key vocabulary:
• Context preservation — ensuring the receiving agent has all info needed to continue
• Handoff message — the structured transfer document passed between agents
• Agent transfer — OpenAI Swarm's term for the same concept

Option B correctly identifies and describes a "context loss in handoff" problem using precise multi-agent vocabulary.

The root cause: The handoff payload is incomplete — it doesn't carry the retrieved data from the previous stage.

What a complete handoff payload should include:
• All intermediate results from previous agents (retrieved documents, API responses)
• Current task state (what's been done, what remains)
• Constraints the receiving agent must respect
• Output format specification (e.g. "return a JSON report with confidence scores")

Debugging steps for handoff failures:
① Log the full handoff payload to inspect what's being passed
② Check whether the receiving agent's system prompt instructs it to load handoff context
③ Look for serialisation/deserialisation issues (e.g. complex objects losing fields)
④ Add an explicit "what I already know" section at the start of the receiving agent's prompt

Key vocabulary:
• Context loss in handoff — the receiving agent starts without necessary prior context
• Handoff payload — the complete data package transferred between agents
• Stateless vs stateful handoff — stateless passes all context explicitly; stateful relies on shared memory
• Working context — the information an agent actively holds while executing its task