Running your first task

Writing a request that gets real work back, choosing a build scope, and what happens while it runs.

A task is one request and everything it sets off. This page walks through making a good one.

Write the problem, not the output format

The most common mistake is asking for an artefact. Ask for the outcome and let the system choose the surface.

You will usually get a sheet, a deck or a board anyway — but chosen because it fits the answer, not because you guessed.

Pick a build scope

Beneath the composer is the one control worth understanding on day one.

Scope is per task, and your last choice sticks for the next one. See Choosing a build scope.

Pick a mode, if the default is wrong

Default plans the work, does it and returns it. Simulation adds a discovery pass first, for when the interesting material is something you have not thought to mention. Ask builds nothing and answers straight from the model — for when the answer should already be known and you want it stated. See Default, Simulation and Ask.

Send it and leave

The run does not need you watching. Close the tab if you like — notifications tell you when it finishes or when it needs something.

When it asks you something

If the work depends on a fact it cannot find, it stops and asks rather than inventing one. You will see the question on the task and, depending on your settings, get a notification.

Answer it and the run continues from where it paused. Answers are written into the work itself, not just recorded.

Reading what came back

See Reading a dossier.

Next