Last week, Anthropic published The AI-Native SDLC playbook, outlining how committed markdown artifacts—intent.md, spec.md, and plan.md—replace the slow, manual handoffs of traditional engineering. It is a solid operational framework for stage-by-stage development. But once you move from single-agent chats to an autonomous multi-agent harness executing parallel waves of work, you run directly into a structural challenge that basic artifact passing cannot solve alone: context management and authority scoping across an organizational hierarchy.
In ETC (the agentic software engineering harness I built at Heavy Chain), we run multi-agent pipelines with operators, conductors, software engineering managers, workers, and reviewers. Over hundreds of builds, we discovered that multi-agent systems suffer from the exact same failure modes as human engineering teams: either an agent guesses what was omitted and hallucinates, or the system dumps everything inline and drowns the model in tokens.
To address this—as one critical technique among the broader flotilla of agentic engineering needs—we codified what I call the Information Ladder. It is a strict information contract governing what flows down, what flows up, and what is deliberately stopped at every rung of the hierarchy.
The Premise
A software organization is an information ladder. Intent enters at the top as a business problem. Each level narrows it for the level below—the VP turns a roadmap item into a feature with constraints, the manager turns the feature into tasks with owners, the engineer turns a task into a change—and each level reports upward in a form the level above can act on without re-reading everything below it. Nobody hands an engineer the whole company strategy, and nobody hands the VP an engineer's terminal scrollback.
An AI SDLC has exactly the same ladder, with the same two failure modes when it is ignored: the recipient guesses at what was narrowed out, or the sender inlines everything and drowns the recipient in tokens. ETC's ladder is the operator, a VP-level conductor (the /etc:epic or /etc:build session), one Software Engineering Manager (SEM) agent per feature, and workers and reviewers per task. What follows is the information contract at each rung—what flows down, what flows up, and what is deliberately stopped.
Down the Ladder: What Each Level Is Handed
| Level | Receives | Deliberately Does Not Receive |
|---|---|---|
| Operator → VP Conductor | Intent and approval state; the epic DAG or the feature ID; frozen contracts and the collision map; the roadmap item; domain grounding; the model/effort ruling; the authority boundaries | Task-level detail, code, worker transcripts |
| VP Conductor → SEM (one per feature) | The feature ID with spec, design, and ADRs by pointer; the approved task DAG; frozen contracts; wave policy—concurrency, isolation, model split; domain grounding; the report contract it must return; what it may not do (merge, release, edit frozen contracts) | Other features' state, the operator's conversation, sibling SEM transcripts |
| SEM → Worker (one per task) | The ten layers below: identity, task summary, its acceptance criteria verbatim with the requirement IDs it serves, file scope, design references by section, the domain paragraph, its role, the response contract and evidence path, the runtime pointer, its workspace, and cross-task awareness (sibling task IDs and the files they own) | The whole specification inline, other tasks' design sections, the SEM's plan, review findings not addressed to it, any authority verb |
| SEM → Reviewer (five roles, fresh, blind to each other) | The candidate commit; the review role and its checklist; the acceptance criteria relevant to the role—spec-compliance gets all of them, security gets the threat model and touched surfaces, architecture gets the design and ADRs; the record schema it must emit | The workers' transcripts, the other reviewers' findings, the SEM's opinion of the code |
The rule that falls out: information narrows going down, and the narrowing is done by the level above, from durable artifacts—never by the recipient guessing. The worker's slice is cut by the SEM at decomposition. The SEM's slice is cut by the VP conductor from the epic. Domain grounding is the one thing that flows unchanged to every level, because it changes what "correct" means everywhere.
Up the Ladder: What Each Level Reports
| Level | Reports Up (Structured, Digest-Bound) | Filtered Out on the Way Up |
|---|---|---|
| Worker → SEM | The evidence file: task ID, terminal status, changed paths, commands run and their results, coverage, gaps, the context-fitness stanza; the final message is the report | Reasoning, transcript, exploratory reads, narrative "done" |
| Reviewer → SEM | The review record at the exact commit: verdict, findings with file and line and severity, the role | Prose beyond the record; suggestions outside the role |
| SEM → VP Conductor | Per wave: completed and blocked task IDs with evidence paths, seam-join results, reconciliation exceptions, the candidate commit, the review aggregate, blockers that need a ruling, cost (turns, resumes, timing) | Per-task evidence bodies, review finding lists (pointer only), anything already recorded in engine state |
| VP Conductor → Operator | Stage transitions, the exact commit, what needs a human decision (policy forks, authority actions), the handoff block: commit, artifact paths, tests actually run, unresolved risks, next action | Everything else—it is on disk |
Two properties make this the organizational analogy rather than a diagram:
Each level's report is the engine record, not a message.
task completefor workers,reviews.jsonfor reviewers, the workflow and build records for the SEM. The message that travels up is a pointer to the record, so an escalation costs the level above one read, not a transcript. The level above never needs to trust the message, because it can verify the record.Authority has the same shape as information. A worker cannot complete a task, a SEM cannot merge, a VP cannot release. Each level can only record upward and narrow downward. The constraint that keeps the conductor's context clean (one orchestration entry point; the conductor's context is sacred) is the same constraint that keeps authority from leaking: nothing flows up except records, nothing flows down except slices.
The Worker's First Screen: Ten Layers
The bottom rung is where the ladder is most often broken, so it is worth being exact about what a worker must know at its first token. Every layer comes from an artifact the engine wrote and bound by digest; nothing depends on the provider delivering anything but the prompt.
| # | Layer | Content |
|---|---|---|
| 1 | Identity | Feature, dispatch, task ID, title |
| 2 | Intent | Two to four sentences: what this task builds, why, which acceptance-criterion slice is its own, and when it is done |
| 3 | Finish line | The acceptance-criteria text the task serves, and the requirement IDs behind it—not IDs alone |
| 4 | Scope | The files it owns, and nothing else |
| 5 | Reading | Design sections and decision records by anchor, in order, each with a few words saying why |
| 6 | Domain | One paragraph: what this codebase is and for whom; the full domain document by pointer |
| 7 | Role | The persona for the task's role, by path, with the instruction to read it first |
| 8 | Response contract | The final-message rule and the evidence file path |
| 9 | Runtime & workspace | The engine's absolute path and the operating standard; the worktree, its base commit, and the instruction to change into it |
| 10 | Cross-task awareness | Sibling task IDs in this wave and the files they own |
And an eleventh that is not content but proof: a test, run on the real harness as a release gate, that spawns each role and asserts these layers arrived. A test that the manifest file contains the text proves the bundle, not the launch.
Two Lessons That Shaped This
1. Delegated delivery is hope until proven
ETC's agents had rich persona definitions and a start-up hook that injected the operating standard into every worker. Probing the real harness showed that neither reached a single worker—the provider applied the persona's model and tool list and dropped its body, and the hook's output never arrived. Builds still shipped correct code because the gates after the work do not trust the worker, but every worker had been running without its role. Any instruction a worker needs must ride in a channel the harness owns and can verify—the rendered prompt and the manifest—with provider mechanisms as a bonus nothing depends on.
2. Inline the slice, point at the whole, and make the pointer list complete
Every token matters in both directions. Inlining a 6,500-token specification and a 2,800-token domain document into nine workers costs ~85,000 tokens per wave, a tenth of which any one worker needs—the previous generation of this harness had already forbidden inlining the design. But a pointer list that omits the specification or the domain document is hope again: the worker reads what it was told to read.
The token-efficient shape is the one the ladder implies: the level above cuts the slice and inlines it (summary, this task's criteria, the domain paragraph, sibling ownership—about 1,300 characters for a real task), and hands a complete, ordered, engine-enforced reading list for the rest.
What This Is Not
It is not a second scheduler, a second state engine, or a prompt-template library. It is a declared subset of the ten layers per role—worker, reviewer, SEM, VP—checked when the dispatch is rendered, and a report schema per level that is already, for the most part, the engine's existing records. The ladder was always the design; this makes each rung verifiable.
Jason Vertrees is the founder of Heavy Chain Engineering, which helps lower middle-market vertical SaaS companies and PE firms turn scattered AI usage into measurable delivery leverage — 85% faster feature velocity, six-to-eight-week projects shipped in days. If you want help building an AI-native engineering organization, book an AI Delivery Assessment.