How to Write Tasks Your AI Actually Nails

It is 8:40 on a Monday. An ops lead at a twelve-person company types "summarize our pipeline" into an AI assistant connected to HubSpot, Jira, and Stripe. Thirty seconds later she gets four paragraphs about the Jira release pipeline. She wanted the sales pipeline. She rephrases. Now she gets every deal since 2023, including the dead ones. Third try, she gets the right deals but as a wall of prose she cannot paste into the Monday standup doc. By 9:05 she has given up and opened HubSpot herself.

Nothing was wrong with the model. Nothing was wrong with the integration. The task was the problem, and almost everything written about how to instruct AI skips this: the task is the interface. A vague task produces a confident guess. A well-built task produces work you can ship.

This guide is the task-writing craft in five parts: outcome, sources, format, examples, escape hatches. Each part exists because a specific failure mode eats your morning when it is missing. We will rewrite real tasks, badly then well, so you can see the difference line by line.

The task is the spec, and the model will fill every gap you leave

Here is the mental shift that fixes most AI frustration: treat every task like a spec handed to a fast, literal, extremely well-read contractor who started this morning and will not ask clarifying questions unless you invite them to.

A human colleague who gets "summarize our pipeline" asks "sales or engineering?" A model, by default, picks one. It fills every unspecified dimension with a guess: which pipeline, which date range, which definition of "active," which format, which length, which audience. Each guess is individually reasonable. Stacked together, five reasonable guesses produce output that is useless to you specifically.

The corollary is more hopeful than it sounds. Most "the AI is dumb" moments are actually "the task had six open variables" moments. You do not need a better model. You need to close the variables. That is a writing skill, it takes about ninety seconds per task once it is a habit, and it transfers across every tool you will ever use. Teams that skip this stage tend to show up later in the postmortem patterns covered in why AI employees fail: the tooling was fine, the instructions were folklore.

How to instruct AI: the five-part task spec

Every task that consistently lands contains five things. You will not need all five at full strength every time, but when output disappoints, the diagnosis is almost always that one of these was missing.

1. Outcome. What exists when this is done, and who it is for.
2. Sources. Where the truth lives: which tool, which objects, which timeframe.
3. Format. The shape of the output: table, memo, list, draft email, with length caps.
4. Examples. One sample of what good looks like, even a rough one.
5. Escape hatches. What to do when data is missing, ambiguous, or surprising.

A compact version of the ops lead's task, rebuilt:

Build the sales pipeline summary for Monday standup. Source: HubSpot deals, pipeline "New Business," stages Discovery through Contract Sent, updated in the last 14 days. Format: a table with deal name, amount, stage, next step, days since last activity, sorted by amount descending, then two bullets on what changed since last Monday. If a deal has no next step recorded, flag it in a separate list rather than leaving the cell blank. Keep the whole thing under 300 words.

Same model. Same integration. Completely different Monday.

The next five sections take each part in turn, because each one deserves more than a bullet.

Outcome: write the finish line, not the activity

Weak tasks describe activity: "look into churn," "check on the Anderson deal," "research competitors." Strong tasks describe a finish line: what artifact exists at the end, and what decision it feeds.

The test is the phrase "so that." If you cannot complete "so that..." you do not yet know what you are asking for, and the model certainly does not.

• "Look into churn" becomes "List every Stripe subscription canceled in the last 30 days with plan, tenure, and MRR, so that we can decide whether the June pricing change is the cause."
• "Check on the Anderson deal" becomes "Pull the last five touchpoints on the Anderson deal from HubSpot and Gmail, so that I can walk into the 2pm call knowing where negotiations stalled."

Notice what the "so that" clause does mechanically: it lets the model make the remaining hundred micro-decisions correctly. A churn list feeding a pricing decision should surface tenure and plan. The same list feeding a win-back campaign should surface contact emails and cancellation reasons. Identical request, different outcome, different correct answer.

One more habit borrowed from good engineering managers: state the acceptance criteria out loud. "Done means I can paste this into the board deck without editing" is a legitimate line to include in a task. It sounds bossy. It works.

Sources: name where the truth lives

This is the part most people skip, and it is the part that produces the most spectacular failures, because a model with nothing to cite does not stop. It generalizes from patterns, and generalized numbers presented confidently are worse than no answer.

Naming sources means four things, in descending order of importance:

• The tool. "From HubSpot," not "from our CRM stuff." If revenue truth lives in Stripe and pipeline truth lives in HubSpot, say which question goes to which system.
• The object. Deals, not "sales data." Tickets in the SUPPORT project, not "Jira." Invoices, not "billing."
• The fields. If you care about the "Close Date" field and not "Created Date," say so. Half of all wrong-date-range disasters are actually wrong-field disasters.
• The timeframe. "This quarter to date," "last 14 days," "since the March 3 release." Never "recently." The model's "recently" and yours will not match.

Source-naming is also where an orchestration layer earns its keep. When your assistant is actually connected to the systems, "pull the last five touchpoints from HubSpot and Gmail" is an instruction, not a wish. This is why the order in which you connect tools matters more than people expect; there is a sensible sequence in which integrations to connect first. In Skopx, every answer cites the record it came from, which changes your verification cost from "re-run the query myself" to "click the citation." Whatever platform you use, insist on that property: an uncited number from an AI is a rumor.

And when the data genuinely is not connected, say that too: "Using only the attached CSV" is a source instruction. So is "do not use your general knowledge for any figure; if it is not in the data, say so."

Format: decide the shape before the model does

Format failures are the most common and the least discussed, probably because they feel cosmetic. They are not. Output in the wrong shape has to be reworked by a human, which silently deletes the time the task was supposed to save.

Decide three things:

• Structure. Table, bulleted list, memo, draft email, JSON. If it is going into a spreadsheet, ask for a table with named columns. If it is going to a person, ask for a memo with a one-line summary on top.
• Length. Models pad by default. "Under 200 words" and "no more than 10 rows" are load-bearing constraints. A useful rule: cap length at what the reader will actually read, not what the topic could support.
• Audience and register. "For the board" and "for the engineering channel" produce different vocabulary from the same facts. Say which.

A format line costs you ten words: "Format: table with columns X, Y, Z, max 10 rows, sorted by Y descending." It saves you the fifteen minutes of restructuring that you would otherwise do by hand at 8:55 while the standup starts without you.

Examples: one sample beats three paragraphs of description

If you have ever tried to describe your team's weekly update format in words, you know the pain: "sort of casual but with numbers up top, and we bold the blockers..." Stop describing. Paste last week's update and write "match this structure and tone."

Examples work because they close dozens of small variables at once: heading style, sentence length, how numbers are presented, whether bullets end with periods. Three ways to use them, cheapest first:

• Paste a previous good output. The single highest-leverage move in this entire guide. One real sample outperforms any style description you will write.
• Sketch a skeleton. If no sample exists, type the shape: "Line 1: metric and delta. Lines 2-4: top three changes, one line each. Final line: the one thing that needs a decision."
• Show a bad example. "Do not do this" plus a pasted example of the failure is remarkably effective when a model keeps making the same stylistic mistake.

Examples matter double for anything customer-facing. A follow-up email drafted "in a friendly professional tone" is generic by definition. A follow-up email drafted to match three of your actual sent emails sounds like you.

Escape hatches: tell it what to do when the world is messy

This is the expert move, the one that separates people who trust their AI's output from people who spot-check everything forever. An escape hatch is a pre-written instruction for the moment the task meets messy reality: missing fields, ambiguous matches, surprising results, or an action with consequences.

Without escape hatches, models do the worst possible thing: they proceed smoothly. Blank close date? Guess one. Two contacts named Chen? Pick one. Refund larger than expected? Report it without comment. The output looks finished, which is exactly what makes it dangerous.

The four escape hatches worth writing every time:

• Missing data: "If a deal has no close date, put it in a separate 'needs data' list. Never infer a date."
• Ambiguity: "If more than one record matches, stop and show me the candidates instead of choosing."
• Surprises: "If any single refund exceeds $500, call it out at the top rather than burying it in the total."
• Consequence: "Draft the email but do not send it. I will review." Anything that touches a customer, money, or a production system gets a human gate. Where exactly to draw that line is its own decision, and when to let AI act without review walks through it; the short version is that read-and-report tasks earn autonomy long before write-and-send tasks do.

Escape hatches feel pessimistic to write. They are the opposite: they are what makes it safe to hand the task over at all.

Before and after: task rewrites across four real tools

Here is the five-part spec applied to everyday tasks. The middle column is the important one: not just that the vague version fails, but the specific way it fails, because you will recognize these failures from your own history.

Read the rewrites again and count the parts. Each one has an outcome, named sources, a format, an example or explicit exclusion, and at least one escape hatch. None is longer than a text message you have sent this week.

How to instruct AI when the first answer misses

Even a good task sometimes lands at 80 percent. What you do next determines whether you get to 100 percent in one move or spiral through six.

The core discipline: change one variable, and name the delta. "Make it better" re-rolls the dice. "Keep everything, but cut rows under $5k and tighten the bullets to one line each" is a surgical edit. Treat the second prompt like a code review comment, not a new assignment.

Three moves that consistently work:

• Diagnose which of the five parts failed. Wrong data is a sources problem. Right data, wrong shape is a format problem. Right shape, wrong judgment calls means a missing example or escape hatch. Fix the part, not the whole task.
• Ask the model what it assumed. "List the assumptions you made" surfaces the guessed variables in ten seconds, and each assumption is a line you now add to the task.
• Save the fixed version. The second-worst outcome is a failed task. The worst is a task you fixed and then retyped from memory next week, wrong. When a task works, it stops being a prompt and becomes an asset.

That last move is the bridge from craft to system. Your best task specs deserve to live somewhere durable, which is the entire argument of the AI runbook guide: written, versioned instructions beat tribal knowledge for AI exactly as they do for humans.

From one-off tasks to standing instructions

Once a task recurs, typing it weekly is waste. The Monday pipeline summary, the release notes ritual, the billing check: these want to become standing instructions that run on a schedule with the spec baked in.

This is where the five parts pay a second dividend, because a well-specified task is already an automation spec. In Skopx, you can type that finished pipeline task as one sentence and it assembles into a workflow on a canvas that runs every Monday morning, with retries, versions, and a full run history, so the escape hatches you wrote ("flag deals missing a next step") execute at 7am whether or not you remembered to ask. The same logic powers its morning briefing: a standing instruction to report what moved across your tools and what is slipping, rather than a fresh prompt every day.

Two cautions from teams that have done this:

• Automate the task only after it has succeeded manually three or more times. Scheduling a task that has never nailed the outcome just delivers disappointment punctually.
• Keep the human gate on consequences. Scheduled reading and reporting is safe. Scheduled sending and changing should stay approval-gated far longer than feels necessary. Your first week of working this way sets those habits, and there is a day-by-day shape for it in the first week with an AI coworker.

FAQ: how to instruct AI, common questions

How long should a task be?

As long as it needs to close the open variables, and no longer. Most excellent tasks are three to six sentences. Under one sentence, you are almost certainly leaving outcome or sources open. Over a paragraph, check whether you are describing style in words that one pasted example would replace. Length is not the goal; closed variables are.

Should I write tasks differently for different models?

Far less than vendors imply. The five parts, outcome, sources, format, examples, escape hatches, are model-agnostic because they address ambiguity, and every model guesses when facing ambiguity. Stronger models recover from vaguer tasks more gracefully, but "the model can survive my vagueness" is a poor operating principle, because you cannot tell a graceful guess from the truth without checking.

Is it worth this effort for a task I will run once?

For a genuinely one-off, low-stakes question, no. Ask casually and iterate. The craft pays off on anything recurring, anything feeding a decision, anything customer-facing, or anything touching money. In practice that describes most work tasks people delegate. A useful filter: if a wrong answer would cost you more than the ninety seconds of specification, specify.

How do I stop the AI from making up numbers?

Three layers. First, name the source so there is real data to use. Second, add the escape hatch "if the data does not contain this, say so; never estimate." Third, prefer platforms where answers carry citations to the underlying record, so fabrication is visible on contact. An uncited figure should be treated as unverified by default, no matter how plausible it reads.

Who on the team should own task-writing?

Everyone writes tasks; someone should own the library. The failure mode is twelve people maintaining twelve private variants of the pipeline summary, each subtly different. Treat proven task specs like shared code: reviewed, versioned, findable. Teams that manage this well tend to manage AI like a team member, with the same onboarding docs and feedback loops they would give a hire.

What is the single highest-leverage change if I only make one?

Paste an example of what good looks like. It closes more open variables per second of your effort than any other move in this guide. Second place: the "so that" clause on the outcome. Third: the missing-data escape hatch.

The ninety-second habit

Task-writing looks like overhead the first week and like a superpower the first month. The five parts are not a framework to memorize; they are the five questions a careful contractor would ask you anyway. Outcome: what exists when this is done? Sources: where does the truth live? Format: what shape does it take? Examples: what does good look like? Escape hatches: what do I do when it gets weird?

Answer them before the model has to guess, and the model mostly stops guessing. Start with one recurring task this week, rebuild it with the five parts, run it three times, then make it a standing instruction. The compounding starts immediately, and unlike most productivity advice, this one survives contact with Monday morning.