Structuring agent control and coordination

Compare tool loops, ReAct, planning followed by execution, manager-worker coordination, and peer handoffs. For each design, identify who chooses the next step, how state moves, and what happens when work fails or must stop.

The previous lesson traced observations and memory through an agent loop. Orchestration makes the control decisions explicit: which operation runs next, which results it needs, and which component is responsible for the final outcome.

A useful pattern describes those responsibilities and dependencies so they can be implemented and tested.

Orchestration organizes model calls, tools, and state within a task. Some paths are defined in code; others are chosen from model output. A single workflow can combine both, for example by using fixed validation before a model chooses its next search.

Scope note: These are common implementation strategies, not a fixed or mutually exclusive taxonomy. Compare them by their control flow, state ownership, and stopping conditions.

In this lesson, we’ll explore the following:

• Single-controller strategies: Tool loops, ReAct, and plan-and-execute.

• Coordination among agents: Manager-worker delegation and peer handoffs.

• Selection criteria: Task dependencies, specialization, parallel work, and observability.

• Framework examples: LangChain/LangGraph, AutoGen, and CrewAI.

The objective is to explain the control flow before choosing the library that will implement it.

Single-agent orchestration patterns

A single-agent design has one agent responsible for the task’s control loop. It can still call several models or tools. “Single agent” therefore does not necessarily mean one model invocation or one fixed set of weights.

But even within single-agent setups, there are several patterns for how this decision-making unfolds. These patterns differ in how structured the reasoning is, how tools are chosen, and how many steps are taken before producing an output.

Let’s look at a few common orchestration patterns used in single-agent systems:

Tool calling loop

A tool-calling loop asks for a next action, validates and executes the chosen tool, and supplies its result to the next decision. The loop also needs completion criteria, error handling, and a bound on repeated work.

For example, an agent tasked with “Send an email summary of this document” might:

• Read the document and create a summary.

• Check that the summary preserves its important claims.

• Resolve the recipients and send through the authorized messaging API.

• Verify the service result and report completion or failure.

Tool-loop implementations appear in frameworks and can also be written directly against a model’s tool interface. A long chain can amplify earlier mistakes. Record which observation justified each next action and avoid retrying an uncertain external write as though it definitely failed.

ReAct (reasoning + acting)

ReAct interleaves generated reasoning traces with actions and observations. Its research formulation uses intermediate text to help track a task and revise action choices after feedback. A visible trace can aid inspection, but it is generated text rather than a complete record of the model’s internal computation.

For example, an agent asked to “Find the most affordable flight to Tokyo” might:

• Identify the departure point, dates, and constraints.

• Query a flight-search tool.

• Inspect returned prices and availability.

• Compare only options that meet the constraints.

• Return the best supported option among those checked, making the search scope clear.

Tool calling and ReAct are related but distinct: an API can return a tool request without exposing an explicit reasoning trace. More intermediate text also consumes context and can contain errors. Evaluate the actions and final result, not just how convincing the trace sounds.

Plan-and-execute

Plan-and-execute separates an initial planning stage from work on the resulting subtasks. The plan may be produced by an LLM and stored with each step’s dependencies and status. Execution can still reveal a need to revise it.

For example, an agent asked to “write a report on Q2 revenue and email it to the team” first generates a plan:

1. Retrieve Q2 revenue data.

2. Create a chart.

3. Write a summary.

4. Send an email.

The chart depends on retrieved data, and the summary should depend on checked results. If the data is missing or its reporting period is unclear, execution should resolve that issue before proceeding. Sending the report also depends on the authorization required by the workflow.

A planner and executor may be separate components within one application. The main risk is treating an initial plan as settled despite contradictory observations. Define when to replan and which completed results can be reused.

A single controller is often sufficient when it can hold the relevant task context and manage the tools. Multiple agents become a design option when separate responsibilities, permissions, or independently executable work provide a measurable benefit.

The next patterns distribute decisions among agents and therefore need explicit coordination.

Multi-agent coordination patterns

A multi-agent system assigns parts of a task to multiple agents. It can separate contexts or permit concurrent work, but it also adds communication, scheduling, and integration costs. Task complexity alone does not prove that multiple agents are preferable.

This coordination can follow different structural patterns. Let’s look at the most common ones.

Manager-worker pattern

A manager-worker design has a central coordinator that decomposes work, assigns subtasks, and combines results. Workers may have different instructions or tools while using the same underlying model. Task queues and result records can be shared directly or passed through messages.

• Manager: Defines subtasks and their dependencies, assigns work, and checks the combined result.

• Workers: Complete bounded tasks and return results with relevant evidence or failure information.

• Example: For a project proposal, background research can inform the outline and introduction. Visual suggestions may be prepared independently once the scope is known. The manager should respect those dependencies rather than assume all subtasks can run at once.

The manager owns integration: reconcile conflicting claims, identify missing work, and ensure the result answers the original request. It can also become a bottleneck or make poor assignments. Worker completion alone is not proof that the combined deliverable is complete.

Decentralized handoff pattern

In a peer-handoff design, agents pass responsibility according to the task state without one manager making every routing decision. A handoff should identify the new owner, the remaining goal, relevant results, and permitted next actions.

• An agent identifies which peer should handle the next responsibility.

• It passes the task state needed for that responsibility.

• The receiver either accepts the work or reports why it cannot proceed.

• The workflow stops or escalates according to explicit completion and failure rules.

For example, in a travel planning system:

• A travel-intake agent records the user’s constraints.

• A flight-search agent returns available routes and relevant conditions.

• A hotel agent uses the selected destination and dates to search for rooms.

• Booking remains subject to the user’s permissions and the workflow’s approval rules.

Peer handoffs distribute control but need protection against repeated transfers, conflicting owners, and dependencies that never complete. An infinite handoff loop is different from a deadlock in which work is waiting indefinitely. Track both progress and ownership rather than assuming decentralization provides robustness.

Choosing the right orchestration strategy

Choose a control structure by examining the task and its failure modes. A fixed workflow, one dynamic controller, and several agents are alternative ways to organize work.

Before choosing a named pattern, ask:

• Can the needed steps and branches be defined in advance?

• Which decisions depend on newly observed information?

• Which subtasks can run independently, and which need separate context or permissions?

These answers narrow the design before framework choice.

One controller or several agents?

Some tasks are naturally self-contained, while others involve multiple roles, skills, or stages. Choosing between a single-agent or multi-agent setup depends on the structure of the task, and the demands of the system.

Here are the main factors we will consider:

• Scope and boundaries: A meeting scheduler may fit one controller. A broader workplace assistant might separate scheduling, document analysis, and communication if those roles need different context or access.

• Specialization: Separate prompts or toolsets can focus a role, but labeling an agent “legal expert” does not establish expertise. Validate the work through the appropriate sources and review.

• Dependencies and parallelism: Independent evidence-gathering tasks may run concurrently. Translation followed by formatting has a dependency and should preserve that order. Parallel work does not inherently require multiple agents; ordinary concurrent code can run fixed tasks.

• Observability: One controller may be easier to trace. Several agents require correlated task IDs, result records, and a clear integration owner so failures and duplication remain visible.

Selecting an agent orchestration pattern

Once we choose between a single-agent or multi-agent structure, the next step is to select the orchestration pattern that best fits the task dynamics, performance goals, and design constraints.

In single-agent systems, the orchestration pattern depends on how structured or open-ended the task is:

• Plan-and-execute: Consider it when a useful initial decomposition is possible and the executor can detect when that plan needs revision.

• Tool loop: Consider it when search, debugging, or another task requires a next action based on an observation.

• ReAct-style interaction: Consider it when intermediate task reasoning helps guide actions and can be evaluated alongside tool results. A readable explanation alone does not satisfy audit or regulatory requirements.

In multi-agent systems, orchestration depends on how autonomy and coordination are distributed:

• Manager-worker: Use a coordinator when decomposition, dependency tracking, and synthesis need one explicit owner.

• Peer handoffs: Use handoffs when responsibility changes between roles, with a clear contract for transferred state, acceptance, failure, and completion.

Agent orchestration frameworks in practice

Frameworks provide implementations of some of these responsibilities. Their interfaces and support status change, so treat the following as architectural examples and check the version you intend to use.

Compare what each framework makes explicit about state and control.

LangChain

LangChain provides abstractions and integrations for models, tools, and agent loops. LangGraph is a lower-level orchestration runtime for stateful workflows. Its graph can combine fixed code paths with model-directed decisions.

• Model and tool interfaces: Connect model decisions to external operations.

• Graph control: Represent steps, branches, and the state passed between them.

• Persistence and intervention: Support checkpointing and human intervention where configured.

LangGraph can persist workflow state and support long-running execution. Tracing and evaluation tools help inspect runs, but the application still defines meaningful state, validation, and recovery behavior.

Use the distinction to guide an experiment: a prebuilt loop may be enough for one task, while explicit graph state can help with branching or resumable work. Compare the implementation burden and visibility of failures.

AutoGen (Microsoft)

AutoGen is a Microsoft-origin framework for agent communication and coordination. Its Core layer supports message passing, AgentChat offers higher-level conversation patterns, and extensions provide model and tool integrations.

• Agent roles: Configure instructions, tools, and responsibilities.

• Message exchange: Coordinate task state through messages or conversation patterns.

• Execution and interaction: Integrate tools and human input under the application’s control.

As checked in September 2026, the project is in maintenance mode and its repository directs new projects toward Microsoft Agent Framework. AutoGen remains useful for understanding the existing examples, but its support status matters when choosing a new dependency.

A conversation-based design still needs a definition of useful progress. Repeated messages between agents can consume budget without producing evidence or resolving the task.

CrewAI

CrewAI organizes work around agents, tasks, and a configured process. Its documented process choices include sequential execution and hierarchical coordination; a manager is required for the hierarchical form, not for every crew.

In a hierarchical configuration, identify:

• Manager: Plans assignments and reviews progress.

• Workers: Use their configured instructions and tools to complete assigned tasks.

• Task context: Carries the required outputs and state between steps.

The process determines how work proceeds. A sequential process follows the defined task order; a hierarchical process delegates through the manager. Neither guarantees that workers are independent or that all tasks can run in parallel.

Additional features, such as human input, memory, and external tool integrations, must be configured for the chosen workflow. Test the specific path needed by the application instead of inferring behavior from the framework’s overall feature list.

Across frameworks, the same questions remain: who owns each task, what evidence is passed, and what state means complete?

A well-structured system:

• Clearly defines agent roles.

• Provides mechanisms for tracking progress and sharing context.

• Manages control flow gracefully, even when agents fail or disagree.

Choose the framework after those contracts are clear. A small test with a failed worker and an interrupted run often reveals more about the design than a successful demo.

Case study: coordinating a research assistant

Consider a hypothetical research assistant for a product team. It gathers competitor announcements, customer reviews, and internal sales evidence before drafting a recommendation. The system must:

• Gather recent competitor announcements from the web.

• Analyze customer reviews for pain points and common feature requests.

• Retrieve and analyze internal sales reports.

• Synthesize insights and draft a product update recommendation.

Requirements:

• Independent evidence-gathering tasks can happen in parallel.

• Review and synthesis must be coordinated.

• Human approval is required before sending the final recommendation to stakeholders.