Work domains
Every task belongs to a work domain. There are two today, software and marketing, and the domain is decided per task when the work is shaped rather than set once for a project.
The reason for the distinction is simple: a task that changes code and a task that publishes a post are checked against different things, verified in different ways, and carry different risk when they go out unattended.
What each domain is grounded against
Section titled “What each domain is grounded against”Grounding is the material a task was written against, and it is where the domains first diverge.
Software work is grounded against the code. At its best that means a real checkout, so the spec names files that exist and patterns the repository actually uses. Where a checkout is not available, the repository is read through the hosting provider’s API instead.
Marketing work is grounded against the project’s marketing material: the product truth, the campaigns that are running, and what recent work actually produced. There is no repository in that ladder, and pretending there is would produce a spec full of invented file paths.
When neither is available, the task is written from the conversation alone, and it says so on its face rather than implying a certainty it does not have.
How the specs differ
Section titled “How the specs differ”Both domains use the same canonical spec, and two sections are worded for the domain because the same words would be wrong in the other one.
| Section | Software | Marketing |
|---|---|---|
| Starting state | The repository state to verify before coding | The starting state to verify before you begin |
| Quality bar | A test plan, written first, that must fail before implementation | Quality checks, defined first, that the work must pass before it ships |
| Definition of done | Tests, lint, and typecheck green, and nothing outside scope | Every quality check passed, every deliverable linked, required approvals obtained |
The marketing definition of done ends where the software one does not: with the approvals its autonomy level requires. Shipping is part of the work, so the permission to ship is part of being done.
Where autonomy diverges
Section titled “Where autonomy diverges”Software work mostly produces things you review before they go anywhere: a branch, a draft, an artifact. Marketing work produces things the public sees.
That is why the action classes on the ladder are dominated by marketing-shaped acts: publishing to a site, posting to a social account, sending bulk email, writing to customer records, and spending on advertising. Internal drafting sits above them at a higher default level precisely because a draft is not visible outside your workspace.
The practical effect: an agent can usually take a marketing task from idea to finished draft on its own, and then stop. The last step, the public one, is the step your autonomy settings decide.
What stays the same
Section titled “What stays the same”Domains change how work is grounded, worded, and gated. They do not create a second product. Both kinds of task:
- live in the same project and carry the same short keys,
- come out of the same meetings and the same drafts,
- execute as runs with the same budgets and the same review loop,
- and appear on the same initiative trail, which is what lets one thread run from a code change to the post announcing it.
Next steps
Section titled “Next steps”- Tasks: the spec and grounding both domains share.
- The autonomy ladder: the action classes marketing work runs into.
- Initiatives and flow: the thread that carries both domains end to end.