AI needs instructions, not optimism.

Start with the result, not the prompt

Many people start by asking: What should I type into AI? A better question is: How will I know the result is correct?

Before writing a request, define:

• Who will use the result
• What decision it supports
• What information must be included
• What information must not be included
• How a reviewer will check it

Once those answers exist, the prompt usually becomes much easier to write. A good request often starts as an acceptance test rather than a prompt.

Start with what you would hand to a colleague

If a colleague asked, “What exactly do you need from me?”, could you answer in a sentence? That is usually a better starting point than a long prompt full of adjectives.

“Analyze our project” is open-ended. “Draft a brief for Friday’s project review showing outstanding decisions, their owners and the supporting notes” describes a useful piece of work. It also gives you something concrete to verify when the result comes back.

Most useful requests contain four things

Many effective requests can be reduced to four elements.

• The job: What work needs to be completed?
• The source: What information may be used?
• The audience: Who will consume the result?
• The limit: Where should the task stop?

Consider the difference between “Summarize the project” and “Using only the approved project notes, prepare a one-page sponsor briefing that identifies open decisions, assigned owners and stated dates. Stop after the briefing and list any gaps requiring clarification.” Both requests describe the same topic. Only one describes the actual work.

Separate the job from permission to act

Say whether you want:

• A draft
• A recommendation
• An action

Preparing an email is not permission to send it. Suggesting a CRM correction is not permission to change a record. Identifying a security issue is not permission to modify a policy. Make that distinction explicit whenever the tool can take actions.

Tell the tool which sources it may use, what it should do when information is missing, whether assumptions are allowed and when it should stop. A source reference helps a reviewer locate evidence. It does not replace checking the evidence. Never provide sensitive information to an unapproved service simply to make the request more detailed.

Drafting is not deciding

Many business tasks contain both analysis and judgment. An AI tool may help assemble information, identify gaps, organize findings and prepare draft material. That does not automatically make it the decision-maker. Examples include:

• Drafting an approval request
• Recommending a customer response
• Suggesting a CRM update
• Identifying a possible policy exception

A reviewer still decides whether the recommendation is correct. A useful draft can reduce effort. It does not eliminate accountability.

A request you can adapt

This is not a magic prompt. It is a work instruction. Adjust it to your sources, your audience, your evidence requirements and the authority you want the tool to have. For a simple wording edit, use something much shorter.

Make the request fit the application

Different applications support different kinds of work. The useful lesson is not building a library of impressive prompts. The useful lesson is naming the object being worked on and the change you need.

• Meeting: Ask for decisions, actions and unresolved issues from the supplied notes. Require owner names or dates only when the notes actually contain them.
• Email thread: Separate confirmed decisions from unanswered questions. Draft a response. Keep sending authority separate.
• Workbook: Identify the table, columns and rules defining an item requiring attention. Check calculations against the underlying data.
• Presentation: Specify the audience, the decision they face and the supporting evidence. Do not ask the tool to invent results to improve the story.

If you only need a workbook review, start there. Asking for every available email, meeting and file increases both cost and risk.

More information is not always better

When a result is disappointing, people often provide more files, more emails and more meetings. Additional context can help. It can also introduce:

• Irrelevant information
• Contradictory information
• More review effort
• Additional privacy concerns

Start with the smallest set of approved information required to complete the task. Expand only when necessary. Broad access is not a substitute for understanding which evidence matters.

Avoid prompt inflation

When a result disappoints, the common reaction is to add more adjectives. Words such as comprehensive, detailed, insightful, intelligent, professional and thorough rarely solve the underlying problem. Specific instructions usually work better.

Instead of “Make it more detailed,” try “Include open decisions, decision owners and supporting references.” Instead of “Make it executive-ready,” try “Limit the briefing to one page and focus on risks requiring executive action.” Specific requirements are easier to verify than descriptive language.

When the answer misses, diagnose the miss

Don’t keep saying “try again” without changing anything. Identify the failure first.

• Wrong audience: Show who will read it and what they need to decide.
• Unsupported claim: Point to the claim. Require the supporting source. Remove the statement if evidence does not exist.
• Too much background: Specify finished length, required content, information that must survive the edit and missing context. Add the relevant approved material. Do not simply add every available file.
• Wrong action: Stop the task. Fix the authority problem before continuing.

Change one condition and see whether the result improves. If clearer instructions help, keep them. If the same mistake continues, investigate source quality and tool limitations instead of endlessly expanding the prompt.

Put a limit on the work

For tasks involving searches, investigations or tool calls, specify scope, sources, time period and a stopping condition. Ask the tool to report:

• What it found
• What it could not establish
• What assumptions were required

instead of continuing indefinitely. The time required to review and correct the output is part of the work. Count it.

Test reusability

Before reusing a request, give it to someone else with the same approved inputs. Ask:

• Can they tell what success looks like?
• Can they verify the result?
• Can they identify missing information?
• Can they determine when the task is complete?

If not, the acceptance criteria still need work. A reusable request should make results easier to judge, not merely easier to generate.

Final thought

A useful request should answer five questions:

What work needs to be done? What information may be used? Who is the audience? What authority does the tool have? How will the result be verified?

If those questions are unclear, a longer prompt is unlikely to solve the problem. The goal is not to create elaborate prompts. The goal is to create clear work instructions. AI does not need optimism. It needs a defined task, approved information and a way to judge the result.