A tentative answer can become a premise for the work that follows. AI-generated conceptual illustration for Renaissance Solutions.

The question I wasn’t ready to answer

An agent — an AI that can build as well as chat — asked a fair question. The kind a careful teammate asks before building the next piece. I did not have an answer. But I was in the habit of answering questions so that the work could continue.

So what was I supposed to do when the question arrived before I was ready to decide? The easy move, and sometimes the dangerous one, was to answer anyway.

A casual answer can become a premise

Once you answer, the agent can treat the reply as a fact. Names, files, and later choices stack on it.

If you are watching, you may notice the friction and correct course. That does not make the original answer safer. The agent may already have built substantially on it. Leave it overnight and the same quick reply can become a load-bearing premise, with no one there to remember that it began as a guess. You did not hold a design review. You answered a question so the agent could continue.

“I don’t know yet”

I tried a different reply: “I don’t know yet. Let's defer this decision if we can.”

Sometimes the agent obliged, and sometimes the agent stopped and explained why the next step needed an answer. Both responses are useful. If the decision is needed, I can work with the agent to understand what it blocks and the risks of choosing now. If it is not needed, we can move on and return to the decision when we know more.

Not knowing yet is itself useful context. It tells both the human and the agent that the decision is not ready to be treated as settled.

This isn’t a new problem

People already had words for when to commit. Four old ideas are enough. None of them was written for agents, and they are not the same idea.

Last responsible moment. Wait to commit until waiting would wipe out a real alternative. Do not wait past that, or the choice happens with no one owning it. And do not confuse waiting with stopping the learning.123

One-way and two-way doors. A two-way door is a choice you can undo. Those should still be made quickly. A one-way door is hard to undo, so it deserves more care. Most decisions, in Jeff Bezos’s 2015 letter, are the kind you can undo, and treating them as if you cannot makes an organization slow.4

Real options. Keeping a choice open has a cost. Do it only when you know why.567

Architecture decision records. An architecture decision record is a short note of a choice already made: what you chose, and what follows.8 The note is not a reason to refuse the decision. The five names later in this essay are ours, not that format.9

What AI changes

The principles above are old. Coding agents change the cost of a question, and how much work can follow an answer.

People already built on a casual answer. What changed is how many forks show up at once, and how much work can follow one reply. Each fork can sound reasonable. Conversation trains you to answer someone who is waiting, so you answer.

Then the agent can build downstream of whatever you said. The new pressure is not the two-way door. It is answering before the question is even a door, or letting an agent pour work through a casual reply. That sequence is an observation from use. It is not a study. No count of rework sits behind it.

Official Codex guidance does one narrow thing here. In plan mode, Codex gathers context, asks clarifying questions, and builds a plan before implementation.10 That tells the agent to ask. It does not tell you to defer, and it does not say “I don’t know yet” is a valid reply. The open question is what you do when the decision is not ripe.

As agents get better at asking the right questions, we need to get better at deciding which questions not to answer yet.

Sometimes “I don’t know” is more context

Silence is not preference. If you skip the question, the agent may defer, state the default it proposes to use, offer a provisional choice, or come back because something real is blocked.

The missing information may not exist yet. The next step can be what creates it: a small spike, a look at real data, a conversation you have not had. In practice, “I don’t know yet” has been more honest than a made-up preference, and more useful than a blank. It is context. It tells the agent the fact is not in hand.

When should we decide?

This is the test. Ask four questions.

  • Do we need an answer for the next useful step? Sometimes we need a decision to continue. If so, the next question is whether a provisional, reversible choice is enough, or whether the work has reached a decision we need to make carefully.
  • Will that step teach something that could change the decision? Sometimes taking the next step without settling the larger question is exactly how you learn enough to settle it.
  • How expensive is the choice to reverse? Since some decisions become more difficult to reverse over time, we need to include reversibility when making or deferring decisions.
  • What does waiting cost? Deferring a decision can also create risk, friction, or expense. Waiting to choose a name may cost almost nothing. Waiting to decide how customer data must be protected may prevent other work from proceeding safely.

Then sort the question. Four rows, not a new method.

  • Necessary, and cheap to reverse. Decide. A reversible choice you already understand should not wait. Type 2 decisions, in Bezos’s letter, can and should be made quickly.4
  • Necessary, and expensive to reverse. Investigate, then decide. Do the learning that could change the answer. Do not treat a hard-to-undo choice as small talk.
  • Not necessary, and low consequences. Default, or defer. Take the ordinary path so work can move, and say that you did. Or leave it, if even a default would be noise.
  • Not necessary, and consequential. Defer on purpose. Do not let a side question become the premise of the next chunk of work.

Decide when the next step needs it. Otherwise, consider what you can learn, what reversal would cost, and what waiting would cost. Created with Codex for Renaissance Solutions.

Deferral is not automatically better. The aim is the right amount of room to change your mind, not the maximum. Waiting is not the same as deciding at the last responsible moment, and a decision made by default, with no one owning it, is generally a poor way to decide.1 An option also expires.7 Waiting until you can no longer change course is already too late. That warning is against waiting until you cannot adapt. It is not against a choice you have named as deferred.

Five useful decision states

Five names for where a choice sits. A short list we are using, not a second framework, and not the status list on an architecture decision record.89

  • DECIDED. We chose. Later work may rely on it.
  • PROVISIONAL. We chose for now, knowing what could cause us to revisit the choice. Later work may rely on it, but should not mistake it for final.
  • DEFAULTED. We took the ordinary or simplest reasonable option because the choice did not justify more attention yet. Name that, or a later reader may mistake it for DECIDED. Unnamed guesses and defaults can get saved as DECIDED.
  • DEFERRED. We looked. The next step does not need an answer. We are not deciding yet.
  • BLOCKED. The next step cannot proceed without an answer, and we do not have one. That is a stop, not a style.

Say the state, including to the agent. An unnamed guess can get saved as DECIDED.

Make the AI help decide whether to decide

You can ask the agent to help sort the question. You keep the judgment. A reply worth reusing:

I don’t know yet. Defer this decision if possible. If you need a decision to proceed, explain what it blocks, whether a provisional choice is sufficient, and how difficult the choice will be to reverse.

The agent may defer, take a stated default, offer a provisional choice, or come back because something real is blocked. You still accept or refuse that. The prompt exists so a reasonable question does not silently become a premise.

Don’t build a drawbridge for every two-way door

Keeping an option open is not a justification for designing every possible future. Being undecided does not justify adding abstraction just in case.

For instance, we might create something that needs a database. Before we finish prototyping and experimenting, we might lack enough information to choose among the options. Choosing SQLite for initial experiments and prototyping because it is sufficient for the experiment can be a provisional decision. That does not mean we should also build an abstraction layer capable of swapping in every database we might someday choose.

A provisional choice does not require a provisional architecture.

Invest effort in preserving an option only when it is worth keeping. Poppendieck noted that options are not free and delay often carries a cost.6 Matts and Maassen observed that flexibility costs more.7 A provisional choice is one you can revisit. A provisional architecture imposes a toll on later changes, for a door you may never use. Two-way doors still require a decision. You do not build a drawbridge for each one.

The overnight test

Before you answer, imagine about eight hours of work downstream of that answer.

If you would not be comfortable meeting that work in the morning, the best reply may be: “I don’t know yet.”

This isn’t a measurement of agent capability. It’s a test of whether you’re comfortable letting the answer become a premise while you’re away.

I don’t know. Do you need to?

I expect better tools will ask more questions, and get better at turning answers into working software. That is a reason to use them. It also moves part of the skill back to you.

You get better at recognizing when an answer is needed, when a provisional answer is enough, and when the most accurate answer is still “I don’t know yet.”

Neither early nor late is a virtue. A reversible choice you already understand should still be made quickly.4 A fact you do not have should not be invented so the agent can stay busy.

When the question arrives, the smaller question is often the right one.

I don’t know. Do you need to?

Footnotes

  1. Mary Poppendieck and Tom Poppendieck, Lean Software Development: An Agile Toolkit (Addison-Wesley Professional, 2003), chapter 3. The authors describe the “last responsible moment” as the point at which failing to make a decision eliminates an important alternative. They distinguish deliberate delay from procrastination and argue that delaying commitment requires active learning. https://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf ↩ ↩2

  2. Lean Construction Institute, “Lean Construction Glossary,” entry for “Last Responsible Moment (LRM).” The glossary defines it as the point at which the cost of delaying a decision exceeds the benefit of delay, or when failing to decide eliminates an important alternative. https://leanconstruction.org/glossary/ ↩

  3. Katherine Radeka, “Why Pushing Decisions Later, Gets You There Faster,” Rapid Learning Cycles Institute, March 16, 2021. Radeka argues that delaying major decisions does not mean delaying the work needed to make them: learning should proceed rapidly while commitment waits for useful knowledge. https://knowledge.rapidlearningcycles.com/2021/03/16/why-pushing-decisions-later-gets-you-there-faster-to-get-there-faster/ ↩

  4. Jeff Bezos, “2015 Letter to Shareholders,” Amazon.com, Inc., filed with the U.S. Securities and Exchange Commission, April 5, 2016. Bezos distinguishes consequential, difficult-to-reverse “Type 1” decisions from changeable, reversible “Type 2” decisions, arguing that the latter “can and should be made quickly.” https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm ↩ ↩2 ↩3

  5. Stewart C. Myers, “Determinants of Corporate Borrowing,” Journal of Financial Economics 5 (1977): 147–175. Myers describes investment opportunities as “real options,” providing an early foundation for thinking about the economic value of preserving choices under uncertainty. The paper concerns corporate finance rather than software design. https://www.liuyanecon.com/wp-content/uploads/Myers-1977.pdf ↩

  6. Poppendieck and Poppendieck, Lean Software Development, chapter 3. Applying real-options thinking to product development, the authors argue that delaying irreversible decisions while uncertainty is reduced can have economic value, while also warning that options are not free and delaying decisions can itself carry a cost. https://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf ↩ ↩2

  7. ↩ ↩2 ↩3

  8. Michael Nygard, “Documenting Architecture Decisions,” November 15, 2011. Nygard proposes lightweight Architecture Decision Records containing a decision’s title, context, decision, status, and consequences so that later readers can understand why an architecturally significant choice was made. https://www.cognitect.com/blog/2011/11/15/documenting-architecture-decisions ↩ ↩2

  9. Martin Fowler, “Architecture Decision Record,” March 24, 2026. Fowler describes an ADR as “a short document that captures and explains a single decision,” including its context and significant ramifications. He credits Michael Nygard with coining the term Architecture Decision Record in 2011 while noting that decision logs themselves predate the format. https://martinfowler.com/bliki/ArchitectureDecisionRecord.html ↩ ↩2

  10. OpenAI, “Best Practices,” ChatGPT Learn, accessed October 4, 2026. The Codex guidance describes Plan mode as allowing Codex to gather context, ask clarifying questions, and build a stronger plan before implementation. The guidance supports asking clarifying questions but does not prescribe how a user should handle a legitimate decision that is not yet ready to be made. https://learn.chatgpt.com/guides/best-practices ↩