Guides / Building software with AI agents

Batch questions with QnA MD and the agentic development life cycle

How agents compile open questions into one QnA MD file, an owner answers them in one sitting, and the answers are applied and recorded before the next round.

Product help

By Steven Michael Barber · Published October 19, 2026 · Updated November 3, 2026 · 5 min read

An AI agent that asks a question the moment it needs an answer has two bad options while it waits: stop, or guess. A person with several agents running gets a steady trickle of interruptions, each needing a context switch. Batching changes the rhythm. Agents collect their questions into one file, the person answers the whole file in one sitting, and the agents apply the answers together. This guide describes that loop as we run it with QnA MD, and how it shapes the way we develop software with agents.

The loop

1. Stage. While they work, agents write each question they cannot settle as a QnA MD tag, with options, a recommendation and a reason. Work that does not depend on the answer goes on; work that does waits, or proceeds on a stated assumption.
2. Compile. One agent gathers the open questions from every plan, record and session into a single file, removes duplicates and anything already answered, and orders the rest.
3. Answer. The person opens the file on a phone and works through the Review tab.
4. Apply. Agents read the answers back and change plans, documents and code to match.
5. Record. Each applied answer gets a note in the file and a line in a dated decisions record, so the next round starts from what was decided.

Then the next round begins. The file is the hand-off in both directions.

Compiling a good round

A batch is only quick to answer if it is well prepared. The compiling agent does most of the work:

• Cross-check before asking. Search earlier decision records and answered files, and drop anything already decided. Asking the same thing twice wastes time and can produce two different answers.
• Put the urgent items first and say so at the top of the file, so a person with ten minutes answers the ten that matter.
• Prefer taps to typing. A confirm or choice with one option marked (rec) can be answered in seconds. Keep free-text questions for things that genuinely need words.
• Cite the source. A ref: to the plan or record a question came from lets the person check, and lets the applying agent find where the answer goes.
• Group ids by area, so answers can be split among agents afterwards. The tag conventions are in the file format guide.

Answering in one sitting

The Review tab shows the items waiting on the person's handle, with a count. Each card shows the paragraph above the question, the question, the reason and the recommendation. The buttons map to how people actually work through a list:

• Answer resolves the item.
• Partial records a half answer and keeps the item in the queue.
• Defer parks it after everything still open, and writes that into the file.
• Veto closes the topic with a one-line reason, until someone explicitly reopens it (the reopen is logged too).
• Skip moves on without changing anything, for this sitting only.

When the queue is empty, the person saves the file and puts it back where the agents read it.

Applying the answers

The read-back rules keep agents from overreaching. Act only on resolved items, or decisions whose chain is complete. Treat partial as a reason for a follow-up question in the next round. Leave deferred items alone. Drop vetoed topics and say so. Never write an answer under the person's handle; record what was done as a note under the agent's own handle, starting with "applied:".

A large round can be split by id prefix, one agent per area, with one coordinating session that collects the results into the decisions record.

Worked example: a three-item round

A coordinating agent compiles three open questions addressed to @owner: whether to offer annual billing, which guide to write first, and which region a new database should use. The owner taps Yes on billing, defers the guide choice until a meeting and vetoes the new database. Later that day the agent adds annual billing and logs its own application note. Here is the resulting file:

<!-- oq:file v=0.1
people:
- @owner = The owner
- @lead = Coordinating agent (agent)
-->

# Open questions, round 7

<!-- oq:confirm #pay-01
by: @lead 2026-10-12T17:00Z
to: @owner
status: resolved
Q: Offer annual billing at launch?
- [x] Yes (rec)
- [ ] No
why: Two agents need this before they can finish checkout and the pricing page.
log:
- @owner 2026-10-12T19:31Z answer: Yes
- @lead 2026-10-12T21:48Z note: applied: annual price added to checkout and the pricing page
-->

<!-- oq:choice #doc-04
by: @lead 2026-10-12T17:00Z
to: @owner
status: deferred
Q: Which guide is written first?
- [ ] A. Setup guide (rec)
- [ ] B. Migration guide
why: The setup guide is linked from the app's first screen.
log:
- @owner 2026-10-12T19:32Z defer: After the pricing call on Tuesday
-->

<!-- oq:ask #ops-02
by: @lead 2026-10-12T17:00Z
to: @owner
status: vetoed
Q: Which region should the new database run in?
log:
- @owner 2026-10-12T19:33Z veto: No new database this quarter
-->

The queue for @owner now holds only doc-04, marked deferred, and it will come back in the next round. The agent knows to build one thing, wait on one and drop one, and the reasons are in the file.

What a real round looked like

In our own studio, one round compiled 123 open questions from the repository and from every earlier agent session; 26 more were dropped after the cross-check found them already answered. Sixty-eight were single-choice and fifty-three were yes-or-no confirmations, and all but two carried a recommendation. The owner answered all 123 in about twenty minutes in the QnA MD editor, choosing against the recommendation 19 times. The same evening, one coordinating session and five agents, each taking one area, applied the answers and wrote a decisions record listing every answer, what changed and who acts next.

The speed came from the preparation, not the app: most items were one tap because an agent had already done the research and written a recommendation the owner could accept or overrule.

The file as memory between sessions

The next compiling agent checks this file and its decisions record before gathering another round. That read-back, backed by git history, prevents an answered question from returning just because a new session lacks the earlier chat.

How it shapes the development life cycle

With agents doing most of the building, the scarce resource is the person's attention for decisions. A life cycle built around batched questions puts that attention in one place: agents work in parallel between rounds, decisions arrive together, and each round leaves a written record. Rounds can be scheduled, so a person might clear a file each evening and find the results applied by morning.

The cost is latency. An agent blocked on an answer waits for the next round, so blocking questions belong at the top of the file, and truly urgent ones still deserve a direct message. For why the format is a Markdown file at all, see why we built QnA MD; for other patterns, QnA MD use cases. The editor is free at /qnamd/.