Harness Theory Part 07 | Long-running and Multi-agent Work: How Tasks Survive Context Boundaries

Suppose you give a coding agent a substantial migration: update several modules, add tests, revise the documentation and finish with a reviewable pull request.

The first session goes reasonably well. The agent finds the old schema, changes part of the implementation and runs several tests. As the context fills, it leaves a short summary and stops.

A new session starts. The incoming agent can see that the repository has changed, but it does not know:

which changes were verified
which changes were temporary exploration
which test was already failing before the task began
whether the previous session performed an operation with side effects
what the next safe action is
how much of the original task remains

It may repeat the investigation, continue from a false assumption, or inspect the visible progress and declare the task complete.

This is not merely a context-window problem. The system is missing a harness that can carry task state across sessions, workers and agents.

Long-running work cannot depend on one conversation surviving forever. It needs durable artefacts, structured progress, clean hand-offs, explicit ownership and a repeatable way to rebuild the working context.

Long-running task across fresh sessions

Figure 7-1 | Each session may use fresh context; the task contract, progress ledger, evidence and artefacts must live outside the session.

A long-running task is not one session kept alive for longer

Part 04 treated context as a finite resource. Part 06 explained how a runtime owns canonical state and checkpoints.

Long-running work adds a further question:

When work spans several context windows, sessions or agents, what must survive and what should be discarded?

The obvious approaches are to:

use a larger context window
compact repeatedly
pass the full transcript into the next session
keep the agent in a loop until it says the work is complete

These techniques can postpone the failure. They do not provide a dependable hand-off protocol.

In Anthropic’s long-running harness experiment, agents commonly tried to implement too much in one session and left half-finished work when the context ended. Later sessions could also inspect substantial existing progress and conclude that the project was finished too early. Their harness used an initialiser to establish the environment, then asked subsequent coding sessions to make incremental progress and leave progress artefacts and Git history behind.¹

A later harness experiment made the distinction sharper. A fresh context reset can remove accumulated distraction, but only if the hand-off artefact carries enough state for the incoming agent to reconstruct the work.²

A context window is a workbench for one stretch of reasoning. It is not the task database.

This does not mean that every long task should reset its session frequently. OpenAI reported an approximately 25-hour Codex run in 2026, showing that stronger models and harnesses can extend coherent continuous work. It was an experiment, not evidence that durable state is unnecessary. Continuous runs, compaction, and fresh sessions can all be valid policies; task truth must not disappear with one context, process, or worker.³

Seven ways long-running work fails

1. Context rot

Current constraints are gradually buried beneath stale information, long tool results and intermediate discussion. The words remain available, but the model no longer gives the right facts enough weight.

2. Goal drift

The agent solves problems it discovers along the way and slowly leaves the original task contract. More activity does not necessarily mean more progress.

3. One-shot overreach

The agent changes too much at once and reaches the end of the context with several modules in an unfinished state. The next session has to infer intent from a dirty workspace.

4. Repeated exploration

Every session reads the same documents, searches the same modules and repeats the same diagnostics. Tokens and time are spent reconstructing decisions that should have been recorded.

5. Hidden state in the transcript

A material decision exists only in a conversation turn. It never becomes part of the specification, ledger, decision record, code or tests. Compaction or transcript loss removes the only copy.

6. Premature completion

The agent sees that most of the feature exists and treats a natural-language judgement as completion. Remaining work, untested paths and exceptions are not checked against an inventory.

7. Concurrent ownership conflict

Two agents claim the same task or change the same resources in one workspace. The result is two outputs that both report success and cannot be integrated safely.

These failures need different controls. Putting all of them into a longer prompt is roughly equivalent to placing project management, version control, queues, locks, tests and incident records in one memo and asking the model to chair the meeting.

Durable and disposable state

The first design decision is to separate information that must survive the session from information that may be regenerated.

Durable state

The next session must be able to trust, query or verify:

the task contract and scope
the specification, plan and work inventory
the progress ledger
confirmed decisions and assumptions
the checkpoint pointer
artefact references
test, build, lint and review evidence
external operation IDs
Git commits and workspace metadata
known failures, blockers and open risks
the next safe action

Disposable context

The following is usually useful only during the current reasoning pass:

temporary reasoning paths
large, unfiltered search results
verbose tool output
candidate approaches superseded by a recorded decision
repeated repository exploration detail
conversational padding that does not affect later work

Durable does not mean permanent. It means that while the task remains active, the information cannot depend on a model vaguely remembering it.

A useful test is:

If a new session cannot retrieve this information, could it repeat work, cross a boundary, misjudge completion or duplicate a side effect?

If so, promote it to an artefact or state outside the session.

Fresh-context iteration is a policy, not the only answer

A fresh-context loop does not keep one agent alive indefinitely. It turns a long task into bounded, restartable iterations:

Load durable task state
→ validate hand-off commit
→ select one bounded work unit
→ execute
→ verify
→ prepare immutable evidence
→ commit progress and next action
→ end or continue

Each iteration reconstructs context, completes a verifiable increment, and then chooses whether to continue the same session, compact, or begin a fresh session at a safe boundary.

Benefits include lower context accumulation, repeated contract checks, durable progress, replaceable workers, and the option of a fresh reviewer. Costs include bootstrap tokens, latency, missing evidence during reconstruction, and coordination overhead.

Condition	Continue the run	Fresh session
Context remains high-signal	Usually	Optional
Durable checkpoint reached	Either	Suitable
External side effect has an unknown outcome	No; reconcile first	No; reconcile first
The next phase needs a different role or reviewer	Possible	Often useful
Hand-off reconstruction is expensive	Prefer continuation	Use carefully
Context rot or premature wrap-up is visible	Weaker choice	Stronger choice

A fresh session should be selected by runtime policy, not merely because the model feels that tokens are running low. Before reset:

stop accepting a new work unit
bring active operations to a knowable state
persist irreproducible evidence
commit a hand-off manifest and new state version
validate that another session can reconstruct the work

The pattern suits work that divides into clear increments with dependable verification and durable state. It may reduce quality for tightly coupled judgement, tasks without observable completion, work requiring a large irreducible context every time, or systems whose hand-off authority is unreliable.

Session bootstrap: reconstruct the working world first

A new session should not begin by asking the model, “What should I do next?” The runtime should execute a repeatable, verifiable bootstrap protocol.

A typical sequence is:

validate the task ID, tenant, repository, branch and workspace
load the task contract, specification, progress ledger and last checkpoint
compare the recorded state with the repository, artefact store and external systems
run the minimum health check required by the current checkpoint
identify one available, bounded work unit
establish the session budget, tool scope and verification requirement
begin execution

The exact steps can differ, but bootstrap must answer:

Which working environment am I in?
What is the actual task state?
Which evidence from the previous session is trustworthy?
Which failures are baseline and which are new?
What is the smallest safe next action?

If bootstrap reads only a prose summary and does not inspect the repository, task store and artefacts, the incoming agent can still begin from a stale description.

A structured progress ledger is an operational view, not necessarily the claim authority

The progress ledger is the operational view of a long task, not a diary or a transcript under another filename.

task_id: migration-payment-state-v2
schema_version: 4
contract_version: 5
task_version: 18
status: in_progress
workspace_id: ws-payment-state-17
completed:
  - id: update-domain-enum
    evidence_manifest: evidence://update-domain-enum/v3
current:
  id: migrate-api-mapping
  claim:
    owner_id: worker-07
    claim_generation: 12
    claim_token: claim-12-a9f3
    lease_expires_at: 2026-07-08T06:00:00Z
remaining:
  - update-webhook-consumer
  - add-backward-compatibility-tests
known_failures:
  - id: baseline-flaky-checkout-e2e
    classification: pre_existing
last_checkpoint: cp-031
last_handoff: handoff-044
next_safe_action: run_api_mapping_contract_tests
updated_at: 2026-07-08T05:40:00Z

It does not prove that the owner still holds a valid claim, evidence passed, ledger and repository updated together, or an external side effect completed.

Ledger view and authoritative task state

A small system may use Markdown or YAML with atomic rename or compare-and-swap as both ledger and task authority. At larger scale, a common arrangement is:

Authoritative task / claim store
→ produces a versioned progress view
→ context builder loads selected ledger sections

The ledger is then the readable hand-off projection, while the task store atomically checks claim token, task version, and completion transitions.

Whichever storage arrangement is chosen, it needs schema, task, contract, and task versions; separate completed, current, and remaining sets; immutable evidence references; classified blockers; checkpoint, hand-off, and next action; and expected-version or equivalent concurrency control.

A progress.md file is usable. Once it participates in automated claiming, completion, or hand-off, it is a state model. Markdown is not an exemption from concurrency, versioning, or validation.

Ledger, checkpoint and Git history are not interchangeable

They often work together, but each proves something different.

Mechanism	Primary purpose	What it cannot prove alone
Progress ledger	Current task position, owner and next action	The files or external state match the description
Checkpoint	A consistent runtime position from which execution may resume	Code history, business completion or every side effect
Git history	File changes and commit boundaries	Runtime approvals, external operations or uncommitted artefacts
Test evidence	A condition passed in one execution	The whole task is complete or every environment is correct

A mature hand-off cross-references them rather than appointing one as a universal source of truth.

For example, a ledger may record commit: a81c2f9, checkpoint: cp-031 and test_run: tr-442. Bootstrap then verifies that the references exist, belong to the same task and remain valid.

A clean hand-off is a committable state transition

A reliable hand-off does not modify the repository, then the ledger, and merely hope that both agree.

Stop accepting a new work unit
→ reach a safe operation boundary
→ persist immutable artefacts and evidence
→ build hand-off manifest
→ validate references and consistency predicate
→ atomically commit task state + manifest pointer
→ release claim or transfer ownership
→ publish session terminal event

handoff_id: handoff-044
task_id: migration-payment-state-v2
from_session: session-19
from_task_version: 18
to_task_version: 19
workspace_ref: workspace://ws-payment-state-17@a81c2f9
checkpoint_ref: checkpoint://cp-031
evidence:
  - evidence://api-mapping-tests/tr-442
  - artifact://diff/api-mapping-v4
current_unit:
  id: migrate-api-mapping
  state: resumable
next_safe_action: run_api_mapping_contract_tests
consistency_predicate: checkpoint-api-mapping-v2

Persisting immutable evidence before committing a versioned hand-off record reduces the risk of a ledger advancing while its artefact never arrived. Where stores cannot share a transaction, use idempotent commit, expected task version, prepared and committed states, orphan-artefact reconciliation, and activate the hand-off pointer only after validation.

Structured progress ledger and clean handoff

Figure 7-2 | Authoritative task state, a versioned ledger, and a committed hand-off manifest ensure that the next session starts from validated evidence and state.

Before hand-off, separate completed, incomplete, blocked, and known-failing work; persist evidence; record external operation identifiers and unknown outcomes; give background work explicit state; handle temporary material and secrets; keep bootstrap usable; specify the next safe action; and prevent stale workers from committing after claim release.

Clean does not mean that the whole repository is always green

Large migrations may require intermediate states. Use a checkpoint-specific consistency predicate defining the modules that must pass, baseline failures, required artefacts, workspaces that must not merge, and prerequisites for the next iteration.

If the state cannot be resumed safely, commit an explicit dirty or blocked hand-off. An honest amber state is more useful than a red state painted green.

The fresh-session test

A direct hand-off test is:

Start an agent with no old transcript. Give it only the task contract, ledger, required artefacts and workspace. Can it explain the current state and choose the next safe action?

A failure usually means that:

a material decision exists only in chat
the ledger lacks evidence
the workspace contains unexplained dirty files
the scope changed without a new contract version
the next action depends on one person’s or agent’s private memory

The test does not prove final correctness. It proves only that the hand-off artefacts are sufficient to reconstruct the operational state. “Can continue” and “is correct” are different claims.

A subagent is a child runtime, not a shorter prompt

Delegation creates a child work unit with its own lifecycle:

Subagent
= child run
+ versioned delegation contract
+ selected context projection
+ scoped resource grant
+ ownership boundary
+ evidence and acceptance contract

At least six questions need answers.

1. Objective and input snapshot

What must the child accomplish, and against which parent state, contract, repository reference, and artefact versions?

2. Resources

Which tools, filesystem paths, network routes, credentials, model, and budget may the child use?

3. Context projection

Which instructions, facts, artefacts, parent state, and task constraints are visible, and which are intentionally omitted?

4. Ownership and authority ceiling

Which files, records, tasks, or external resources may it modify? May it delegate again, request approval, or widen scope?

5. Cancellation and lifecycle

How do parent cancellation, deadline, budget exhaustion, or policy change propagate? How are completed, partial, failed, cancelled, and unknown retained?

6. Evidence and acceptance

Which artefacts, tests, sources, assumptions, coverage gaps, and traces must return before the parent can verify and accept the result?

{
  "child_run_id": "child-204",
  "parent_run_id": "run-108",
  "delegation_id": "delegation-77",
  "contract_version": 3,
  "parent_state_version": 41,
  "task_id": "audit-webhook-mapping",
  "objective": "Find callers that depend on the legacy payment-state mapping.",
  "input_snapshot": {
    "repo_ref": "payments@a81c2f9",
    "spec_ref": "artifact://spec/payment-state-v2"
  },
  "resources": {
    "tools": ["read_file", "search_code", "run_readonly_tests"],
    "network": "deny",
    "write_scope": [],
    "delegation": "deny"
  },
  "budget": {
    "max_turns": 12,
    "max_cost_usd": 0.8
  },
  "required_evidence": [
    "caller inventory",
    "file and symbol references",
    "coverage gaps",
    "child trace ID"
  ],
  "result_protocol": {
    "submitted_states": ["completed", "partial", "failed", "cancelled", "unknown"],
    "parent_decisions": ["accepted", "rejected", "repair_required"]
  }
}

It illustrates explicit constraints on context, resources, authority, budget, and acceptance. It does not prove that restrictions are enforced, the search is complete, or the result deserves acceptance.

Anthropic’s Claude Code documentation describes subagents with independent context, selected tool access, and independent permissions. Current OpenAI Codex documentation says that children receive the parent turn’s live sandbox and approval overrides. These are product semantics, not one universal inheritance rule. A custom harness must define its resource grant and authority ceiling explicitly.⁴⁵

Parent and child runtime contract

Figure 7-3 | A parent creates a child runtime through a versioned delegation contract. The child submits evidence; the parent then accepts, rejects, or requests repair.

Shared resources are not shared context

Parent and child may share:

a repository
an artefact store
a sandbox image
tool services
a task registry

That does not tell the child what the parent inspected, rejected or assumed.

The child should not return its entire transcript either. A more useful result contains:

artefact references
commands or tests executed
source citations
modified resources
assumptions
unresolved gaps
confidence and coverage
a child run or trace ID

Anthropic’s multi-agent research system uses an orchestrator-worker pattern. A lead agent assigns different research directions to parallel subagents, then synthesises their findings. Detailed search context remains within workers rather than flooding the lead agent’s context.⁶⁷

The point is not to hide detail from the parent. It is to make detail retrievable through artefacts and provenance rather than copying every token into one conversation.

A child summary does not become more trustworthy merely because it came from “our agent”. Anthropic notes that subagents can isolate untrusted content, but treating transformed output as trusted may create trust escalation. Child output should retain source, data-versus-instruction role, and trust or taint metadata for parent policy and verification.⁸

Multi-agent work needs a protocol, not a shared chat room

Free-form text is insufficient for assignment, approval, results, cancellation, and shutdown.

message_id: msg-883
protocol: task_result
protocol_version: 2
request_id: req-117
from: worker-api-02
to:
  - coordinator
task_id: migrate-api-mapping
claim_generation: 12
type: response
status: result_submitted
payload_ref: artifact://results/api-mapping-02
sequence: 6
dedupe_key: task-result:migrate-api-mapping:12
created_at: 2026-07-08T06:20:00Z
expires_at: null

It does not establish processing, parent acceptance, duplicate removal, current ownership, or artefact retention.

Do not assume exactly-once delivery

Queues, networks, and restarts can produce duplicate and late messages. A safer assumption is:

at-least-once delivery
+ idempotent handler
+ dedupe key
+ monotonic task state

created
→ delivered
→ acknowledged
→ processing
→ result_submitted
→ accepted / rejected / repair_required

Acknowledged means responsibility was received. Result submitted means a candidate was delivered. Accepted means the coordinator adopted it against contract and evidence.

Requests and responses need correlation

Approval, permission, plan-review, and shutdown requests need a request_id; responses use the same identifier and reach approved, rejected, expired, or cancelled. The actual write or tool path still checks protocol state, operation digest, and state version.

Idle is not completed

A worker may wait for a tool, approval, external process, result persistence, or parent acceptance. The coordinator needs work-unit state, heartbeat, pending operations, claim generation, and result protocol rather than a timer measuring the last token.

Delivered is not processed

Broker delivery does not prove that the receiver validated the schema, accepted the task, acquired a claim, read the artefact, completed the request, or submitted evidence.

Background acceptance, worker completion, and parent acceptance are three events

Task request
→ authorised
→ background accepted with work_id
→ worker runs
→ worker result submitted
→ parent verifies
→ accepted / rejected / repair required

Background acceptance includes work identifier, initial state, inspection endpoint, cancellation capability, and whether side effects may have begun. Worker completion includes terminal state, artefact reference, timestamps, and claim generation. Parent acceptance contains the accepted result version, verification evidence, gaps, and authoritative task transition.

Do not reuse one tool request identifier for an initial accepted result and a second result later. The original request terminates with background_accepted; later events use the work identifier.

Atomic task claiming needs a claim generation as well as a lease

This contains a race:

read task where status = pending
if task has no owner:
    write owner = me

Claiming is one atomic transition:

pending, task_version=18
→ compare-and-set
→ claimed(
     owner=worker-A,
     claim_generation=12,
     claim_token=claim-12-a9f3,
     lease_until=...
   )
→ running
→ result_submitted
→ accepted / partial / failed / released

The predicate checks task state, dependencies, owner and lease, worker capability, workspace scope, and task version.

Result submission also verifies task identifier, expected task version, claim generation and token, workspace or result version, submitter ownership, and cancellation or supersession state.

A lease only measures owner renewal. A stale worker may awaken after a network partition and still submit. The task store or integration gate needs a monotonically increasing claim generation or fencing token to reject stale results.

Atomic task claiming, lease and reassignment

Figure 7-4 | Claiming is atomic. A lease supports reassignment; claim generation prevents an expired worker from committing a stale result.

A lease is renewable operational state, not a side-effect guarantee

A lease includes a lease identifier, owner, claim generation and token, times, heartbeat, release, and reclaim policy. Renewal should use an expected version so that a stale worker cannot extend a claim already reassigned.

Lease expiry does not make an operation safe to repeat. If the worker may have caused an external side effect, the coordinator first checks the operation identifier and external authority. Part 08 covers unknown outcomes, idempotency, and reconciliation.

A task can be reclaimed without making earlier side effects safe to repeat, and a worker can continue running without retaining authority to submit.

Build a task portfolio before adding agents

Multi-agent work introduces coordination, context, budget, merge and verification costs. Delegation should consider:

outcome clarity
verification quality
reversibility
blast radius
context availability
dependency stability
judgement density
expected review cost
parallelisability
human learning value

High-confidence delegation

Good candidates for background or parallel execution include:

mechanical refactors with tests
bugs with stable reproductions
bounded migrations
documentation updates from canonical sources
issue triage with no external response
research with a fixed report schema

Exploration

These tasks may be delegated, but the outputs are options and evidence rather than shippable results:

library surveys
architecture alternatives
prototype directions
reproduction experiments

Human-primary work

Human leadership remains appropriate when:

product intent is unclear
the decision is irreversible or high risk
no dependable evaluator exists for the required judgement
the work has serious security, legal or financial consequences
human skill development is itself part of the task

Adding agents does not clarify an ambiguous requirement. It only lets the ambiguity produce branches more quickly.

Capability-tiered coordination

Some workloads contain a small amount of high-judgement planning and a large volume of search, classification, transformation or reading.

A coordinator can:

decompose the problem
define coverage
check conflicts
synthesise the conclusion

Constrained workers can:

search assigned areas
execute repeated queries
produce structured findings
preserve provenance and coverage gaps

This works when:

subtasks can be separated clearly
worker output can be verified
raw data need not enter the coordinator’s context
the coordinator can detect omissions and conflicts
coordination costs less than it saves

Do not assume that a cheaper model is automatically suitable for execution. If worker errors are difficult to detect, the apparent saving moves into review and incident handling.

Workspace isolation contains the write surface, not merely the directory

Parallel coding agents cannot rely on a prompt asking them not to edit the same file.

A work unit may need an isolated:

Git branch or worktree
container or filesystem snapshot
database schema or test tenant
queue or topic namespace
object-store prefix
temporary credential scope
port, service instance, or external sandbox

Current Claude Code documentation supports worktree isolation for parallel sessions and subagents, while OpenAI Codex supports parallel subagent workflows. These capabilities demonstrate the value of isolation, but a worktree isolates a checkout, not a database, cloud resource, credential, or external side effect.⁹⁵

Anthropic’s parallel C compiler experiment used containers with separate repository clones before pushing into a shared upstream. It also demonstrates the other half of the problem: parallel execution still needs work partitioning, synchronisation, and tests, or it amplifies conflict.¹⁰

A workspace lifecycle should be explicit:

Validate name and resource scope
→ create isolated workspace
→ bind task, claim generation, and owner
→ pin base revision and environment
→ execute
→ verify local result
→ submit integration candidate
→ rebase / merge in controlled order
→ run integration verification
→ accept / repair / discard
→ cleanup after retention checks

Workspace isolation and integration lifecycle

Figure 7-5 | A workspace isolates local writes. The integration gate revalidates the exact source head, dependency order, external resources, and current evidence.

Workspace metadata

Retain at least:

workspace identifier
repository and base reference
original commit
branch or snapshot identifier
task, owner, and claim generation
resource namespace
configuration and tool-catalogue version
creation time
current state
dirty files
local verification evidence
integration-candidate head
cleanup and retention decision

Isolation does not remove semantic conflict

Two agents may avoid the same file while still:

making incompatible assumptions about one API
producing conflicting migration orders
modifying different locations that share one schema
adding semantically duplicate abstractions
passing local tests and failing after integration
polluting one shared test tenant or external sandbox

The integration gate checks:

that the candidate head still matches the verified source head
current claim and task version
ownership and write-set conflicts
rebase or merge strategy
schema and migration ordering
cleanup of shared external resources
integration, contract, and end-to-end tests
final verifier and acceptance record

A merge creates a new combined state, so local evidence is not automatically integration evidence. If the base branch advances while the worker runs, affected tests may need to run again after rebase.

Isolation prevents immediate overwrites. It does not create a shared world model, dependency order, or acceptable integrated result.

Partial completion is a first-class result

Long-running work often stops with:

some subtasks complete
implementation complete but verification incomplete
a blocker requiring human judgement
an exhausted worker budget
an unavailable external dependency
a cancellation that leaves useful artefacts

Child, worker and session reports should therefore distinguish:

completed
partial
blocked
failed
cancelled
unknown

Also distinguish worker outcome from task acceptance. A worker may report completed, but before parent or integration verification the task is at most result_submitted. Authoritative task state reaches completed only after the acceptance contract passes. partial is not a polite spelling of success. It should include:

completed scope
incomplete scope
available evidence
claims not yet verified
side effects and operation IDs
workspace and artefact locations
the proposed next safe action

The coordinator can then decide whether to accept the contribution, reassign the remaining work or escalate it to a human.

Graceful shutdown

Killing a worker directly can leave:

a partial file write
an active tool process
a held lease
an unflushed artefact
a pending message
an unknown external side effect

A graceful shutdown normally:

requests a stop
prevents the worker from accepting new tasks
checkpoints or cancels active work at a safe point
releases leases and resources
persists partial results and final evidence
acknowledges termination
cleans up the workspace and process

Not every operation can be interrupted safely. Some tool calls must reach a knowable state before the recovery and reconciliation controls in Part 08 take over.

Walking through a cross-module migration

Consider this task:

Migrate payment status from the legacy enum to the new schema across the API, webhook consumer, dashboard and tests, without executing the production migration.

1. The initialiser establishes the task

The harness creates:

a task contract
a feature or work-unit inventory
a progress ledger
a base workspace
a baseline test report
a verification plan

2. The first session selects a bounded unit

The agent claims update-domain-enum and changes the domain model and unit tests in an isolated workspace.

3. Verification and hand-off

After the tests pass, the runtime stores the commit, test run and diff artefact, then atomically updates the ledger. The next safe action becomes migrate-api-mapping.

4. A fresh session bootstraps

The incoming agent does not receive the old transcript. It validates the state using the contract, ledger, checkpoint and repository, and confirms that baseline failures have not changed.

5. The parent delegates read-only research

A child agent is asked to identify every caller of the legacy mapping. It can search and run read-only tests, then returns a caller inventory, file references and coverage gaps.

6. Workers proceed in parallel

API and dashboard tasks receive atomic claims and separate worktrees. The webhook task remains blocked because it depends on the API contract.

7. A lease expires

The dashboard worker crashes. The task is reclaimed with a new claim generation after lease expiry. The harness retains the partial branch and artefacts; if the old worker awakens later, its stale claim token cannot submit.

8. Integration

The coordinator gathers child evidence, merges the API and dashboard branches, and runs contract tests, integration tests and migration-order checks.

9. The task stops partially complete

The webhook change requires confirmation from another team. The harness reports partial, including completed scope, blocker and next safe action. It does not declare the whole migration complete.

The model performs the reasoning and implementation. External task state, ownership, evidence and workspace lifecycle keep the work from becoming an archaeological dig every time the context changes.

Twelve questions for reviewing a long-running and multi-agent harness

Does task truth exist outside the session and full transcript?
How does runtime policy choose between a continuous run, compaction, and a fresh session?
Before reset, has the run reached a safe boundary and committed a verifiable hand-off?
Is the progress ledger authoritative state or a versioned projection of a task store?
How does the hand-off manifest avoid a dual-write gap across ledger, workspace, checkpoint, and artefact?
Does the child contract pin input snapshot, resource grant, authority ceiling, cancellation, and acceptance?
Does child output retain provenance and trust role instead of becoming trusted instruction automatically?
How does messaging handle duplicate, late, acknowledged, submitted, and accepted states?
Is claiming atomic, with task version and claim generation or fencing rejecting stale results?
Does delegation account for parallelisability, verification cost, blast radius, and human learning value?
Does workspace isolation cover files, environment, and external resources, and does integration verify the exact source head?
Do partial, blocked, cancelled, and shutdown states retain recoverable evidence, claims, and next safe action?

If the answers are still “the agent will remember”, “they all see the same chat”, “retry after lease expiry”, or “the worktree isolates everything”, the system has parallelised amnesia, races, and conflict.

From theory to implementation: Part 07 checklist

Part 08 addresses the next problem: when a worker, tool, network, or external system fails, how should the harness choose among retry, fallback, replanning, reconciliation, compensation, and stopping without duplicating side effects?

References

Anthropic, Effective harnesses for long-running agents, 26 November 2025. ↩
Anthropic, Harness design for long-running application development, 24 March 2026. ↩
OpenAI, Run long horizon tasks with Codex, 23 February 2026. The cited run is an experiment, not a general production guarantee. ↩
Anthropic, Create custom subagents, accessed 8 July 2026. ↩
OpenAI, Subagents, accessed 8 July 2026. ↩ ↩²
Anthropic, How we built our multi-agent research system, 13 June 2025. ↩
Anthropic, Effective context engineering for AI agents, 29 September 2025. ↩
Anthropic, How we contain Claude across products, 25 May 2026. ↩
Anthropic, Run parallel sessions with worktrees, accessed 8 July 2026. ↩
Anthropic, Building a C compiler with a team of parallel Claudes, 5 February 2026. ↩