# Interview — decision discipline — ORCHESTRATED · dispatch **Everyone whose setup looks like this should read this file.** More than one agent runs at once, from a queue. Runs read what their brief names and cannot ask why a choice was made, so a decision overtaken after the brief was written is executed in good faith. You are running this because someone pasted it from docs.utopiamodels.ai. Your job in this step is to ask what cannot be measured, and to write files a second prompt will read. You are not building anything yet. The reader is a senior technical person — an engineer, a consultant who writes SQL and builds decks, a founder who still ships. Do not explain what an AI agent is. Do not reassure. Ask the question and take the answer, and where they are wrong about their own setup, say so with the evidence. --- FIRST — WRITE YOUR CHECKLIST TO A FILE Long sessions compress their own history, and instructions pasted into chat get dropped when that happens. Files do not. Write your checklist to a file in the output folder before anything else, and work from that file rather than from this message. Tick each box as you finish it, not at the end. --- ASK WHERE THE OUTPUT GOES — RECOMMEND, THEN CONFIRM Everything this module writes about the reader's setup lands in one folder, and every later module gets its own subfolder beside it. Propose this, and ask them to confirm or redirect: /patterns/decision-discipline/ This folder holds the four files below — the record of THIS session. It is not where their decision records will live; prompt 2 puts those beside the work they bind, and asks first. Lead with your own recommendation rather than an open question. If they keep notes somewhere with an obvious convention, mirror it and say that is what you are doing. If there is no convention, propose a dedicated folder in their home directory and say why: a module that writes into a folder it shares with other work is a module whose output cannot be found again. One question. Then create the folder and say where it is. --- OPEN BY STATING WHAT YOU FOUND — DO NOT OPEN WITH A QUESTION You surveyed before this. Play it back as assertions and invite correction, and keep two kinds of statement visibly apart: MEASURED — you ran a command and read the output. Assert it. Do not offer to edit it. INFERRED — you concluded it. Show it as a correctable default and say it is an inference. Collapsing those two produces either an interview that re-asks what it already knows, or one that silently locks in a wrong guess. Both lose a technical reader in the first two minutes. --- HOW TO ASK — THIS MATTERS MORE THAN THE QUESTIONS ASK WITH your harness's own interactive question tool (Claude Code `AskUserQuestion` · opencode `question` · Codex CLI `request_user_input` · Gemini CLI `ask_user` · Cursor's built-in Ask-questions tool; Claude Desktop has none — write the option list out instead). Every question in this step, including the first one, including the folder question. Not prose in the conversation. This is not a formatting preference. A question asked in prose has no options, so it has no RECOMMENDED option — and a recommended option is the entire mechanism by which someone who reads nothing still ends up with a working system. Asking in prose silently removes that, and the conversation looks fine while it happens. If your harness is not in that list, or has no such tool, say so in one line and then ask in plain text with the options written out and the recommended one marked. Never drop the options. EVERY QUESTION CARRIES A RECOMMENDATION. Put it first, label it, and give one line of why. The person should be correcting a decision, never composing one from nothing. ONE QUESTION AT A TIME. Not four, not a batch. A batch makes a follow-up probe structurally impossible, and the follow-up is where the real answer lives. FIVE TO SEVEN QUESTIONS. Hard ceiling of ten. The constraint is not that they will abandon it — this audience finishes. It is that a reader who has decided the interview is not listening will answer question eleven with something reasonable-sounding produced by no actual thought, and that failure is invisible: the interview completes and the answers look fine. SPEND QUESTION ONE DELIBERATELY. It costs about two and a half times what question three does. Never a warm-up. ASK ONLY WHAT A COMMAND COULD NOT ANSWER. If you could have measured it, measure it. Asking someone what you could have read is the fastest way to lose their attention, and their recalled answer is worse than the measurement anyway. LEAD WITH YOUR OWN ANSWER, so they are correcting rather than composing. NEVER ASK FOR MOTIVES IN THE ABSTRACT. "What are your goals" produces fluent, generic, useless text. "I see X on this machine — what are you trying to do with it?" produces a real answer, because it is a correction task rather than an essay prompt. PREFER OPEN TEXT FOR GOALS. A multiple choice partly authors the answer: in one measurement, 58% of people picked an option when offered it against 35% who volunteered it unprompted. Use options only for genuine either/ors. STOP WHEN YOU CAN WRITE THE FILES, not when you reach the end of a list. --- ## The questions These are the ones a command cannot answer. Ask them one at a time, in this order, and stop early if you can already write the files. Where the survey already found the answer, assert it instead and skip the question. 1. What is the last decision an unattended run reopened, and what did undoing it cost? 2. Where do runs read decisions from, and is that the same place people write them? 3. What have you deleted that a scheduled or dispatched job could bring back? 4. Which caps set concurrency, retries or timeouts, and what measurement set each? 5. When a brief cites a decision that has since been superseded, what catches it? **Then one more, always, and it is the highest-yield question in the set:** What should I have asked you and did not? --- ## The objection you should expect > **My runs follow the spec. Why do they need decision records?** Because a spec can cite a decision that was replaced after the spec was written, and a run executes it faithfully. Runs cannot ask; they can only read. The failure is silent — correct code built on a dead choice, merged, and green. Answer it before they raise it, not after. --- ## What this tier is missing, and what closes it - **a run cannot reopen a decision without writing a superseding record** — otherwise every run is free to re-decide what the last one settled - **every cap carries the measurement that set it** — an unmeasured ceiling becomes your capacity without ever failing Name these in `TIER.md`. Do not present them as failure — a setup that is deliberately here is correctly classified, not behind. --- WRITE THESE FOUR FILES In the folder they confirmed. These are what the execution prompt reads, so the headings are fixed. DECISION-MAP.md — the durable one. Headings, in this order: ## Where decisions live now every place a choice is recorded today — a records directory, a docs page, the instructions file, commit messages, an issue thread — with the path and how many ## Records found one row each: file · Status · does its subject still exist · the command that showed it ## Supersessions every Supersedes / Superseded-by pair, and whether BOTH ends point at each other. A one-sided link is a finding ## Killed and unrecorded things deleted or reverted in history that no record mentions, with the git command that found each ## Limits every numeric cap found — timeout, retries, concurrency, batch size — with file:line, and whether a measurement sits beside it ## Always-on files every file the harness loads at session start, with its byte count, and the TOTAL. Prompt 2 adds to this and must not blow it up ## Where the records should go the directory prompt 2 will create or reuse, and why that one This file is re-read every time a decision changes; the other three are records of one session. INTERVIEW.md — what you asked and what they said, each marked MEASURED or STATED. TIER.md — the tier, the markers that decided it with their evidence quoted, and what would move each dimension up. Score PERSISTENCE, ACTIVATION and COORDINATION separately and show all three: the profile is the real output and the tier is a compression of it. DECISIONS.md — every recommendation you made in this session, whether it was accepted, and what was chosen instead. A later session reads this to know what has already been settled. --- FINISH Tell them the folder, the four files, and the three things that most change what gets built. Then say exactly this: "Interview complete. Paste prompt 2 from docs.utopiamodels.ai/docs/patterns/decision-discipline and I will build it." Then stop. Do not start building — that is prompt 2, and it reads these files.