Tasks and the agent¶
A task is one concrete piece of work. "Draft the pricing page copy." "Compare our onboarding against the three competitors in the knowledge base." "Write five subject lines for the launch email."
A task has a name, a prompt describing the work, a label saying what kind of work it is (insights, strategy, content, growth, sales, ops), and usually a mission and a week. The week is the same bucket the mission roadmap uses, so a task planned for a week sits under that week's intent.
Where tasks come from¶
Three places, and they behave identically once they exist.
You create one, because you know what you want done.
The agent creates one while you are talking to it, which is usually how a conversation that starts "can you look into..." ends.
A day plan proposes one. These arrive in your inbox as part of a morning plan, and each carries a one-line rationale saying which slice of the day's win condition it advances. Read the rationale before the task name; it is the part that tells you whether the agent understood the day.
Status is a record, not a control¶
A task moves through planned, running, and then done or failed. You do not set that by hand, and there is no field to drag. Status follows what actually happened: it goes to running when work starts and to done when work finishes.
This is on purpose. A status you can set by hand is a status that lies, because updating it is a second job everybody forgets. Here, a task marked done is done because something completed.
Live or in the background¶
There are two ways a task gets executed.
Live in chat means you and the agent work through it together. You see the reasoning as it happens, you can interrupt, you can redirect halfway. Use this when you are not sure what you want yet, or when the work is the kind you would normally do over someone's shoulder.
In the background means the agent runs on its own and you come back to the result. Use this when the brief is clear and the work is long. Background runs are also how scheduled work executes.
The agent and its context are identical either way. The choice is about whether you want to be in the room.
Attachments¶
You can attach files to a task. Those are context for that piece of work and nothing else: attaching a file to a task does not add it to the workspace knowledge base, and it should not, because the brief for one task is rarely reference material for every future one.
If you find yourself attaching the same document to a fourth task, that is the signal to mark it as knowledge instead.
Working with the agent in chat¶
The chat is not one endless conversation.
Each chat tab has its own memory. Two tabs open on two different problems will not bleed into each other. This is what makes it safe to leave a long thread running while you ask something unrelated.
"New chat" is genuinely fresh. Not a visual clear with the old conversation still in scope. If a thread has gone somewhere unhelpful and you cannot steer it back, starting a new chat actually works.
The agent can see what you have open. If you are looking at a mission, the agent knows which mission. You can say "add a task for this" without naming it. This also changes how changes are applied: when the agent edits something already on your screen, you watch it change instead of getting a card asking permission for something in front of you.
You can interrupt. A live run that has gone the wrong way does not have to finish before you correct it.
How to frame a task prompt¶
The most common mistake is writing a specification. The agent has your knowledge base; it does not need you to restate your positioning in the prompt.
The second most common mistake is being so brief that "good" is undefined. "Write a blog post" gives the agent nothing to aim at.
A prompt worth writing says:
- What you want, in one line.
- Who it is for, when it is not obvious from the mission.
- What good looks like, which is the part people skip. "Something a sceptical CFO would forward" tells the agent more than three paragraphs of structure.
- What to avoid, if you have been burned before. Though if you find yourself writing the same avoidance twice, it belongs in a rule.
A good first prompt is usually three or four sentences. If yours is running to a page, most of it is probably context that belongs in the knowledge base, where every future task can use it too.
When a task goes wrong¶
A failed task keeps its record. You can read what happened rather than guessing.
The useful question after a bad result is which of three things was missing: context the agent did not have, a brief that did not say what good was, or a job that genuinely needed a person. Only the third one is a reason to stop delegating it. The first is a knowledge base edit and the second is a better prompt, and both make every future task better rather than just this one.