The computational structure of multi-agent systems: pipelines, orchestrators, and debate

Represent an execution as a graph

An execution that has already been expanded can be represented as a directed graph G = (V, E). Nodes are execution steps with inputs, outputs, and status: model calls, tool operations, programmatic checks, or artifact commits. Edges express dependencies. A persistent logical agent usually corresponds to many nodes, so agent count is not the width of the computation graph.

The meaning of an edge matters. A data dependency says that a step requires an artifact. A control dependency determines who may start, cancel, or select subsequent work. A messaging relationship determines who can see which information. A central scheduler can arrange tasks that never communicate, and participants can exchange messages without acquiring scheduling authority. Drawing every relationship as the same arrow hides these constraints.

The context visible to a model is a projection of execution state. The full state also includes task queues, tool results, artifact versions, budgets, and external side effects. Putting all conversation records in one window does not make these states consistent. Splitting records across windows does not establish that the tasks can be completed independently.

Pipelines encode stable dependencies in the runtime

When steps and dependencies can be specified in advance, a pipeline can be expressed as a static DAG. It can include branches, conditional gates, and fan-out/fan-in: expand an input into parallel branches, then merge them when an agreed condition holds. Stages need not correspond to different agents. The same model can be called repeatedly, and a programmatic check may use no model at all.

A pipeline makes correctness conditions explicit at boundaries. Structured extraction must retain source locations. Validation must identify which fields passed. Synthesis may consume only explicitly permitted versions. Format validation checks structure; semantic validity still requires appropriate evidence, tests, or human judgment. A successful node does not make every conclusion in its output trustworthy.

A process with fixed stages can support rework. A DAG describes dependencies within one attempt; an outer controller creates retries, or a predefined bounded loop manages them. Expanding attempts into separate versioned executions preserves their ordering. The important part is to retain stable stage contracts and rerun only successors whose inputs or premises changed, rather than restarting the entire task after every failure.

Orchestrators expand the task graph during execution

The harder case is discovering which subproblems exist through exploration. An orchestrator-workers design reads current state, proposes new tasks, selects workers, and revises its plan from their results. Running ten predefined tasks concurrently already involves scheduling, but does not yet involve this kind of dynamic task generation.

The orchestrator can be code or include model decisions. New tasks are checked for duplication, write conflicts, and budget. A task moves from WAITING to READY only when its required input versions are committed and still valid. A ready task must still wait for execution slots and rate-limit capacity: satisfied dependencies do not imply immediate dispatch.

A delegation pins the question, input versions, expected artifact, read/write scope, and termination conditions. If a discovery changes scope, record which premise changed. One conservative state protocol is:

WAITING → READY → RUNNING → VALIDATED → COMMITTED
RUNNING → FAILED
VALIDATED → STALE

A returned call produces a candidate. Validation moves it to VALIDATED; matching dependency versions and a successful commit move it to COMMITTED. Only then may a successor consume it as validated input. Failure of a required child leaves its parent blocked, with the protocol choosing retry, replanning, or failure. If partial fan-in is allowed, the conditional artifact must retain the missing items.

Separate contexts can isolate exploration, while giving the orchestrator compression and integration work. If branches continually need the same implicit decisions, communication may consume the gain from parallelism. I would first delegate investigations with clear boundaries and keep decisions that require joint modification together.

State ownership determines how results commit

Multiple contexts become troublesome when participants hold different interpretations of the current state. Assigning a writer to a mutable artifact while other tasks propose candidates from pinned snapshots can reduce overwrites. Ownership may transfer between stages, but the runtime must record and enforce the transfer rather than relying on role prompts.

Each result should identify its input artifacts and versions, execution configuration, validation status, and output version. If two tasks read version v and one commits v+1 first, the other result must be assessed against the content it actually depends on. It may require recomputation or remain usable after checking. It should not overwrite newer state directly.

Context compression should respect dependency boundaries too. What a summary retains or discards changes the judgments available downstream. Rather than repeatedly inserting complete logs into a window, I would retain retrievable original traces and separately pass the decisions, constraints, and evidence locations the task needs. A short summary does not guarantee completeness. If recipients cannot detect missing premises from the handoff, revise the format or undo the split.

inputs = store.read_pinned(task.dependencies)
proposal = run(task, inputs)
if not validate(proposal, inputs):
    return FAILED
return store.commit_if_dependencies_match(
    proposal,
    expected_versions=inputs.versions,
    writer=task.owner
)

This assumes the store checks dependency versions and commits atomically; a separate check followed by a write leaves a race. The pseudocode handles only artifacts managed by that store and does not make remote tool side effects atomic. A code change may also encode decisions about interfaces, paths, or data formats. Those constraints must enter shared artifacts instead of remaining in one agent's conversation.

Critical paths and synchronization limit parallelism

For an expanded, fixed DAG, let node v occupy an execution resource for duration t_v. Total work is W = Σ_v t_v, with at most P interchangeable execution slots. Ignoring scheduling overhead, completion time L is bounded below by:

CP is the critical-path length. This bound assumes known node durations, interchangeable slots, and a graph that correctly represents dependencies and communication time. Real systems additionally require accounting for LLM API rate limits, provider-side queues, and heterogeneous resources. Dynamic task generation leaves the full graph unknown in advance. The formula identifies bottlenecks; it does not directly predict an LLM workflow's latency.

If fan-in must wait for every branch, a slow branch delays the merge. Allowing partial results to drive later work can reduce some waiting, but requires rules about acceptable gaps, late-result merging, and revisions to judgments already produced. A timeout cannot be interpreted as negative evidence.

Synchronous updates have participants read the same round snapshot and commit after all finish. Sequential updates let later participants see earlier revisions. Asynchronous updates may read states of different ages. They can use results sooner while making version checks and cancellation more complex. Parallel calls do not automatically imply an asynchronous protocol, and additional agents cannot shorten an inherently sequential critical path.

Debate is a local protocol that connects candidates

Debate can occupy a local subgraph: preserve initial answers that are hidden from one another, send specific claims and support to other participants, and record challenges, responses, and revisions. Compared with independent sampling followed by voting, it adds information dependencies between candidates rather than simply another sample.

Records should point to checkable objects such as a derivation step, test result, or source passage. Participants may contribute counterexamples or report no additional support. Fixed supporting and opposing roles, or demands for new evidence in every round, can turn discussion into compliance with a role. Blinding initial answers reduces direct following but does not remove correlated errors from shared models or sources.

Communication topology, round updates, adjudication, and stopping are separate choices. Messages may pass through a moderator or only between neighbors. A judge may return a conditional conclusion or abstain. Consensus does not replace tests or evidence checks. If communication overwrites a correct candidate, preserved versions should make the regression visible.

Topology and history retention jointly determine input volume

Start with a simplified model that counts only message inputs received from other participants. There are N ≥ 2 participants on a fixed topology, and every new message contains ℓ tokens. Self-delivery is excluded. A fully connected graph has N(N−1) directed deliveries per batch. In a directed ring, everyone sends only to the next node, giving N deliveries. Identical text entering several recipients' contexts is counted once per recipient.

Let m be the deliveries per batch. Treat the initial candidates as the first batch. Across R updates, r batches are available before update r. Reading only the newest batch and rereading all received history respectively produce the following communication-input totals:

These quantities count how often messages are read as model input. They exclude base prompts, local history, tool results, output generation, and message wrappers, and ignore caching, truncation, and compression. Sending to several recipients can reuse text already generated, so input duplication must not be treated as duplicated output generation. Input tokens are also not identical to billed cost or actual compute.

Reducing edges changes information visibility. A piece of information may need N−1 hops to reach the furthest node on a directed ring. At a fixed round count, the ring cannot be assumed to have seen the same candidates as full connectivity. Fixed-length messages may also lose details during relay. The input-volume comparison does not rank effectiveness; topology and rounds must be evaluated alongside task outcomes.

Central summarization introduces another tradeoff. Add a separate center connected to these N participants: a round has N uplinks and N downlinks. Assigning ℓ tokens to every message body is possible only if each downlink is compressed to that fixed length, changing its information content. The center also has reading and summary-generation costs. If everyone still needs everyone else's original messages, routing them through two hops does not eliminate the content they must read.

Propagate recovery through dependencies; enforce authority at execution

A checkpoint should preserve committed artifacts, input versions, queued and in-flight tasks, consumed budgets, and side-effect status. Recovery must distinguish completed, failed, timed-out, and unknown outcomes. A failed read can usually be retried. A timed-out external write may already have succeeded; query its status or use an idempotency key instead of executing it again blindly.

When inputs or configuration change, invalidate affected results through recorded dependencies instead of clearing the entire task. For cacheable steps, keys should cover the model, prompt, generation configuration, tool, and input versions that affect the result, with tool-result validity checked as well. Being able to resume does not guarantee identical token-by-token replay. Preserve the state needed to inspect and continue execution.

Check authority at execution: delegation carries only permitted read/write capabilities, and retrieved materials or other agents' messages cannot promote themselves into instructions. Scheduling authority does not expand tool permissions. State ownership addresses artifact races; authorization determines whether an action may execute. Neither replaces the other.

Combine the mechanisms at different layers

One manageable combination uses static outer stages for input acquisition, candidate generation, validation, and commit. An orchestrator expands a local task graph only when a stage discovers an unknown subproblem. A bounded debate begins only when a specific disagreement could change the result. Each local process returns an explicit status before execution returns to the outer dependencies.

The combination depends on return semantics. Who waits for and cancels tasks created by the orchestrator? Which checks rerun when debate overturns a premise? Can unresolved disagreement be committed as a conditional artifact? These rules determine how the graph changes. Adding a manager and reviewer to every stage can turn stable dependencies into repeated explanations.

Verification itself consumes resources on the critical path. If the synthesizer must reread every branch's complete materials and repeat all tool calls to assess usability, candidates may be generated in parallel while acceptance approaches a serial rerun. Return formats should make premises and check results locally inspectable. Measure that saving across the complete task; earlier branch completion alone does not establish a speedup.

I would prioritize parallelism for read-only exploration and candidate generation, with shared-state integration concentrated at explicit commit points. If branches continually exchange large amounts of detail, or every commit invalidates other branches, I would first undo the split and examine whether one execution trace should maintain those decisions.

Read framework components in terms of execution semantics

A framework name does not settle these choices. In CrewAI documentation checked in October 2026, a Crew defaults to sequential. Hierarchical execution must be selected explicitly with manager_llm or manager_agent. Sequential execution expresses a predefined order; hierarchical execution introduces managerial delegation and checking. Neither defines an application's artifact versions or acceptance conditions.

Microsoft Agent Framework provides sequential, concurrent, handoff, group chat, and Magentic orchestrations. Group chat can itself use a central orchestrator to select speakers; Magentic uses a manager for dynamic coordination. Shared conversation, central control, and dynamic tasks can coexist. The label group chat does not imply the absence of a center.

AutoGen is now archived and can serve as a mechanism reference. Its classic debate example combines sparsely connected solvers with an aggregator. When choosing components, I would keep asking whether returns block, how messages enter contexts, how failures persist, and who commits shared state. Those behaviors determine whether the system matches the design more directly than pattern names.

Judge additional structure by task outcomes

Before comparing designs, fix the task set, input snapshots, model versions, tool scope, and acceptance criteria, and retain tasks not used for tuning. Include a single-agent baseline, then compare independent candidate aggregation, static pipelines, dynamic delegation, and local discussion. To assess communication, reuse the same initial answers where possible so differences in candidate quality interfere less with the comparison.

Equal agent counts do not imply equal budgets. Count input and output tokens, tool calls, coordination, summarization, and failed retries, while reporting actual cost and elapsed time. Under a fixed budget, compare completion quality. At a fixed quality target, compare cost and latency. These are different questions and should not become one unconstrained claim of being better.

Process records should explain outcomes: what blocked the critical path, how many tasks were duplicated or invalidated, how much recomputation local recovery avoided, and which correct candidates communication changed into errors. Timeouts, abstentions, and exhausted budgets belong in the complete task set rather than being excluded from successful runs. Repeated trials help reveal variance, but failure types and affected scope also need inspection.

I would first make a shorter execution graph reliable, then add structure for an observed bottleneck: try parallelism for insufficient exploration coverage, dynamic delegation for repeatedly missed unknown subproblems, and communication when a specific judgment remains unresolved by existing checks. Each change needs an objective that can be recorded and verified. That gives a reason both to retain an agent and to remove one.