Autonomy

Autonomy

Status: v5 direction. This page describes the autonomy model harness-kit is moving to. The intake stage and the resolve-mark-proceed disposition are being rolled out stage by stage, starting with prd. Where a mechanism is not yet live, it is marked (planned).

harness-kit's original design stops and asks the human for inputs before each artifact: the PRD agent asks for squad, problem, customers, hypothesis, and bet link; the PRP agent asks for repo paths. Every question is a place the run halts. The autonomy work removes the trivial questions without removing the real decisions, so one command carries an idea end to end and only pauses where a human genuinely adds judgment.

Questions are missing context in disguise

An agent asks a question when it lacks the context to proceed. There are two ways to remove the question:

1. Delete it and let the agent guess. This produces confident, wrong artifacts: a hallucinated squad, an invented metric, a plausible-but-fake customer. Worse than asking.
2. Give the agent a way to find the answer itself. The repository, its history, and the context library already hold most of what the questions were fishing for. Read them first, ask only for what is genuinely external.

harness-kit takes the second path. This mirrors what happens when a coding agent is turned loose on a well-structured repository with no bespoke setup: it reads the code, the README, the recent commits, and infers intent. The autonomy work makes that reading step explicit and mandatory, so inference happens before any question is raised.

In harness-engineering terms this is a shift from feedback to feedforward (see Harness Engineering). Asking the human mid-run is feedback: the agent produces a gap and waits for a correction. Harvesting context up front is feedforward: the agent is handed what it needs before it starts, so the gap never forms.

The intake stage

Autonomy is anchored by a new first stage, intake, that runs before prd. It is a subagent whose entire job is to gather context and commit it to a single artifact the rest of the pipeline reads.

intake  →  prd  →  prp  →  plan  →  dev  →  test  →  pr
  │
  └─ reads:  target repo (code, README, recent commits, open PRs/issues)
             context-library/ (business-info, squads/, metrics/, decisions/)
             git remotes and repo registry
  └─ emits:  .claude/runtime/outputs/intake/{feature_id}.md
             { squad, problem, customers[], hypothesis, repos[], metrics, unknowns[] }

Because it is a subagent, intake runs in an isolated context. Its heavy exploration, potentially hundreds of files read, never pollutes the context of the stages that follow. They receive only the distilled intake.md, not the raw search.

The intake artifact is the single source of the answers the PRD agent used to ask for. The PRD agent no longer interrogates the human; it reads intake.md.

Resolve, mark, proceed

Every input the pipeline needs has one of three dispositions. This replaces the binary ask-or-block.

Disposition	When	What happens
Resolve	The answer is in the repo or context library	Intake writes the value into intake.md. No human contact.
Mark	The answer is genuinely unknowable from available context (e.g. a bet link, an exec's target)	Intake writes NOT FOUND - NEEDS REVIEW: {detail} and adds it to unknowns[]. The run continues.
Proceed	Always	The pipeline never blocks on a missing input mid-run. Unknowns are surfaced at the next gate, not as an interrupt.

The evals already tolerate a bounded number of unresolved markers (prp-context-quality blocks only above five NEEDS REVIEW/TBD markers). Autonomy leans on that existing tolerance: a few honest unknowns are acceptable and visible; they are not a reason to halt.

The rule in one line: resolve from context, mark what you cannot, never stop to ask.

Gated autonomy: humans on the loop, not in it

Full autonomy is not the goal. Unattended generation with no human checkpoint is both dangerous and expensive to undo. The goal is to move the human from in the loop (answering an input before every artifact) to on the loop (approving direction at the points where review is cheap and a mistake is expensive), a distinction drawn from Böckeler's harness-engineering writing.

harness-kit places human gates only at high-leverage, low-reversibility boundaries:

intake → prd → [ GATE: approve direction ] → prp → plan →
dev → test → [ GATE: approve PR before it opens ] → pr

• The PRD gate costs the human ~30 seconds and prevents an entire dev run aimed in the wrong direction. This is the single most valuable checkpoint in the pipeline.
• The PR gate guards the one outward-facing, hard-to-retract action: opening a pull request.

Everything between the gates runs without interruption. Two decisions, not a dozen questions.

A --yolo flag (planned) removes even these gates for trusted, low-risk flows, collapsing the whole pipeline to a single unattended command.

What stays deterministic

Not every removed question needs an LLM. Some are lookups, and a lookup should be code, not inference:

• Repo paths. A context-library/repos.md registry (planned) maps squad → repo paths, so the PRP agent resolves targets by table lookup instead of asking. When the registry has no entry, intake falls back to auto-detecting from the current working directory and git remotes.
• feature_id. Already computed deterministically as {YYYY-MM-DD}-{squad}-{slug}.

Keeping these in code makes them cheap and reliable, and reserves the agents for the parts that actually need judgment.

How it plugs into the existing harness

Autonomy adds one stage and changes the disposition of inputs. It does not replace the gating machinery:

• Sensors and evals still fire on every stage. An autonomously-produced PRD is held to the same prd-structure and prd-quality bars as a hand-guided one.
• Markers, token accounting, and .pipeline-state.json are unchanged. Intake is just another stage that writes an artifact and flips state through the same hooks.
• /pipeline:continue still resumes at the next pending stage, so an autonomous run that fails midway is as resumable as any other.

The pipeline gets more independent without getting less governed. The gates that make the output trustworthy stay exactly where they were.

See also

• Orchestration and Subagents: the intake subagent and the orchestrator that owns state
• Pipeline and Stages: where intake sits and how gates work
• Harness Engineering: feedforward vs feedback, humans on vs in the loop