Tasks, projects and playbooks
Work in a workspace comes in three shapes. A task is a piece of work being done. A project is a body of work with an end. A playbook is work that repeats.
They all hang off goals, and picking the right shape is mostly common sense — but the differences change what agents do with them, so they are worth five minutes.
Tasks: the unit of execution
A task has a status, an owner, and usually a link up to the project or goal it serves. Owners can be agents or you — some tasks are yours because only you can do them, and an agent will say so rather than pretend otherwise.
Bigger tasks carry steps, so progress is visible before the whole thing is finished. The statuses cover the usual ground, and two of them are the ones to watch. Waiting for approval means an agent has stopped and put something in your inbox. Blocked means it cannot proceed and has written down why — a missing tool connection, an unanswered question, something outside its reach.
Most delegated work becomes a task without you asking. That is the point: the chat is the conversation, the task is the record — where the result attaches and where the history lives.
Projects: work with an end
A project is a launch, a website, a migration, a book: something finite, with deliverables, risks, and a set of tasks that make it up. It usually names the goal it serves.
Use one when the work has enough moving parts that a flat list would lose the thread. Do not create one for an afternoon's work — that is a task, and a project around it is just ceremony.
The useful thing a project gives an agent is the ability to ask "what is next here?" on its own. When one task finishes, the project says what the next one should be.
Playbooks: work that repeats
A playbook is a written procedure an agent follows: the weekly report, new-client onboarding, the monthly reconciliation, the content review. It holds the steps and keeps a record of every run.
The moment to create one is right after a piece of work went well. Ask for it while the details are fresh and the agent writes the procedure from what it actually did, rather than from a general idea of how such things are done. "Turn what you just did into a playbook" is the whole request.
This is where the compounding happens. Agents run playbooks on their own during a heartbeat, so work you did once by hand becomes work that happens on Tuesdays without anyone remembering to start it.
Look at the run history occasionally. A playbook that fails at the same step every time usually has an out-of-date instruction in it, or is missing a tool connection.
Which shape do I want?
If it is being done now and then it is done — a task.
If it has an end but enough parts to need a plan — a project.
If it will happen again in the same shape — a playbook. And if you are not sure it will repeat, do it once as a task and turn it into a playbook the second time you find yourself asking for it.
Keeping the pile honest
Close what is finished. A workspace full of tasks that quietly completed three weeks ago makes every status summary a lie, and agents read those files too.
Ask for a sweep when it feels heavy — "what in here is stale?" It costs one message and the agent is reading the same files you would have to.