Who decides: your questions and the agent's
Dennis Zaiser, technical founder
An agent that asks you every question stalls whenever you step away. One that decides everything makes product choices you would never have made, quietly, inside a commit. Most people swing between the two, tightening after a bad surprise and loosening after a slow week. What works better is a line that says which questions are yours and which are the agent's, and a fixed way of handling each kind.
Two kinds of questions
A question is yours when its answer changes something only you can weigh. That covers product scope: what the product does or doesn't do, and for whom. It covers customer-facing behaviour where the choice is one of intent, not implementation. It covers pricing, billing and any cost you pay; the legal stance the business takes; priorities, meaning what is built first, deferred or dropped; and reversing anything you have already decided.
Everything else is technical: architecture, code shape, sequencing, tooling, naming, internal contracts, how the development environment runs. These are the agent's to settle, and asking you about them is a cost, not a courtesy.
A test that sorts most cases: would a customer, an investor or your accountant notice the difference between the options? If yes, the question is probably yours. If only the next developer would notice, it is the agent's.
The boundary that trips people up
The hard cases sit at the edge. Once you have decided a feature, how it is realised is technical, even when it looks like a product detail: the options a field offers, the name of an internal concept, a cap, a line of text only agents read. If the agent brings each of these to you, you get a stream of small questions that each look like yours and together eat the day.
The opposite edge matters as much. Changing something you already decided is always your question, even when it looks technical. An agent that finds a recorded decision in its way raises it; it doesn't route around it.
Technical questions: research, adopt, record
The agent shouldn't ask you a technical question, but it shouldn't simply pick an answer either. A short best-practice pass does better: a separate agent researches the options, with facts from the web where they are needed, weighs the trade-offs and returns one recommendation. The separate agent matters. An agent that has just spent an hour on an approach is a poor judge of whether to keep it. A fresh one, briefed with the question and the constraints but not with the asking agent's preference, gives a read that isn't anchored on the first idea.
The asking agent adopts that recommendation. It departs from it only when it conflicts with a recorded decision or a rule, and at that point the question has turned into a business question and goes to you.
Then it records the verdict and a one-line reason where the work is written down: the plan, the design doc, the decision log. The next agent working in that area reads it there instead of asking again. A small, obvious choice skips the research and is simply made and recorded.
Business questions: one shape, batched
When a question is yours, it should arrive in a shape you can answer in a minute. One or two lines stating the question. Two to four options, the recommended one first. One line per option on what it means for the business. What is blocked until you answer. Any decision already on record that bears on it.
For example: does a free account keep its history after thirty days? Option A, recommended: keep it, since storage costs little and people expect their history to stay. Option B: delete it, which lowers storage cost and gives the paid plan one more reason to exist. Blocked: the cleanup job. Existing decision: none.
Batch them, so you answer five at once instead of being interrupted five times. Meanwhile the agent keeps working on everything that doesn't depend on the answer. A question you can answer with a letter is a question that gets answered.
Smaller now, fuller later: leave a trail
Many answers are “the smaller option for now”: one person before teams, a simple version before scale. Without a trail, the next agent in that area finds the gap and either builds the fuller version unasked or asks the same question again.
So a deferral gets three lines in a tracked record: what is built now, what is deferred and why it waits, and what would trigger a revisit. A one-line comment at the place in the code where it matters names that record. And before planning work in an area, the agent searches the deferred decisions there and either folds them into the work or names them as non-goals, so each deferral stays a conscious choice.
When the agent relays a decision like that, it says so: the answer is “the smaller option for now”, and here is the record that holds the rest.
Where ctxflows fits
In ctxflows, a person decides what is built and whether it was met, and the workflow says where. On the Workflows page, an approval is a node that stops for a person, offers the possible answers and waits; the run costs nothing while it does. An agent the engine started never approves its own work.
Runs & actions gathers every question and approval into one inbox of everything waiting on you, answered in the web app, the assistant or your own agent, and anyone in the project can answer. A question a run raised overnight arrives there in the morning, beside the approvals, in the same shape. Every answer is kept in the history: who decided, when and why. The Roadmap holds priorities as the order of your goals, so “what comes first” is answered once, not per task, and Docs keeps decisions and their reasons on the pages the next task reads.