loop plan is built to be driven by an agent talking to a person. The machine asks one question at a time and decides when the interview is over; the person answers.

ak-harness loop plan start "we need usage-based billing for the API"
# → { "planId": "…", "question": { "id": "q1", "text": "…" } }

ak-harness loop plan answer q1 "per request, counted at the edge, billed monthly"
# → the next question, or "the interview is done"

ak-harness loop plan show <id>            # the PRD so far, as Markdown
ak-harness loop plan approve <id>         # HUMAN GATE — the architect starts
ak-harness loop plan architect <id>       # the design, then the vote
ak-harness loop plan approve-design <id>  # HUMAN GATE — everything inherits this
ak-harness loop plan decompose <id> --create

The interview ends when the machine says so

Not when a model declares itself finished. The PRD has required fields — objective, users, inScope, successCriteria — and the interview continues while any is empty or any question is open. A model that says it is done with a gap still open is asked again.

How to relay a question

Put it to the person in substance, and add what you actually know:

Which requests count as billable? From the codebase, three plausible answers:

1. every request that reaches the router, including 4xx (simplest, matches the current metrics);
2. only 2xx responses (kindest to customers, needs a change in the edge middleware);
3. only requests that reached a model call (closest to real cost, hardest to measure).

I would pick 2: it is what your pricing page already implies.

A question relayed bare wastes the person's turn. A question with alternatives and a recommendation costs them one word.

The one rule

Never answer in the human's place. Not "the obvious choice is X, recording X". Not a default because they are slow to reply. Not an inference from the codebase, however strong. Those answers are the requirements, and a requirement invented by an agent is how a plan ends up building the wrong thing confidently.

"I don't know, decide later" is a real answer — record it, and the PRD carries it as an open point.

What comes out

decompose produces issues that each carry a layer label, a priority, verifiable acceptance criteria and a designRef back to the approved design. Without --create nothing is written to the tracker. With it, they are created in the queue's entry state: moving them into the ready state is the single gate into the queue, and it stays a human gesture.

The skill ak-harness-loop carries this same guidance for agents operating the loop from a chat session.