Conversation Planning

When you ask an AI to 'help me optimise my database', the model must make dozens of assumptions: which database engine, what workload pattern, what scaling constraints, what 'optimise' means in your context. Each assumption it makes silently is a potential misalignment that wastes a follow-up message correcting it. A planned conversation provides this context upfront, letting the model generate relevant responses from the first exchange.

Planning also changes what the model can do. A model that knows your stack, constraints, and goals in the first message can make connections between them — identifying trade-offs and suggesting approaches that consider all factors simultaneously. A model learning these facts across ten messages faces attention dilution as early context competes with later messages within the context window.

The compounding effect is significant. Each well-informed response builds better context for the next question. A planned conversation that establishes the full picture in the first message enables a productive exchange in messages two through five that would take an unplanned conversation ten to fifteen messages to reach — if it gets there at all.

This does not mean over-planning. The goal is to provide enough context for the model to give a useful first response, not to anticipate every possible question. A brief paragraph of context and constraints outperforms both a bare-minimum prompt and a multi-page specification.

A practical framework has four stages. Stage one is context: what you are building, who it is for, and what the current state is. Stage two is constraints: technical limits, budget, timeline, non-negotiable requirements, and known risks. Stage three is exploration: potential approaches, trade-offs to consider, open questions you want the model to help think through. Stage four is implementation: the specific deliverable you need.

Not every conversation needs all four stages. A quick question might only need context and implementation. A strategic discussion might spend most of its time in exploration. The framework is a mental checklist that ensures you do not skip context the model needs to be useful, not a rigid script that must be followed to the letter.

The progression from general to specific also helps the model allocate its reasoning appropriately. When it understands the big picture before diving into details, it makes better trade-off decisions and flags potential issues that a detail-first approach would miss. A model told 'we have a tight budget' in the context stage will weigh cost throughout its recommendations; one told the same thing in a late follow-up will have already made recommendations that ignore cost.

An effective shorthand for planning is the 'context paragraph': a single paragraph at the start of the conversation that covers who you are, what you are working on, what constraints matter, and what output you need. This paragraph takes thirty seconds to write and saves minutes of clarification downstream.

For analytical tasks — data analysis, code review, strategy evaluation — front-load the criteria and standards you want applied. The model needs to know what 'good' looks like before it can evaluate whether something meets that bar. Include your evaluation rubric, your quality standards, or examples of analyses you consider well-done — see this expert prompt teardown for a worked example.

For creative tasks — brainstorming, content creation, design ideation — provide the boundaries but leave the centre open. Too many constraints in a creative conversation produce generic output that satisfies all constraints but inspires none. The planning here is about defining the edges — what it must include, what it must avoid, who the audience is — while leaving room for the model to explore within those bounds.

For multi-step work, the plan should define checkpoints rather than the entire path. Plan the first step in detail, execute it, review the output, then plan the next step based on what you learned. Over-planning complex work before any execution often leads to plans that do not survive contact with reality — the first step's output changes what makes sense for the second step.

For recurring tasks — weekly reports, standard analyses, template-based deliverables — the plan itself can be saved and reused. A well-crafted initial prompt for a recurring task, stored in Claude Projects or as a prompt template, eliminates the planning overhead entirely for subsequent iterations.

The most frequent mistake is providing too little context, not too much. Professionals who are deeply familiar with their domain unconsciously omit context that seems obvious to them but is essential for the model. When a developer asks 'how should I handle the race condition?' without specifying the language, framework, or concurrency model, the model cannot provide specific, actionable guidance. The remedy is to briefly state what you would tell a knowledgeable colleague joining the project for the first time.

Another common mistake is front-loading the solution rather than the problem. Asking 'write me a Redis caching layer' prescribes an implementation before the model understands the problem. Asking 'we have an API that queries a PostgreSQL database on every request, response times are 800ms, and we need them under 200ms' lets the model consider multiple approaches — caching being one option, but query optimisation, connection pooling, or read replicas being others that might be more appropriate.

Skipping the exploration stage is a third pattern that reduces output quality. Jumping directly from context to implementation asks the model to commit to an approach without considering alternatives. Including even a brief exploration step — 'what approaches could solve this, and what are the tradeoffs?' — often reveals a better path than the one you would have prescribed.

Finally, some professionals over-plan in ways that constrain the model's usefulness. A three-page specification pasted into a chat window consumes context window space and often overwhelms the model with details it cannot process effectively in a single pass. The context paragraph approach — concise, prioritised, covering the essentials — consistently outperforms exhaustive specifications.