Multi-agent orchestration and sessions

Multi-agent orchestration means arranging several artificial intelligence workers so their separate contributions become one controlled, traceable result. The goal is not to collect as many agents as possible, but to divide work where specialisation genuinely improves focus without losing state, authority, or evidence. A single-agent loop normally receives a request, reasons about it, uses permitted tools, inspects the results, and produces an answer or action. Multi-agent orchestration extends that loop by assigning bounded parts of the work to other agents and coordinating what comes back. Giving one powerful agent every tool and every document can look simpler, but irrelevant material may crowd out the facts that matter and excessive capability may enlarge the consequences of a mistake.

Text description

• Specialisation benefit: Focused context, less unnecessary tool access, easier evaluation, and possible parallel work.
• Coordination overhead: More instructions, transfers, waiting, reconciliation, and opportunities to lose context.
• Design decision: Choose multiple bounded workers only when their added value outweighs the boundary costs.

Specialisation means giving a worker a narrower role, such as extracting transactions, interpreting a contract, or retrieving policy versions. That narrower role can reduce distraction, limit unnecessary tool access, and make the worker's output easier to evaluate. Independent tasks may also run at the same time, but only when neither task needs the other's result before it can begin. These benefits have a cost because every boundary creates instructions, transfers, waiting, reconciliation, and another place where context can be lost. Coordination overhead is the time, complexity, and failure risk created by managing those boundaries. If coordination overhead exceeds the benefit of specialisation, one well-scoped agent may be the better design.

Text description

• Coordinator scopes work: Understands the request, selects workers, and supplies each worker with the facts and constraints it needs.
• Subagents perform bounded tasks: Each worker uses its assigned role, context, tools, and permissions without automatically seeing other private state.
• Coordinator tracks and assembles: Reconciles results, handles failures, preserves evidence, and produces the final controlled outcome.

A common arrangement uses a coordinator, which is the agent responsible for understanding the whole request, selecting workers, routing information, tracking failures, and assembling the final result. A subagent is a worker given a specific role, instructions, tools, configuration, and a bounded assignment within that larger job. This coordinator-and-subagent arrangement is often called hub-and-spoke coordination because information normally passes through the central coordinator, although the analogy does not capture every possible communication path. Subagents commonly have isolated context, meaning they do not automatically see the coordinator's full conversation or the private working state of other agents. Isolation can reduce irrelevant exposure, but it also means the coordinator must deliberately supply everything a worker needs.

A useful delegation packet states the objective, relevant facts, available evidence, constraints, permitted actions, expected output, uncertainty requirements, and rules for identifying sources. The vague instruction to research this is unsafe because the receiving worker may not know what this refers to, which sources are authoritative, or what it is allowed to do. Harbour Resolution will be our fictional running example, so none of its cases or outcomes describe a real organisation or deployment. In one hypothetical Harbour Resolution case, a customer disputes a transaction and supplies a contract, a call transcript, a policy history, and an account record. The coordinator first identifies the decision that must be supported, the documents available, the missing information, and the limits on what the system may conclude.

It might ask one subagent to extract contractual obligations and return each obligation with the exact contract section that supports it. A second subagent could build the transaction chronology while keeping recorded timestamps separate from assumptions about why each event occurred. A third could retrieve the policy in force at the relevant time together with later revisions, because the newest policy is not automatically the applicable one. A synthesis agent could then compare the bounded results and create mappings between claims and their sources. The coordinator should invoke only the workers needed for the particular complaint rather than treating every possible specialist as a mandatory pipeline stage.

If a hypothetical complaint contains no call and turns entirely on a duplicated payment, a transcript specialist would add delay without adding evidence. A fixed full pipeline can also inject irrelevant findings that sound important merely because a specialist was asked to produce something. Selective invocation has its own limitation because the coordinator can overlook a useful specialist when its initial reading of the case is wrong. The design therefore needs observable selection reasons and a route for adding a specialist when returned evidence exposes a new issue. A good task boundary produces something independently meaningful, has clear inputs and outputs, and avoids unnecessary overlap with neighbouring assignments.

For example, transaction extraction is independently meaningful because another worker can inspect its chronology without repeating the entire account review. Boundaries can become too narrow when one worker sees a promise in a transcript while another sees a contract restriction, but neither is asked to compare the two. Cross-cutting issues are questions that span multiple evidence types or responsibilities, and the coordinator must reserve a synthesis step for them. Some overlap can be intentional when two independent readings are valuable, but accidental overlap wastes effort and can produce conflicting summaries with no plan for reconciliation. A dependency exists when one task needs information or a decision produced by another task before it can proceed correctly.

Text description

• Policy retrieval: Runs independently from the policy records.
• Transaction extraction: Runs concurrently from the account records.
• Dependency join: Waits for both required results before continuing.
• Policy comparison: Assesses whether the transaction matched the governing policy.

Tasks without such a dependency can run in parallel, which means they proceed concurrently rather than waiting for one another. Tasks with a dependency should run sequentially, which means the later task begins only after the required earlier result arrives. In the fictional complaint, policy retrieval and transaction extraction can proceed in parallel because each can work from its own records. A final assessment of whether the transaction matched the governing policy must wait for both results, so that assessment is sequential. A workflow can be pictured as a route map with branches that join, but unlike a road map it must also describe authority, evidence, and failure at every junction.

Text description

• Track every branch: Record success, failure, timeout, uncertainty, or source unavailability separately.
• Choose a response: Retry, use another suitable specialist, continue with a labelled gap, or hand the matter to a human.
• Constrain the conclusion: Report supported findings while leaving conclusions that require missing evidence unresolved.

Parallel work requires explicit branch status because one successful branch does not prove that the other branches finished. A branch might succeed, fail, time out, return uncertain evidence, or discover that its assigned source is unavailable. The coordinator may retry the failed source, use another suitable specialist, continue with a clearly labelled gap, or transfer the matter to a human. The appropriate response depends on the importance of the missing evidence and the authority required for the next action. Silently dropping a failed branch is especially dangerous because a polished synthesis can make an incomplete investigation look complete. Suppose the fictional transaction worker succeeds but policy retrieval fails; the coordinator may report the chronology while stating that policy compliance remains unresolved.

That response is less satisfying than a definitive answer, but it preserves the boundary between what the evidence supports and what the system merely hopes is true. A subagent should usually return a compact structured result containing findings, supporting evidence, uncertainty, unresolved questions, status, and stable source references. A stable source reference identifies the same underlying material across later processing, such as a controlled document identifier, version, section, and record owner. Structured JSON can help the coordinator parse fields consistently, but correct syntax only means the structure is well formed. Syntax is not truth, so a perfectly formatted JSON field can still contain the wrong date, a fabricated conclusion, or a reference to the wrong document.

Text description

• Source evidence: Information directly supported by an available record, including its identity and relevant version.
• Labelled inference: A conclusion drawn from evidence that remains distinguishable from the underlying facts.
• Provenance history: Tracks where the claim came from and how extraction, summarisation, comparison, or reformatting changed it.

Evidence is information directly supported by an available source, while inference is a conclusion drawn by interpreting one or more pieces of evidence. If a ledger records a debit at a particular time, the debit and recorded time are evidence, but the claim that an employee intended to cause it is an inference unless another source supports intent. Both evidence and inference can be useful, but they should be labelled separately so later reviewers can challenge the reasoning without disputing the underlying record. Provenance is the traceable history of where a claim came from and how it changed as agents extracted, summarised, compared, or reformatted it.

Preserving provenance means carrying source identity and relevant version information through every transformation rather than attaching vague citations at the end. A concise summary should not erase whether a statement came from a signed contract, an unverified note, a model inference, or a human decision. When two agents disagree, the synthesiser should not average their claims or choose the more confident wording. In a hypothetical procurement review, one worker might retrieve a current refund policy while another extracts an older policy attached to the signed agreement. The coordinator should compare effective dates, contractual scope, document ownership, and the authority of each source before deciding whether either policy governs.

Authority here describes why a source or decision-maker is entitled to govern the issue, not merely how recent or confidently expressed it is. If the conflict cannot be resolved, both claims and their evidence should remain visible together with the missing fact needed to settle them. Central coordination makes that conflict handling easier to observe because one component owns routing, branch status, evidence preservation, and final aggregation. Some architectures allow subagents to communicate directly, which can reduce central traffic when collaboration is genuinely dense. Direct peer communication can also create hidden dependencies, duplicate work, inconsistent case state, and provenance gaps when the coordinator cannot see what changed.

A graph-shaped workflow, where several workers exchange results along defined connections, can be appropriate, but each connection needs a clear purpose, rules stating which worker may exchange which information, and records that let reviewers reconstruct what happened. The simplest architecture that preserves the required evidence and authority is usually easier to secure and diagnose. Agent identity and conversation state are related, but they are not the same thing. An agent definition describes a worker's role, standing instructions, permitted tools, and configuration. A session is the continuing conversation and working context accumulated while an agent handles one stream of activity. Resuming a session continues from its prior state, including relevant earlier messages and working assumptions that the platform retained.

Forking a session creates a new branch from an existing point so an alternative line of work can proceed without changing the original branch. In a hypothetical software support case, one fork could explore a configuration rollback while another examines a permissions repair, leaving the accepted diagnostic path intact. Forking is also useful for comparing alternative prompts or exploring a risky hypothesis, provided exploration itself does not grant permission to perform risky actions. Each fork needs a traceable branch identifier, a known starting point, and a rule explaining whether and how its result may return to the main branch. Merging should not mean copying every statement back, because one fork may rely on assumptions rejected by another.

Text description

• Agent session: Holds continuing conversation, working context, and retained assumptions; it may be truncated or summarised.
• Durable application state: Stores important accepted case data independently of any conversation.
• Governance controls: Versioning records changes, ownership assigns accountability, and access rules control viewing and alteration.

A controlled merge selects supported findings, preserves their branch provenance, records conflicts, and requires the appropriate authority for any consequential change. Conversation history should not be treated as the only system of record, which is the durable authoritative store for important case data. Sessions can be truncated, summarised, misinterpreted, or separated from the application that owns the underlying business state. Important case state should therefore live in durable application storage, where versioning records each accepted change, ownership identifies who is accountable for maintaining and approving changes to the state, and access rules specify who may view or alter it. The session is a reasoning workspace around that durable state, much like a workbench beside a filing system, although the analogy stops where software permissions and version rules begin.

Long-running work creates context pressure as documents, tool results, drafts, and subagent messages accumulate. The coordinator should retain task-defining facts, evidence summaries, accepted decisions, source mappings, branch status, and open issues. Duplicated boilerplate, superseded drafts, and bulky raw output can be omitted from active context when they remain safely stored and retrievable elsewhere. Careless summarisation can create a new failure mode by dropping qualifications, merging opposing claims, or turning an unresolved inference into an apparent fact. Hooks provide another layer of control around agent activity. A hook is system code that intercepts a defined lifecycle event so the application can validate, log, transform, allow, deny, or trigger a predictable action.

Text description

• Prompt guidance: Asks the model to remember and interpret a rule, without guaranteeing that an operation will be stopped.
• Trusted pre-tool hook: Checks a proposed operation and can reject it, constrain it, or attach required metadata before execution.

A lifecycle event is a known point such as session start, immediately before a tool call, immediately after a result, or completion of a task. A prompt can ask a model to remember a rule, but a prompt is guidance interpreted by the model rather than a dependable enforcement boundary. Enforcement occurs when trusted system code checks the operation and can actually block or constrain it. A pre-tool hook can reject a disallowed file path, inspect the risk of a requested command, or attach required case metadata before execution. In a hypothetical human-resources workflow, a pre-tool hook could block an agent from sending a draft decision because the case lacks the required reviewer approval.

A post-tool hook can standardise returned fields, record operational measurements, apply a formatter, or flag output that may contain sensitive information. A session-start hook can load approved environmental context, while a completion hook can initiate validation or send an allowed notification. Hooks should be fast, observable, and predictable because slow or hidden behaviour can make an agent failure look mysterious. A hook that silently rewrites evidence may undermine provenance even if its intention is helpful, so transformations need their own records and tests. Hooks do not replace checks inside the backend service, which is the application component that ultimately receives and carries out an operation.

Text description

• Authentication: Establishes who or what is making the request.
• Authorization: Determines whether that identity may perform the requested operation on the particular resource.
• Approval when required: For an approval-gated action, records the proposed action, approving identity, authorization decision, time, and exact approved object.
• Backend enforcement: Independently validates identity and permission where the operation is ultimately received and carried out.

Authentication establishes who or what the caller is, while authorization determines whether that authenticated caller may perform the requested operation on the particular resource. In a hypothetical support system, a valid employee login authenticates the worker, but it does not automatically authorize that worker to approve a large account credit. The backend must validate both identity and permission even when a coordinator, tool wrapper, or hook has already performed a similar check. This layering is defence in depth, meaning several independent safeguards reduce reliance on any single control without promising absolute safety. A confirmation is evidence that someone acknowledged a proposed step, while authorized approval is a decision made by an identity that has permission to approve that exact step.

Clicking a button labelled confirm does not create authority if the person or agent clicking it lacks the required role, scope, or case ownership. A well-designed approval flow records the proposed action, relevant consequences, approving identity, authorization decision, time, and exact object being approved. Delegation means the coordinator remains responsible for the overall task while another worker returns a bounded contribution. A handoff transfers primary responsibility for continuing the work to another agent or person. Because responsibility moves, a handoff needs more state than a narrow delegation, including the case goal, current status, evidence, actions already attempted, uncertainty, permissions, and required next decision. Human escalation is a handoff rather than a vague admission that the artificial intelligence system is unsure.

In a hypothetical payroll investigation, a useful escalation would identify the disputed payment, show the verified ledger entries, explain the unresolved policy conflict, list attempted retrievals, and name the decision reserved for payroll management. The receiving human should also be told which actions have not been authorized, so merely opening the escalation cannot be mistaken for approving them. More agents do not automatically produce a more accurate answer because workers may repeat the same unsupported assumption or rely on the same flawed source. Correlated mistakes are errors shared across workers because their instructions, models, evidence, or assumptions are too similar to provide genuinely independent checks.

Additional workers also consume time and resources, increase the number of permissions to manage, and create more reconciliation work. Independent perspectives are valuable when they examine meaningfully different evidence or reasoning paths and when the system has a defined way to compare their results. Evaluation should therefore examine not only the final prose but also task selection, source coverage, branch failures, conflicts, permissions, and the quality of each handoff. A strong orchestration design keeps coordination central enough to remain observable while allowing specialised workers enough independence to contribute real value. The lasting principle is simple: divide work to improve focus, but never let decomposition hide context, provenance, failure, or authority.