Better Prompts Start With Better Problems

I don't always want the same thing from an AI conversation. Sometimes I need an answer, while other times I need ideas, a challenge to an assumption, an examination of edge cases, or help understanding a problem before deciding what to do. Advice about prompt structure and wording is useful only if it helps the model do the kind of work I actually need.

Structure helps when it clarifies that objective. Asking a model to compare options, interview me, or challenge my preferred approach gives it a different job from simply producing an answer, so those requests shouldn't all use the same instructions.

The distinction becomes more important with agents. A chat prompt shapes how a large language model (LLM) approaches a question or produces an output; an agent prompt can also influence its behavior, tools, actions, and decisions about when to involve a person.

In either case, I want the instructions to support the thinking or behavior the problem calls for, then evaluate whether the result accomplished that purpose. Finding a collection of supposedly magical phrases doesn't give me the same basis for judgment.

Start with the outcome you want

Consider a simple prompt:

Review this idea and tell me what you think.

That request leaves the model to infer what would make its response useful. Encouragement, feasibility, alternatives, risks, contradictory evidence, product opportunities, and technical limitations are different kinds of assessment, and the model's interpretation may not match the help you need.

Compare that with:

I am considering automating lead qualification for a small service business. The goal is to reduce manual review without incorrectly rejecting potentially valuable inquiries. Before recommending an approach, identify the assumptions in my current framing, ask about information that would materially affect the decision, and identify edge cases where automated qualification could produce the wrong outcome.

The second prompt establishes the problem, desired outcome, constraint, and kind of thinking I want. Its length isn't the advantage; the additional information gives the conversation direction.

Context changes the quality of the reasoning

A model working without relevant context has to ask for it, work around the gap, or make assumptions. Including information that could change the recommendation gives it a better basis for reasoning.

Asking how a nonprofit should redesign its website may produce reasonable general advice. Explaining its small team, limited technical capacity, related digital properties, budget, existing WordPress site, and goal of helping visitors reach services makes the recommendation more specific to the operating environment.

The same principle applies to business strategy, software development, marketing, automation, product decisions, and many other kinds of work. Useful context might include the audience, existing systems, available resources, constraints, evidence already collected, previous decisions, or approaches that have already been attempted.

More context isn't automatically better. A large amount of irrelevant information can make a prompt harder to reason through rather than easier. The goal is to provide the information that could materially change the answer.

Decide what kind of thinking you need

One of the reasons I find LLMs useful is that I can ask the same system to approach a problem in very different ways. The prompt should make that intention clear.

Sometimes I'm looking for generative thinking. I want possibilities rather than a single recommendation, so I might ask the model to identify alternative ways of framing a problem, make connections to adjacent industries, propose approaches based on different assumptions, or identify opportunities that aren't obvious from the current solution.

For example:

Generate several fundamentally different ways a small nonprofit could improve how people find services online. Do not limit the ideas to redesigning the website. Consider content, navigation, search, partnerships, communication channels, and changes to the service experience itself.

That instruction opens up alternative ways to address the problem instead of limiting the model to improving the solution I've already assumed.

Other times I want critical thinking. I already have an idea and want the model to challenge it rather than help me defend it. In that situation, I might ask:

Assume my preferred recommendation may be wrong. Identify the strongest assumptions supporting it, explain which have weak evidence, develop the strongest reasonable argument against the recommendation, and tell me what additional evidence would most likely change the decision.

This is useful because conversational AI can otherwise feel cooperative in ways that aren't always helpful. If I provide a strongly framed argument and simply ask whether it makes sense, the model may work within the framing I provided. If I want resistance, I should make that objective clear.

A third mode is edge-case thinking. Here I'm less interested in whether an idea works under normal circumstances and more interested in where it could fail:

Evaluate this workflow outside the happy path. Look for missing information, unusual user behavior, conflicting rules, integration failures, permission problems, security or privacy concerns, incorrect assumptions, and situations where the automated action could create a worse outcome than doing nothing.

These modes produce different kinds of value. I choose among them based on whether the problem needs exploration, challenge, or an examination of possible failures.

Interview the problem before solving it

When I don't yet understand the problem well enough, I often ask the model to interview me before making a recommendation.

One framework I use to create that structure is CRIT: Context, Role, Interview, Task. Context explains the situation and what is already known. Role gives the model a useful perspective from which to examine the problem. Interview instructs it to ask questions that could materially change its understanding. Task describes what should happen once enough information has been gathered.

The interview step is particularly useful because people naturally leave out information they already know. We understand our own business, customers, project history, and constraints, so we may not recognize which pieces of that context are missing from the prompt.

Instead of asking:

Create a plan for improving our lead management process.

I could say:

We are a small service business looking to improve how new inquiries are qualified, routed, and followed up. Act as a product and operations partner. Before proposing a solution, interview me about our current process, lead sources, volume, qualification criteria, systems, ownership, exceptions, and where leads are currently being lost. Once you have enough information, recommend the smallest set of changes likely to improve response time and follow-through.

The conversation then becomes part of discovery. CRIT helps create space for identifying missing context before moving from an incomplete problem statement to a polished answer, but I wouldn't treat it or any prompting framework as a universal requirement.

A role should provide perspective, not theater

"Act as an expert" appears in many prompt templates, but a role is most useful when it changes how the problem should be examined.

Telling a model to "act as a world-class genius product strategist" adds very little useful information. Telling it to evaluate a decision from the perspective of someone responsible for security, finance, customer support, accessibility, or operations can expose considerations that were missing from the original framing.

Roles can also be combined carefully when the problem crosses disciplines:

Evaluate this proposed customer onboarding workflow from three perspectives: the customer trying to complete it, the operations employee responsible for exceptions, and the engineer responsible for maintaining the integration.

Those perspectives are useful because they make different considerations visible. An impressive title assigned to the model doesn't establish that it will examine the problem well.

Agent prompts have a different job

An agent's instructions extend beyond how to answer a question because its tools let it act. Searching information, retrieving customer records, sending messages, updating a database, triggering workflows, and delegating work make the prompt part of the system's operating logic.

I find it useful to think about an agent prompt through several components:

Role → Goal → Context → Responsibilities → Tools → Decision boundaries → Escalation → Completion

The role establishes what the agent is responsible for within the larger system, while the goal defines the outcome it should work toward. Context explains the operating environment and relevant rules, and responsibilities describe the work it is expected to perform.

The remaining components become particularly important once the agent can take action. Tools define what the agent can actually do. Decision boundaries establish which choices it can make independently. Escalation defines when it should stop, ask for help, or hand the work to another person or system. Completion describes what needs to be true before the task should be considered finished.

A customer support agent, for example, shouldn't simply receive an instruction to "help customers." A more useful definition might establish that its goal is to resolve routine questions using approved resources while ensuring account-specific, sensitive, uncertain, or policy-exception requests reach the appropriate person. It may be allowed to search a knowledge base, retrieve limited account information, create a support ticket, and route the request.

The instructions should explain when each tool is appropriate and when the agent shouldn't act. As actions become more consequential, both the boundaries and the technical controls around them need more care.

Tell the agent when not to act independently

Escalation can be the appropriate result rather than a failure. A support agent might answer a routine question using an established resource but collect information and involve a person when an unusual billing issue requires a policy exception.

In both cases, success depends on recognizing the appropriate path, not on resolving every request independently.

An agent prompt should therefore describe circumstances where independent action is undesirable. Low confidence, missing information, conflicting data, sensitive information, unusual requests, policy exceptions, high-impact actions, or repeated customer frustration might all justify escalation depending on the workflow.

The objective is not maximum autonomy. It's authority that fits the decision and its consequences.

Tools should be connected to decisions

Providing an agent with a long list of tools isn't enough. The system needs enough information to understand what each tool is for, when it should be used, and what limitations apply.

Imagine an agent that can search a help center, look up a customer account, issue a refund, create a support ticket, and send an email. Those tools carry very different levels of consequence. Searching documentation may be relatively low risk, while issuing a refund changes something meaningful in the business.

The instructions and technical controls around those actions should reflect the difference. A useful design might allow documentation search freely, permit customer lookup only when necessary to resolve an account-specific question, and require human approval before a financial action occurs.

This is part of prompt design, but it's also system design. Permissions, tool configuration, workflow logic, and technical controls should reinforce the instructions rather than depending on a paragraph of text to prevent every undesirable action.

Check performance across different situations

One impressive response gives us little evidence of how reliably a prompt will perform. If it'll be used repeatedly, I want to test it across the situations it's likely to encounter.

For a conversational prompt, I'd examine incomplete information, evidence that conflicts with my preferred conclusion, a deliberately weak assumption, and problems with several reasonable interpretations. The response should distinguish evidence from inference, identify gaps, challenge unsupported assumptions, and adjust when context changes.

For an agent, evaluation becomes more behavioral. I'd test routine cases, ambiguous cases, situations where a tool should be used, situations where the same tool shouldn't be used, requests that require escalation, and cases where the user's requested action conflicts with the agent's boundaries.

For agents, I also examine whether the system interpreted the objective, chose the right tool, used information appropriately, recognized uncertainty, escalated when needed, and stopped once the outcome was reached. A response that sounds intelligent doesn't establish that those behaviors were correct.

Evaluate against the outcome you defined

The appropriate measures depend on what the prompt or agent was designed to accomplish. For a research prompt, useful criteria might include factual accuracy, source quality, completeness, identification of uncertainty, and whether important counterarguments were considered. For an ideation prompt, novelty and range may matter more because five variations of essentially the same idea don't provide much exploration.

For critical analysis, I'd care about whether the response surfaced assumptions I had missed, distinguished strong evidence from weak evidence, and identified information that could change the decision. For an operational agent, the measures become closer to product or workflow metrics: successful completion, incorrect actions, escalation accuracy, human corrections, time saved, cost per completed task, customer outcomes, and consistency across similar situations.

Evaluation comes back to the original problem: if I can't explain what better looks like, I can't assess whether the prompt helped.

Improve the problem before endlessly tuning the wording

There's value in refining prompts. Small changes to instructions, examples, context, output structure, and tool descriptions can materially improve performance. There's also a point where repeatedly adjusting the wording becomes a distraction from a poorly defined problem.

If an agent keeps making inconsistent routing decisions, the answer may not be another sentence in the prompt. The business may have unclear routing rules. If an LLM keeps giving generic recommendations, the missing ingredient may be customer evidence rather than a better role description. If an automation can't reliably determine when to escalate, the organization may not have agreed on what actually requires human judgment.

AI can expose these gaps because it forces us to describe processes and decisions that people may previously have handled through experience, intuition, or informal communication. That can be useful even before the model produces anything because writing a good prompt requires us to clarify what we know, what we want, which constraints matter, and what we expect to happen next.

Better prompting is better problem definition

I've found it more useful to understand the conditions a model needs for good work than to keep looking for a perfect prompt. That includes the information it needs, the outcome I'm asking for, whether I want exploration or challenge, the assumptions it should examine, and what it should do with missing context.

For agents, that extends to responsibility, tools, decision authority, escalation, and completion. Defining those elements gives me a basis for checking whether the system produced the outcome I wanted.

A prompt can't indefinitely compensate for an unclear objective, a poorly understood process, or missing information. Defining the problem well gives the model something more useful to work with and gives us a clearer way to assess its response.