Bidirectional Prompting

A plan becomes more precise when you question the agent's assumptions and let it question yours. You know what you want the software to do, but you may leave parts unstated. The agent can inspect the implementation, but it still needs your decisions about behavior that the code cannot settle.

Bidirectional prompting is a conversation in which you and the agent ask questions to resolve missing information before acting on it. Questions can uncover a requirement you forgot to mention or confirm that an existing approach will work. Record what you learn so the implementation can use it.

Give The Agent Enough To Ask Useful Questions

Continue with the pipeline editor from Robust Planning. You have described saving and reopening ordered steps. Before the agent implements that behavior, ask it to inspect the existing editor and storage code. Then have it identify decisions that would change its approach.

This gives the agent a task, a place to investigate, and a reason to ask. It can look up how pipelines are currently stored, but whether two of them may share a name is a product decision. When no existing requirement settles that, the agent should bring the question back to you.

Answer The Decision Behind The Question

Suppose the agent asks: “Should saving a pipeline with an existing name overwrite it?” Answering “yes” may appear sufficient but leaves the meaning of identity unclear. Renaming one pipeline could accidentally overwrite another if the implementation uses the name as its lookup key.

You could decide that editing an existing pipeline updates it by a stable identifier, while the editor rejects a new pipeline with a duplicate name. Ask the agent to describe how that rule affects saving and renaming. If the current storage format has no identifier, that becomes a specific change to discuss in the plan.

Deal with questions in small groups when later answers depend on earlier ones. Choosing local storage rather than shared storage changes the relevance of questions about concurrent editing. Asking every conceivable question at the start wastes time on branches you may never build.

Ask For Evidence Behind Recommendations

The conversation must also test what the agent proposes. If it recommends a new storage service, ask which requirement needs it and what prevents the existing storage code from meeting that requirement. Have it point to the limitation in the code or demonstrate it with a small test.

Useful questions make the answer inspectable:

• Which existing function would you reuse and where is it called today?
• What happens to the steps in the editor if the save operation fails?
• Which part of this recommendation depends on an assumption we have not checked?
• What observation would make you change the proposed approach?

Avoid asking for reassurance about a decision you have already praised. “This design is solid, right?” gives the agent little reason to investigate its weaknesses. Ask it to compare the proposal with the requirements and identify supported problems. Allow it to report that it found none.

Explanations still need checking. An agent can give a convincing account of why an API behaves a certain way while describing an API that does not exist. When the answer depends on implementation details, follow the cited code or run the proposed check.

Keep The Decisions After The Conversation

Once you have resolved a question, put the answer in the plan. A later session may otherwise reopen it or act on an earlier suggestion. Ask the agent to separate agreed behavior from rejected alternatives and unresolved questions. Then read that record yourself.

If the conversation has accumulated unrelated debugging or abandoned designs, prepare a handoff before starting a fresh session. Preserve the current decisions and relevant file paths. Keep the observed results and the next unresolved task too. Check the handoff against the files on disk; a summary of the conversation can describe an earlier version of the code.

Move to implementation when the remaining questions no longer change the next step. If a question requires seeing the feature run, write down what the experiment should tell you and build that small part. Further discussion alone cannot settle how an interaction feels or whether an integration works.

Exercise 1: Make The Agent Ask First

Choose a feature that has not been built yet in a working project. Tell an agent to read the relevant code, list every question whose answer would change its approach, and wait for answers before it plans or edits anything. Answer each question with the decision and the reason for it, since a bare yes leaves the agent to guess what the yes covers.

Then reverse the direction and pick one of the agent's recommendations and ask which requirement needs it and where in the code the limitation appears. Write the settled decisions into a short record, with rejected options kept in a separate section. A fresh session given only that record should be able to start the work without asking any of the same questions again.

September, 2026