Subagent Isolation: Why the Orchestrator Is Half-Blind

An orchestrator asks a research worker to inspect a market and return the important findings. The worker replies with one polished paragraph.

What can the orchestrator verify?

From that paragraph alone, it cannot know which sources were searched, which pages failed to load, what evidence was omitted, whether contradictory material was found, or which assumptions shaped the summary. Delegation produced an answer, but it also placed work behind a boundary.

A caller sees what the delegation contract returns, not everything the delegated runtime saw or did.

01 / Caller

Orchestrator context

• Task objective
• Selected state
• Delegation policy

Bounded input->

02 / Delegated runtime

Subagent context

• Local instructions
• Permitted tools
• Tool results and local state

->Result + explicit telemetry

03 / Caller

Verify or escalate

• Check evidence
• Inspect artifacts
• Accept, retry, or stop

Visible by contract: result, status, evidence, artifacts, errors, and trace events the runtime exposes.

Not automatic: the worker's full context, every attempted step, or raw hidden reasoning.

Delegation assembles another context

Every model call processes the context represented to that call. When an orchestrator invokes a worker, the surrounding system decides what crosses into the delegated runtime:

• the task and expected output;
• selected history or application state;
• worker-specific instructions;
• available tools and credentials;
• retrieved documents or file contents;
• limits, approval rules, and stopping conditions.

The worker may then accumulate local tool results, retries, intermediate artifacts, and model outputs. Those items do not automatically appear in the orchestrator’s next context.

Some frameworks start workers with fresh context. Others pass filtered history, a state object, references to shared storage, or a resumable session. The implementation varies. The stable principle is that context crosses an explicit application boundary. Agent labels do not create shared awareness.

This is why “half-blind” is useful shorthand. The orchestrator may know what it requested and what came back while lacking important evidence about execution inside the boundary.

Shared state is not shared context

Several mechanisms are often described loosely as “what the agents know.”

Mechanism	What it means	What it does not guarantee
Conversation history	Prior messages retained by an application or provider	That every worker receives the same history
Shared state	Data in a store or state object that multiple participants may access	That it is injected into every model call or remains conflict-free
Current context	The represented input available to one inference	That it persists after the call
Worker-local state	Tool results and artifacts available inside one delegated run	That the caller can inspect them
Return result	Data sent through the worker’s output channel	That it captures all relevant work or is correct

A system with a shared database must still decide who can read each record, who can write it, how versions are identified, and what happens when two workers update the same item. A model cannot use a state value merely because the value exists somewhere. The runtime must read it and represent the relevant part in the call.

Likewise, copying the same conversation into every worker is not always desirable. It consumes context, can expose unrelated data, and may blur each responsibility. Isolation can be a benefit when it limits scope deliberately.

The return channel is an engineering interface

“Done” may be an acceptable result for a harmless notification. It is a poor result for delegated code repair, contract review, or financial analysis.

A useful delegation contract may define:

• the task identifier and completion status;
• the requested findings or artifact;
• evidence such as URLs, quoted clauses, test output, or changed files;
• inputs that were unavailable;
• tool errors and retries;
• assumptions and unresolved conflicts;
• validation already performed;
• a recommended next action or escalation state.

The right fields follow from what the caller must decide. A research worker may need citations and coverage notes. A coding worker may need a patch, diagnostics, and tests run. An execution worker may need an operation identifier and a durable side-effect status.

Structured output makes these fields easier to consume and reject when missing. It does not make their values true. A valid object can contain a fabricated URL, an incomplete test result, or an incorrect status. Schema validation checks the interface shape; downstream verification checks the claim.

Observable events are not hidden reasoning

The runtime can record operational facts without claiming access to a model’s private cognition.

Useful trace events may include:

• the route and worker selected;
• the input version or context references supplied;
• model calls and their visible inputs and outputs, subject to privacy policy;
• tool requests, authorization decisions, results, and errors;
• state reads and writes;
• latency, token use, and cost;
• retries, checkpoints, validation results, and terminal status.

These records answer questions such as “Which document did retrieval return?” and “Did the test command fail?” They do not prove why a model selected a token or expose a complete faithful chain of thought.

Observability should also respect security and privacy boundaries. Logging every prompt and tool result can leak credentials, personal data, or sensitive documents. A production trace policy must decide what to record, redact, retain, and permit operators to inspect.

The caller cannot validate what the contract hides

Suppose an orchestrator asks a coding worker to fix a failing test. The worker returns:

{
  "status": "done",
  "summary": "Fixed the date parsing bug."
}

The response is valid JSON. The orchestrator still cannot tell:

• which files changed;
• whether the target test passed;
• whether unrelated tests failed;
• whether the worker edited generated files;
• whether the apparent fix merely changed the assertion;
• whether an error was hidden behind the status.

A stronger contract could return changed-file paths, a patch or commit reference, command exit codes, focused test output, remaining diagnostics, and explicit limitations. The orchestrator can then apply policy: inspect the diff, rerun tests in a trusted environment, request human review, or reject the result.

The reliability improvement is not “ask the worker to explain its thoughts.” It is “require the artifacts and observable events needed to check the work.”

Review is not independent verification

A second agent can review the first result, but another model call is not automatically independent evidence. The reviewer may share the same model, retrieved sources, prompt assumptions, context omission, or systematic bias.

Stronger verification depends on the claim:

Delegated claim	More independent check
“The code builds”	Run the build in a controlled environment
“This clause requires approval”	Inspect the cited authoritative clause and policy version
“The response matches the interface”	Validate against the expected schema
“The order was created once”	Check a durable operation identifier in the system of record
“All required sources were reviewed”	Compare returned coverage against a known source set

A reviewer can still be useful for ambiguity, consistency, and likely omissions. It should not be promoted into proof merely because it is called a validator agent.

Failures cross the boundary too

Delegation can hide the first error in a convincing chain:

retrieval worker misses the current policy
-> summary worker treats an old passage as complete
-> manager writes a confident answer
-> final review checks style, not policy coverage

Each later step can be locally coherent. The earliest missing evidence remains decisive.

Production workflows can place validation boundaries where errors would otherwise propagate. Depending on risk, that might mean source requirements, typed failure states, checkpoints, deterministic tests, approval gates, or stopping rather than producing a best-effort result.

Retries also belong to the contract. Retrying a transient read can be reasonable. Retrying a side-effecting action such as sending an email, placing an order, or changing infrastructure can duplicate the effect unless the tool and operation boundary support safe deduplication or idempotency. A worker should not collapse “unknown outcome” into “failed, try again.”

Design the boundary before delegating

Before introducing a worker, ask:

1. What exact context will it receive, and what will remain outside?
2. Which state can it read or write, and how are conflicts handled?
3. Which tools and permissions does it need?
4. What result, evidence, artifacts, errors, and status must return?
5. Which trace events are required for debugging and audit?
6. Which checks must run outside the worker?
7. When should the caller retry, escalate, ask a human, or stop?
8. What sensitive data must not enter logs or another worker’s context?

Isolation is not inherently a defect. It can narrow context, permissions, and responsibility. It becomes dangerous when the caller treats a polished bounded result as though it had observed and verified the complete run.