Writing a good request

Four things decide whether what comes back is usable: what done looks like, the background it has no way of knowing, the constraints you would complain about if they were broken, and the form you want the work handed back in. A request carrying all four usually comes back finished. A request missing them comes back as a question, or as something plausible that isn’t what you meant.

Say what done looks like

Weak — Look at our churn numbers.

Better — Here is our subscription export for the last six months. Tell me which month cancellations rose most, and what the five largest cancelled accounts had in common. One page. No charts.

The first has no finish line, so anything it produces is arguably correct and probably useless. The second can be checked: you either got the month, the five accounts and the pattern, or you didn’t.

Give the background it cannot look up

It can search and read the open web, read the files you hand it, and work inside the apps you have connected. Gmail, Google Drive, Notion, Slack, GitHub and Airtable are the first-class ones; many others connect by pasting a key.

Everything outside that is invisible to it. Who the reader is. Why the decision went the way it did. What you already tried and rejected. Which of the two spreadsheets is the real one. Two lines of that context prevent most of the rework.

Name the constraints

Weak — Rewrite our onboarding email.

Better — Rewrite our onboarding email. Keep the first sentence exactly as it is. Under 150 words. Don’t mention pricing, and don’t invent customer names. If you need a fact I haven’t given you, stop and ask instead of filling it in.

Constraints in the request are the ones about the work itself. The constraints about how far it may go on its own live in the panel headed What it can use, which applies to the one thing you’re about to send: how much it may do without checking with you (by default it checks before anything leaves the app), a spend limit for that run, and whether to plan the steps first. The composer is also where you choose Auto, which picks the best value for each request, or set it yourself to Fast, Smart or Max — or pick an exact engine.

Ask for the thing, not just the answer

Weak — Find me a venue for the team dinner.

Better — Find three venues in central Lisbon that seat 40 for a dinner in October, each with a private room and a set menu under €60 a head. Cite the page you took each number from. Give it to me as a spreadsheet. If fewer than three meet all of it, say so instead of padding the list.

Name the artefact you want: a spreadsheet, a slide deck, a document you can edit, a written report, source files, an image, or a website you can download. Without that, you will usually get prose in the chat and nothing you can file or forward.

One honest limit: a website it builds arrives as files you download and open — not as a hosted address you can send someone.

That last sentence in the example matters as much as the rest. Telling it what to do when your request can’t be fully satisfied is the difference between a short honest answer and a padded one.

Expect it to stop and ask

When something material is genuinely missing, it stops and asks rather than guessing, and the work sits parked — nothing runs and nothing is charged while it waits for you. A good request isn’t the one that avoids every question. It’s the one where the questions left are the ones only you can answer.

When you don’t want to sit through it

Typing something always starts a chat. Handing work off to run without you is a separate, deliberate choice: start it from a task card on the home screen, or from the composer on the Tasks screen. Nothing gets promoted to a background task behind your back based on how you phrased it.

A handed-off task can run once or repeat — every morning, weekdays at 9am, Mondays at 9am, every hour, every 30 minutes. It also accepts plain text material only, so if the job depends on a PDF, a spreadsheet or an image, keep it in the chat instead. See Giving it materials.