Scale with work graphs, then control entropy: Practical Field Guide

On this page

01Working definition
02Field situation
03Worked example
04Build it, with checkpoints
05Operating context
06Hands-on lab
07Failure clinic
08Production boundary
09Sources and claim limits

Learning objectives

Represent eligible work as a dependency graph with inputs, outputs, ownership, conflict zones, and verification gates
Compare sequential and parallel execution using wall time, total cost, overlap, integration failure, and reviewer burden
Design merge and handoff contracts that preserve evidence and prevent two workers from owning the same mutable surface
Establish entropy checks for stale instructions, broken links, generated facts, expired exceptions, dead fixtures, and rule drift

Before you start

• Modules 00 through 08 with passing evaluator, isolated worktrees, durable ledger, correlated events, and recovery controls
• Two independent Release Desk holdout tasks and one deliberately overlapping task for the collision fixture

Working definition

Graphs, parallelism, entropy

A work graph is a versioned set of tasks connected by explicit dependencies, evidence inputs, owned outputs, conflict zones, budgets, and verification gates. Parallel execution is allowed only for eligible nodes whose mutable and runtime resources are isolated. Entropy control continuously checks that repository knowledge, generated maps, fixtures, rules, exceptions, and links still describe the code agents actually change.

Parallel sessions can reduce elapsed time when tasks are independent and environments are isolated. They can also multiply token and tool cost, duplicate research, race on shared fixtures, produce incompatible abstractions, and move the burden into integration. Worker count is therefore an evaluated operating choice, not a maturity badge.

Harnesses decay as the repository changes. Instructions point to renamed packages, architecture maps lose generated facts, exceptions outlive migrations, checks stop covering new routes, and progress ledgers reference missing evidence. A stale harness can guide an agent confidently toward the wrong boundary. Entropy work keeps the system of record credible enough to automate against.

Field situation

Two fast workers, one broken integration

The task graph, branches, timing, costs, merge conflicts, and harness-health findings are synthetic Release Desk fixtures.

Owner: A platform lead evaluating whether Release Desk can safely run two coding tasks concurrently.
Decision: Should these tasks run concurrently, and what graph or ownership change would make a later parallel trial defensible?
Starting state: One task adds request-change reasons and another adds an audit export. Both appear independent, but each edits the shared transition schema and seed fixture. Separate branches pass their focused tests; the combined branch fails migration ordering and loses one enum value.
Expected outcome: The overlap is detected before dispatch, shared-schema work becomes an upstream node, independent UI and export nodes run afterward, and the team compares the complete integrated receipts.

Constraints

• Every worker uses its own worktree, environment identity, ports, data, logs, caches, screenshots, and process ownership
• A node cannot start until dependencies and conflict-zone checks pass
• Sequential and two-worker trials use equivalent contracts, evaluator gates, and final integrated output
• Parallel execution is rejected if critical failures rise or coordination cost exceeds the declared fixture threshold

Worked example

The graph removed a false dependency claim

Evidence status: Named synthetic scenario

Initial planning assigned two workers by feature name. The path declarations revealed both needed transition-schema.ts, migration metadata, and the same seed record. In the unguarded trial, elapsed implementation was shorter, but integration required manual conflict repair and one acceptance case disappeared.

The revised graph created a schema-contract node owned by one worker and blocked both feature nodes until its receipt passed. The remaining nodes owned disjoint UI and export packages plus separate fixture namespaces. A final integration node regenerated maps, ran combined migrations, checked receipts, and executed the complete suite.

The second parallel trial produced no overlapping writes or lost tests. Its wall time improved inside the synthetic fixture, while total compute and coordination remained higher than sequential. The decision allowed two workers only for graph-certified nodes and kept shared-schema tasks sequential.

Limits

Results depend on repository topology, task duration, model and tool behavior, and reviewer workflow. Another codebase needs its own collision fixtures and cost comparison before adopting the same worker limit.

Method

Build it, with checkpoints

Field situation

Should these tasks run concurrently, and what graph or ownership change would make a later parallel trial defensible?

01Declare nodes, dependencies, and conflict zones
02Run equivalent sequential and parallel trials
03Verify branch and integrated truth

Acceptance checks

The system refuses overlapping parallel work, proves isolated eligible work through integrated acceptance, reports the real coordination tradeoff, and detects five forms of harness drift before they misguide another session.

Why this visualA dependency graph with ownership and conflict zones shows when parallel work is eligible and where integrated verification must occur.

01
Declare nodes, dependencies, and conflict zones
For each node, record contract, upstream evidence, owned paths, protected paths, mutable resources, output receipt, budget, verifier, and merger. Run static and generated path analysis to expose shared schema, fixture, migration, and configuration surfaces before dispatch.
CHECKPOINT · The original two-node graph is rejected for overlap, and the revised graph makes shared schema work a verified upstream dependency.
02
Run equivalent sequential and parallel trials
Execute the same final scope once sequentially and once with two eligible workers. Record wall time, total model and tool use, retries, duplicate reads, changed paths, conflicts, integration repair, reviewer time, critical failures, and final evaluator results.
CHECKPOINT · Both trials reach equivalent integrated behavior and receipts, or the comparison records a no-go without repairing evidence after the fact.
03
Verify branch and integrated truth
Validate every branch receipt against commit and environment, merge only eligible outputs, regenerate repository facts, then run migrations, mechanical rules, full evals, browser acceptance, and receipt checks on the combined commit. Preserve conflicts as named decisions.
CHECKPOINT · The integrated receipt accounts for every node, changed path, conflict decision, effect, fixture, and verification layer.
04
Seed and repair harness entropy
Break one instruction link, age one exception, stale one generated route map, orphan one receipt, and remove one fixture target. Run harness health, repair each finding through its owner, and record maintenance time plus the rule or generation change needed.
CHECKPOINT · All five drift fixtures fail with distinct codes, clean state passes, and the health receipt records map generation and source commit.

Operating context

Beyond the demo

Schedule from ownership and evidence

Each graph node declares task contract, dependency evidence, owned paths, protected paths, environment resources, budget, expected artifacts, merge conditions, and verifier. Eligibility requires all upstream receipts, a healthy isolated environment, and no overlap with active ownership. A coordinator cannot create independence by writing a vague assignment.

Integrate through receipts and diffs. Verify each branch alone, then verify the combined state. If two results conflict on architecture or evidence, preserve both and route the conflict to a named decision. Do not ask a synthesizer to smooth incompatible changes into plausible prose or code.

Budget maintenance as product work

Create a harness health command that checks instruction links, generated-map freshness, source access dates, fixture reachability, rule parity, exception expiry, ledger evidence, and orphaned artifacts. Some checks run on every change; slower regeneration and full link verification can run on a schedule or relevant path change.

Track harness change alongside feature change. A repository that needs constant human correction may lack legibility or useful controls even if its feature throughput looks high. Report maintenance time, false positives, stale findings, regenerated artifacts, and reviewer burden so scaffolding that costs more than it saves can be simplified.

Hands-on lab

Run a two-worker graph and entropy audit

Model three Release Desk nodes, reject the seeded overlap, split shared schema work upstream, run isolated branches, verify integration, then age selected harness artifacts and detect the drift.

Prepare

• Create explicit worktree and environment records for sequential and parallel trials without touching another local project's resources
• Freeze task contracts, expected integrated behavior, critical gates, cost fields, overlap policy, and the harness-health manifest

Deliverable

A validated work graph, ownership and conflict report, sequential and two-worker receipts, isolated environment proof, integration evidence, decision memo, harness-health manifest, seeded drift fixtures, and maintenance budget.

Starter kit: Work graph manifest

YAML

nodes:
  schema-contract:
    dependsOn: []
    owns: ["src/domain/transition-schema.ts", "migrations/rd-transition/**"]
    outputs: ["receipt:schema-contract"]
  request-reasons:
    dependsOn: ["schema-contract"]
    owns: ["src/app/requests/**"]
    verify: ["npm run harness:eval -- --case RD-REASONS"]

Downloadable artifacts

Work graph manifest

work-graph.yml · YAML

An editable course fixture for the main lab. Save it inside the Release Desk repository before running the acceptance command.

Run receipt template

he-09-receipt.json · JSON

A compact evidence record for the check, environment, result, and limits that another reviewer must be able to inspect.

Acceptance command

npm run harness:graph -- --manifest .harness/work-graph.yml --compare --entropy

Expected receipt

PASS he-09 graph-and-entropy
eligibleWorkers=2 overlapsAccepted=0 integrationCriticalFailures=0
entropyFixturesCaught=5 decision=bounded-parallel

Expected result

Carry forward

The graph, comparison report, and health manifest become capstone inputs. Preserve the rule that scaling requires measured integrated value and a clear rollback to simpler execution.

Acceptance checks

01Graph validation blocks active path, migration, fixture, configuration, or mutable-resource overlap before worker dispatch
02Sequential and parallel reports include equivalent final scope, all costs, reviewer burden, conflicts, critical failures, and integrated evidence
03Every branch uses isolated ports, data, cache, logs, screenshots, processes, and cleanup ownership
04Harness health detects broken instructions, expired exception, stale generated map, orphaned receipt, and missing fixture target

What breaks

Failure clinic

F1Two branches pass alone but lose a case after merge.

Inspect: Compare owned paths, shared fixtures, migration order, generated maps, test registries, merge decisions, and integrated receipt.
Likely cause: Planning treated feature labels as independence and skipped combined verification.
Repair: Restore the lost case, create an upstream shared-contract node, and rerun both branch and integration gates.
Prevent next time: Validate path and resource conflicts before dispatch and require a dedicated integrated verification node.

F2Parallel wall time improves while reviewer time and total cost double.

Inspect: Break down coordinator, worker, tool, retry, duplicate source, conflict repair, integration, and review usage.
Likely cause: The decision counted only elapsed implementation and ignored coordination plus final evidence work.
Repair: Recalculate the complete comparison and reduce workers or return dependent tasks to sequential execution.
Prevent next time: Predeclare value, quality, cost, review, and critical-failure gates for every scaling experiment.

F3The repository map confidently points agents to a deleted route.

Inspect: Check generator version, source commit, path-change triggers, health receipt, instruction links, and last successful regeneration.
Likely cause: Generated knowledge had no freshness contract or failed silently after topology changed.
Repair: Regenerate from the current commit, repair the trigger, and add the stale state as a health fixture.
Prevent next time: Publish source commit and generator hash, then gate relevant path changes on freshness verification.

Beyond the demo

Production boundary

01Work nodes declare dependencies, evidence inputs, owned outputs, conflict zones, resources, budgets, verifier, and merger
02Eligibility blocks unresolved dependencies, overlapping ownership, unhealthy environments, stale contracts, and missing upstream receipts
03Every worker has isolated network, data, cache, log, screenshot, process, fixture, and cleanup ownership
04Parallel decisions compare equivalent integrated scope across quality, critical failures, wall time, total cost, review, and recovery
05Integration validates branch receipts, conflict decisions, generated facts, migrations, rules, evals, browser behavior, and effects
06Harness health checks instruction links, map freshness, sources, fixtures, rules, exceptions, ledgers, receipts, and orphaned artifacts

Evidence status

Sources and claim limits

Sources support the named claims; they do not guarantee the same result in another system.

[1]
Harness engineering: leveraging Codex in an agent-first world
OpenAI · Public case · 2026-08-26
repository knowledge · agent legibility · mechanical enforcement · entropy management
[2]
Effective harnesses for long-running agents
Anthropic · Published research · 2026-08-26
initializer pattern · feature ledger · session handoff · end-to-end verification
[3]
Learn Harness Engineering
Walking Labs · Public case · 2026-08-26
project-based sequence · five harness subsystems · loop engineering · graph engineering
[4]
Andrej Karpathy's AI Engineering Playbook
AI Builder Club · Public case · 2026-08-26
Software 3.0 framing · spec-diff-eval practice · parallel session framing · repository instructions
[5]
Harness Engineering learning guide
deusyu · Public case · 2026-08-26
repository as record · mechanical rules · agent readability · continuous cleanup