A Small Tip for Using AI Agents: Don’t Ask for the Plan Too Soon

Recently, while using AI agents to think through product and technical designs, I found a small but useful habit.

It is not a complicated prompt trick. It is much simpler than that.

Instead of asking the agent to immediately produce a plan, I first ask it to understand my requirement. If anything is unclear, I ask it to question me before writing the final proposal.

In other words:

Don’t generate the solution yet. First understand what I want. If anything is unclear, ask me questions. After we clarify the details, then give me the plan.

This sounds ordinary, but it has improved the quality of the output quite a lot.

1. The problem with asking for a plan too early

I used to work with agents in a very direct way.

I would describe a rough idea and say something like:

Help me design a solution.

The agent would usually respond quickly with a complete-looking proposal. The structure was often clean. The logic looked reasonable. Sometimes the answer even felt quite professional.

But the problem was that the proposal did not always match what I actually wanted.

That was not necessarily because the agent was bad. More often, it was because my original input was incomplete.

Many important details were still only in my head: background context, constraints, preferences, priorities, and edge cases. If I did not say them clearly, the agent had to fill in the gaps by itself.

The more confidently it filled in those gaps, the more complete the plan looked. But if the initial understanding was slightly off, the final plan could drift in the wrong direction.

2. Let the agent ask first

So I started changing the flow.

When I had a rough requirement, I would add one instruction before asking for the final answer:

Don’t rush to give me a proposal.

First understand my requirement.

If anything is unclear, ask me questions.

After I answer, then produce the final plan.

This changed the whole interaction.

The agent no longer jumped straight into “answer mode”. Instead, it started asking clarifying questions.

It asked about goals, boundaries, priorities, first-version scope, exceptional cases, when to involve the user, which actions could be automated, and which actions must stop for confirmation.

The screenshot below is an example. The initial direction was still vague, but the agent kept asking about boundaries, permissions, login state, device selection, failure handling, and other details before writing the plan.

3. Questions reveal hidden requirements

This process was useful because many of those questions were things I had not fully thought through myself.

Once the agent asked them, I had to turn my implicit assumptions into explicit answers.

For example:

• If login, verification code, or CAPTCHA appears, should the agent handle it automatically or ask the user?
• If the device is offline, should the task fail, notify the user, or fall back to another path?
• If multiple browser tabs are available, which one should be preferred?
• Which actions can be automated, and which ones require user confirmation?
• Which parts belong to the first version, and which should be left for later?

These may look like small details, but they often determine whether a design is actually usable.

A bad proposal is not always caused by poor writing. Very often, it comes from unclear requirements.

After several rounds of questions, the agent had a much better understanding of my preferences, constraints, priorities, and decision rules. At that point, the final plan was no longer based on guessing. It was based on alignment.

The next screenshot shows the result after several rounds of clarification. The scattered answers were turned into a concrete target architecture, component responsibilities, plugin goals, and design boundaries.

4. It is not guessing. It is alignment.

That is the part I find most useful.

The goal is not to make the agent magically guess what I want in one shot. The goal is to use conversation to turn a vague requirement into a clearer design input.

I now think that using agents well is not only about writing better prompts. It is also about designing a better conversation.

If I only say:

Help me write a plan.

The agent may give me something that looks complete but does not fully fit the situation.

But if I say:

First understand my requirement. Ask me anything unclear. Then give me the plan.

The agent behaves more like a collaborator.

It helps me break down the problem, find missing information, confirm boundaries, and only then produce the final result.

This flow is a little slower than asking for an answer directly, but the result is usually much closer to what I need.

5. Where this works well

This habit is especially helpful for complex tasks, such as:

• product design;
• technical architecture;
• automation workflows;
• content strategy;
• tool selection;
• system boundary definition;
• multi-role collaboration processes.

These tasks are rarely clear from one sentence.

The quality of the final plan often depends less on how polished the writing is, and more on whether the problem was clarified first.

6. The workflow I use now

These days, I tend to work with agents like this:

1. Describe the rough direction.
2. Tell the agent not to generate the final plan yet.
3. Ask it to restate its understanding.
4. Let it ask clarifying questions.
5. Answer those questions one by one.
6. After the context is clear, ask it to produce the final proposal.

This is not a grand methodology. It is just a small practical tip.

But it works.

If you want an agent to produce a proposal that better matches your expectations, don’t ask it to answer too soon.

Let it understand you first.

Let it ask questions.

Then ask it to write the plan.

A few extra rounds of clarification can save a lot of time that would otherwise be spent rewriting the wrong proposal.