Parallel agents versus one orchestrator

The choice between parallel agents and one orchestrator is not a question of sophistication. It is a question of task shape. If the work can be expressed as a known list of independent jobs, each returning a defined result, fan it out. If the work is exploratory, and each finding may change what should be investigated next, keep one orchestrator in control of accumulating shared state.

That rule matters in credit-document analysis because apparently similar assignments can have very different dependency structures. Extracting specified fields from 40 indentures is divisible. Determining how a liability-management transaction changes guarantor coverage, collateral value and covenant capacity is not. The second assignment develops through discovery. Its questions, sources and priorities change as the analysis proceeds.

What is the actual decision rule?

Start with three tests:

1. Can the complete job list be written before substantive analysis begins?
2. Can each job be completed without knowing what another worker discovers?
3. Can the expected return from each job be defined precisely enough to combine mechanically?

If all three answers are yes, parallel agents are usually appropriate. If any answer is no, a single orchestrator should normally hold the investigation together.

The distinction is not simply “simple tasks versus difficult tasks.” A difficult assignment can still be parallel if its components are independent. Conversely, a narrow question may require orchestration if the first answer determines which document, provision or transaction step must be examined next.

When does fan-out work well?

Fan-out works when decomposition is stable. Consider a portfolio review in which the required fields have already been settled: issuer, instrument, maturity, governing law, guarantor count, collateral description, restricted payments capacity and debt-incurrence tests. Each document can be assigned independently. The agents can return the same fields, in the same format, with source references.

This architecture offers more than speed. It isolates failures. A malformed return from one document does not contaminate the interpretation of the others. Missing fields can be rerun. Validation rules can reject unsupported answers or require a quoted source passage. The combining step does not need to understand each agent’s reasoning; it needs to verify that the prescribed output contract was satisfied.

Other natural fan-out tasks include:

• locating a defined provision across a fixed document set;
• extracting specified terms from amendments;
• comparing an agreed list of fields across instruments;
• classifying clauses under a settled taxonomy;
• checking each proposition in a draft against its cited source.

The important phrase is settled taxonomy. If the team is still discovering which distinctions matter, the work is not ready for broad parallelisation.

What does failed fan-out look like?

The failure signature is duplicated discovery without cumulative learning.

Suppose several agents are asked to investigate how value moved through a completed restructuring. One studies restricted payments, another studies investments, and a third studies guarantees. Early in the work, the investments agent identifies an unrestricted subsidiary designation that changes the relevance of the other workstreams. In a naïve fan-out architecture, the sibling agents do not receive that development. They continue under their original assumptions.

The resulting memoranda may each be plausible but fail to cohere. Defined terms are interpreted differently. One agent assumes a transfer occurred under an investment basket while another treats it as a restricted payment. A third spends time analysing guarantee release mechanics that became secondary once the transaction perimeter was understood. The final assembler must reconstruct the investigation after the fact.

Common symptoms include:

• multiple agents summarising the same background facts;
• inconsistent names for entities, instruments or transaction steps;
• repeated searches for a document already found by another agent;
• conclusions resting on incompatible factual assumptions;
• unresolved conflicts hidden inside polished individual outputs;
• a long synthesis phase that effectively repeats the underlying analysis.

Adding more agents usually worsens this pattern. More independent discovery produces more divergent local contexts. The problem is not insufficient labour. It is the absence of a mechanism through which one finding changes everyone else’s work.

When should one orchestrator control the work?

Use one orchestrator when the investigation has a branching structure. The orchestrator does not need to perform every task itself. It needs to own the evolving plan, decide what evidence matters next and maintain the authoritative state of the matter.

A covenant analysis often has this form. The initial question may concern debt capacity. Reviewing the document reveals that classification depends on consolidated net income, available amount mechanics or the status of a subsidiary. That finding changes the next task. The orchestrator may need financial disclosures, an amendment, a security document or a corporate-structure exhibit before further covenant calculations are useful.

The sequence cannot be specified reliably at the start:

1. Establish the governing document set.
2. Identify the relevant defined terms and operative provisions.
3. Record facts that change the interpretation.
4. Resolve conflicts or missing evidence.
5. Dispatch the next bounded inquiry.
6. Update the working conclusion.

This is exploratory work even when the final deliverable is structured. The path to that deliverable depends on what is found.

Why does orchestration need a shared ledger?

An orchestrator without disciplined shared state is merely a long conversation. Important facts disappear into history, tentative propositions harden into assumptions, and later tasks consume context that is large but not useful.

The better mechanism is a ledger or dossier. It should be compact, structured and continuously updated. At minimum, it should contain:

The ledger is not a dumping ground for every agent transcript. It is the current model of the assignment. Each entry should be concise enough to retrieve and specific enough to test. Source references should travel with factual propositions. Uncertainty should remain visible.

This discipline also controls context growth. The orchestrator can discard conversational residue while preserving the facts, conflicts and decisions that later steps require. A short dossier with strong provenance is more useful than a large context window filled with repeated summaries.

What does failed orchestration look like?

The failure signature is needless serialisation.

If 100 documents require the same eight fields, a single orchestrator should not open them one by one, extract the fields and then proceed to the next. No result from document 12 changes how document 13 should be processed. Holding the entire job inside one sequential loop adds latency and increases the chance that early and late outputs will be handled inconsistently.

Other symptoms include:

• a growing queue of interchangeable tasks;
• no change in instructions after each completed task;
• idle capacity despite independent work items;
• repeated context loading for unrelated documents;
• one central agent becoming a throughput bottleneck;
• declining consistency as a long sequence accumulates history.

The cure is not to abandon orchestration entirely. It is to let the orchestrator identify the deterministic stage, define its output and dispatch that stage in parallel.

Why must the return shape be decided before dispatch?

Parallelism is useful only if the results can be recombined. Before dispatching an agent, define what must come back.

For a provision-level extraction, that may include:

• document identity and date;
• provision category;
• operative language;
• relevant defined terms;
• source location;
• extracted value or conclusion;
• stated uncertainty;
• missing documents or dependencies.

This return contract forces an architectural decision. If the required fields cannot yet be specified because the investigation is still discovering what matters, the task is probably premature for fan-out. If the schema is clear, parallel execution becomes safer and reconciliation becomes cheaper.

The contract should also distinguish fact from interpretation. “The agreement defines Consolidated Total Assets by reference to the borrower and restricted subsidiaries” is different from “this definition makes the basket unusually permissive.” The former can be extracted and sourced. The latter requires comparison, context and judgement.

How should the two architectures be combined?

Most serious workflows should use both architectures at different levels.

The orchestrator begins by framing the question and building the initial dossier. Once it identifies a stable batch of independent jobs, it fans them out. Agents return structured results. The orchestrator validates those returns, updates shared state and decides whether the next stage is another parallel batch or a focused investigation.

For example, the orchestrator might first determine the relevant document universe. It can then dispatch document-specific extraction in parallel. After reconciling the results, it may identify a conflict between an original indenture and a supplemental indenture. That conflict returns the workflow to exploration. Once resolved, citation checking of the final analysis can again be parallelised.

The architecture therefore alternates:

Explore centrally → define bounded jobs → execute in parallel → reconcile centrally → revise the plan.

This pattern preserves cumulative reasoning without forcing independent work through a serial bottleneck.

What should a credit team require in practice?

Before choosing an architecture, write down the task graph. Mark which outputs change later instructions. Those dependencies, not the number of documents or agents, should control the design.

For parallel work, require a fixed schema, source references, explicit uncertainty and deterministic reconciliation rules. For orchestration, require a maintained dossier, visible open questions, controlled context and a clear record of why the plan changed.

Then watch the failure signatures. If agents repeat discovery and produce incompatible narratives, centralise the exploration. If the orchestrator processes interchangeable jobs sequentially, define the return contract and fan them out.

The correct architecture is not parallel or central by default. It is the smallest coordination structure that matches the dependencies in the work.