Subagent context engineering

Coding agents are designed to help. Give them a task and they will usually start trying to solve it. That is useful, but it can also mean they do not question a bad premise as much as they should.

A long context makes this worse: every answer is anchored by assumptions from earlier turns. The fix is to stop asking the agent that has watched the idea develop and start one that has not. The phrasing I keep typing is use a blind sub agent, harvest the feedback — for a README, a PR, a type design, a language choice, a docs front page. About my own writing I usually ask: "what does a blind untainted agent say about the readme?"

Whether a sub agent ends up blind depends on the harness, not on the prompt. The harnesses differ in how much context a sub agent inherits, and in who writes the seed:

• Claude Code seeds sub agents with a fresh, isolated context window. The main agent improvises a delegation message (no template, no verbatim user text), and the harness stacks the subagent's own system prompt (the agent definition, not the full Claude system prompt), the CLAUDE.md hierarchy, a git status snapshot, and any preloaded skills around it. Blindness is the default.

• Codex is the only harness where blindness is opt-out. Sub agents fork the parent's history by default: fork_turns takes all (the whole conversation, mechanically filtered to user turns and final answers, tool noise dropped), none (a fresh thread with only the parent's message), or a number (the last N turns). The parent writes the message field, passed through verbatim. It is also the only harness where your original words reach the sub agent by default, and the docs warn that cutting context "may cause the agent to lack the context it needs" — a blind spawn means overriding both the default and the documented advice.

• omp sub agents start blank. The main agent expands your one-liner into a brief under format contracts: # Goal / # Constraints / # Contract for the shared context, # Target / # Change / # Acceptance per task, and the tool prompt outright prohibits one-liners. The harness delivers the task text byte-identical inside a templated first message ("Complete assignment thoroughly: …") and injects the context into the subagent's system prompt.

• pi has no built-in sub agent feature. Its sub agent extension starts a fresh pi --no-session process per agent: the system prompt is the agent definition file verbatim, and the only user message is the Task: line the main agent wrote. Nothing else is appended.

The split is the same everywhere: the parent improvises the brief, the harness wraps it in scaffolding. In the seeded harnesses your original words never cross — the parent's rewrite is the whole content bridge. Codex's default fork is the exception: everything crosses, verbatim. The scaffolding is fixed; the brief is the only lever. Inherited context is good for continuation work, terrible for judgment. A fork that carries the whole conversation will validate the trajectory it just inherited. Seeded context produces opinions that are actually untainted, at the cost of making the brief do all the work.

Blind never means zero context. Repo instructions, git status, and workspace files ride along in every harness. It means the conversation does not.

So a blind agent needs a self-contained brief: which files to read, what "done" means, what evidence to return. Nothing carries over. My briefs have converged on a shape: investigate read-only, cite concrete files and lines, describe current behavior and invariants, expose risks and unknowns, return a recommendation an implementer can act on. Writing that brief forces me to say what I actually want checked, which is half the value.

I use blind agents in three modes:

• Cold reads. Give the README or docs front page to an agent with a specific background and ask for general feedback. Then trim and restructure, and repeat with a different background each round so the reviewer never anchors on the previous round's feedback. The rotation is the mechanism: each round is a fresh viewpoint, and the changes land between rounds. Someone new to the domain catches what the docs silently assume; someone from a neighboring stack catches what is jargon; someone who has taught the subject catches what is missing. For a database library those rounds might be Drizzle, Kysely, and Prisma users in turn. The names are incidental — rotating viewpoints is the point.

• Blind builders. Hand an agent only the public surface of a platform (a skill file, an account token, nothing else) and tell it to build something real and report every bug, silent failure, and confusing error with a severity and a repro. "You are a BLIND developer's agent. You have NO insider knowledge." Its confusion is the product finding. This is the closest thing I have to penetration testing without hiring a pentester.

• Fresh-eyes review. "Now look at the PR with fresh eyes, critical of complexity, security, agent ergonomics — launch separate review agents." One-off blind reviews beat the anchored opinion of a long session, and they are cheap enough to rotate per domain: a Postgres specialist on schema compat, a tRPC person on types.

Two habits make blind agents reliable. Smoke-test the cold-start pipeline before trusting it with real work: "ensure pi sub agent works before starting work" got me a subagent-ok before any real delegation. And when blind tests keep surfacing things that should have been covered by test cases, the fix is usually an integration test, not a longer prompt: "are we missing an integration test suite?"

The same pattern works beyond the repository. Agents can harvest primary research, online conversations, competing approaches, and prior art, then synthesize the useful disagreement back into PLAN.md.