A supervisor diagnoses a failing service and delegates a patch. Should the worker receive the entire investigation? Now the supervisor delegates a review of that patch. Should the reviewer receive the same investigation, including the supervisor’s confident explanation of why the fix is correct?
Those requests look similar in an orchestration diagram. Their information needs are different. A worker can benefit from established context; a reviewer needs enough evidence to assess the work without being required to accept its author’s interpretation.
This article develops a proposed operating design and experiment protocol, informed by primary sources reviewed through September 15, 2026. The examples are illustrative. No fork-versus-isolation performance trial is claimed here.
The implemented development
LangChain’s September 8 announcement introduces two Deep Agents context modes: an isolated child receives its assignment in fresh context, while a forked child inherits the supervisor’s state. The report identifies workers and independent verifiers as different use cases and explains that prefix caching can make inherited history economical. Those are documented mechanics and design arguments, not a benchmark establishing a universal winner. (Bengre and Curme.)
The current subagent documentation and public repository are the implementation entry points. Pin the actual package version before reproducing behavior. Python and TypeScript support and defaults should be checked independently rather than inferred from an example in the other language.
The broader engineering question is independent of one framework: what information should cross a delegation boundary, and what evidence should return?
Separate four things that often travel together
The following decomposition is a proposed design aid, not a ContextOS wire schema.
| Item | Example | How to handle it |
|---|---|---|
| Assignment | Repair duplicate delivery handling | State the required outcome and boundaries |
| Evidence | Failing test, current source, provider contract | Give stable references and relevant snapshots |
| Interpretation | “The timeout handler is definitely wrong” | Label as a hypothesis; omit from a blind first review |
| Authority | Permission to edit a module or invoke a tool | Bind outside the conversation and check at execution |
A message saying “you can deploy this” is not sufficient evidence that the delegator had deployment authority. Similarly, a conversation containing a private document does not automatically justify copying it into every child. Information access and action permission deserve separate checks.
For ContextOS integrations, use the established orchestration foundation and invocation contracts. The design below does not introduce another RunContext, change approval tiers, or claim that this documentation repository implements a production delegation runtime.
Choose context according to the work
The simple fork-or-isolate choice becomes more useful when paired with explicit evidence selection.
| Work | Proposed starting point | Main failure to watch |
|---|---|---|
| Implement a diagnosed local fix | Inherited or selectively packaged investigation | Carrying forward an incorrect diagnosis |
| Review correctness | Fresh context with requirements, diff, and test evidence | Missing a requirement because the packet is incomplete |
| Investigate an independent question | Fresh assignment and source boundaries | Repeating necessary context gathering inefficiently |
| Extract durable decisions | Relevant conversation with provenance | Promoting speculation or untrusted text into memory |
| Execute a sensitive external action | Minimal verified inputs and externally bound authority | Treating copied instructions as authorization |
This table is a starting hypothesis. It should be adjusted using observed failures. “Fresh” does not mean uninformed, and “inherited” does not mean correct.
A reviewer needs the acceptance criteria, relevant design constraints, the artifact under review, and the means to test it. Withholding those inputs creates an artificial disadvantage for isolation. Conversely, passing the author’s entire narrative can turn review into an exercise in confirming an existing explanation. Evaluate both information completeness and interpretation dependence.
A concrete review packet
Consider an illustrative change that retries a request after a timeout. The intended behavior is one logical operation, even if the provider commits the operation before its response is lost. A review packet might look like this:
# Illustrative research fixture; not a ContextOS runtime schema.
assignment: review_retry_change
requirements:
- one_effect_per_logical_operation
- preserve_provider_error_evidence
- unresolved_outcome_must_remain_visible
artifacts:
base_revision: fixture_base
candidate_revision: fixture_candidate
provider_contract: fixtures/provider-contract.md
failure_case: fixtures/commit-then-response-loss.json
review_scope:
- implementation_diff
- regression_tests
- failure_semantics
requested_output:
- findings_with_file_and_test_references
- unresolved_questions
- verification_performedThe packet intentionally describes the required behavior without announcing a preferred verdict. The reviewer can inspect the implementation and discover whether it generates a new operation identity on retry, loses evidence, or treats ambiguity as success.
If the reviewer later needs the author’s explanation, provide it in a second phase and record whether the findings change. This gives the explanation a useful role without allowing it to replace the first assessment.
A separate execution policy should keep the reviewer from changing the candidate or making external writes. That separation lets the review result remain an observation about a fixed artifact. A subsequent fixer can receive the findings with a distinct editing assignment.
Why fresh context is not proof of independence
Two agents may start with different conversations and still share the same model tendencies, incomplete evidence, and misleading tests. Agreement is therefore weaker evidence than independent verification of a requirement. A fresh context window removes one information path; it does not establish statistical independence or correctness.
EvoSafeHarness uses fresh-context adversarial review within its optimization process to challenge candidate defenses. That provides a research motivation for testing the technique, not a guarantee that a fresh reviewer detects every flaw in ordinary software. (Li and colleagues.)
The proposed operational test is simple: plant a plausible but incorrect explanation in one review condition while leaving the code and requirements unchanged. Compare which defects are found and which unsupported conclusions are repeated. Run an additional condition with genuinely useful explanatory context so the experiment also measures the cost of withholding information.
Cache economics need an end-to-end denominator
Inherited history can avoid repeated file reads and can reuse eligible prompt prefixes. It can also copy irrelevant material, require compaction, or add analysis work. The useful unit is total cost for an accepted outcome, including the supervisor and every child.
Use an accounting identity such as:
workflow cost = supervisor usage + all child usage + tool charges
+ environment charges + measured review/recovery costKeep token categories in their provider-native form before normalizing them. Record uncached input, cache reads, cache writes where exposed, and output separately. Preserve missing values. A cost estimate built from incomplete usage is an estimate with incomplete coverage, even when every available row is internally consistent.
Cache hit rate alone cannot establish savings. A system that reads fewer files but creates twice as many children may cost more. A cheaper review that misses a release-blocking defect has not met the same acceptance criterion. Compare both warm-cache and cold-cache conditions and report their frequency in the intended deployment.
An experiment a team could actually run
This is a proposed experiment, not a report of completed results. Start with representative task families that exercise diagnosis reuse, independent review, and unfamiliar evidence. Use a pilot to estimate variance before choosing the final sample size.
Treatment A: full inheritance. The child receives the supervisor’s eligible history and the assignment.
Treatment B: isolated packet. The child receives the assignment and a prepared evidence packet. Include the cost of constructing that packet.
Treatment C: isolated retrieval. The child receives the assignment plus access to the same evidence sources, and gathers what it needs. This measures the cost of rediscovery separately from the value of curated evidence.
For each task, fix the artifact revision, acceptance criteria, tool permissions, model settings, and resource limits. Randomize treatment order and preserve session timestamps so provider changes and cache conditions remain visible. Repeat tasks sufficiently to characterize variability; repeated runs of one task should not be treated as unrelated examples.
| Endpoint | How to measure it | Why it belongs |
|---|---|---|
| Accepted completion | Independent requirement checks | Prevents fluent output from becoming the success label |
| Review sensitivity | Detected seeded defects / applicable seeded defects | Measures whether review finds relevant problems |
| False findings | Unsupported findings, adjudicated against evidence | Captures review noise and human burden |
| Interpretation dependence | Findings changed by misleading narrative | Tests susceptibility to the parent’s explanation |
| Total cost and latency | Supervisor, packet construction, children, tools | Captures overhead as well as cache savings |
| Information exposure | Sensitive fixtures visible outside intended scope | Checks delegation boundaries |
| Human work | Minutes to adjudicate, correct, and accept | Connects the experiment to practical value |
Predeclare the main endpoint and the conditions for recommending a mode. Report per-family results and uncertainty. If one mode saves money for implementation but reduces defect detection in review, publish that interaction rather than averaging it into a single preference.
The release policy that follows
Treat context mode as versioned configuration associated with a role and workload. Retain the packet builder and the criteria for selecting evidence. Re-evaluate after changes to the model, context window, compaction strategy, caching behavior, or permissions.
A proposed safe rollout begins on tasks whose outcomes can be checked without consequential external effects. Compare in shadow, inspect failures, and promote only after the intended acceptance criteria hold. Keep a way to restore the prior delegation configuration.
The durable design principle is to make inheritance intentional. A child should receive enough evidence to do its job, a clear distinction between facts and hypotheses, and only the authority granted through the runtime. The right amount of context is a measured property of the assignment.
Sources and evidence notes
- Thushanth Bengre and Chester Curme, LangChain. Organizing Context in a Multi-Agent Harness. September 8, 2026. First-party feature and architecture report.
- LangChain. Subagents documentation and Deep Agents source. Living materials, reviewed September 15, 2026; no local package execution claimed.
- Nanxi Li and colleagues. EvoSafeHarness. September 5, 2026, preprint v1. Motivation for testing fresh-context review; the proposed experiment here is independent of that study.
The series ledger records evidence boundaries. Review packets, evaluation treatments, metrics, and rollout advice in this article are proposed practitioner methods.