Work items
The primary durable unit of actionable work. A work item is a contract for what needs to get done — not a chat message, not a single attempt, not a session that scrolls away.
Definition
A work item is a durable work contract owned by one team at a time. It exists to make an intended outcome explicit and preserve that outcome across runs, waits, retries, reviews, and handoffs.
One work item may produce many runs over time. Comments and labels may change. The team that owns it may use persistent agents, ephemeral execution, waiting on other teams, or review loops. But ownership stays explicit until it’s intentionally transferred.
What a work item captures
- Source — Why this work exists. A trigger, a prior promise, an external signal, a review outcome, an operator directive. Work items that can’t answer “why does this exist?” have already started wrong.
- Owning team — Exactly one team at a time. Ownership doesn’t live in comments or session history — it’s explicit on the work item.
- Task text / expected outcome — What the team is trying to accomplish. Concrete enough that a different agent could read it and pick up where someone else left off.
- Current state — One of: proposed, admitted, in_progress, waiting, completed, failed, canceled. (Full lifecycle below.)
- Labels — Lightweight classification. Labels classify; they don’t replace state.
- Comments — Discussion, progress notes, rationale, review notes attached to the work item over its life.
- Waiting condition — When the item is in waiting state, what specifically it’s blocked on. Visible from work-item state, not buried in prompt history.
- Optional coalescing key — Repeated pressure for the same unresolved work should map to the same item, not multiply.
Lifecycle
A work item moves through these coarse states:
- Proposed — The work has been suggested but not yet admitted by a team. Still being interpreted. The threshold to admission is the most important moment in a work item’s life: before, the company is still deciding; after, a team is on the hook.
- Admitted — A team has taken ownership. The work is real.
- In progress — A run is active or recently active. Concrete attempts are being made.
- Waiting — Blocked on something external. The waiting condition is explicit on the work item itself.
- Completed / failed / canceled — Closed. The work no longer competes for attention. The history stays so the next similar signal can be recognized.
Why work isn’t the unit
A common mistake is to make the work item the primary mental model of an exocorp. Work items matter, but they’re downstream of a larger metabolism: signals come in, beliefs form, bets get chosen, validation runs, commitments are made, and only then does work get admitted.
When work items become primary too early, the company starts turning open questions into scoped action. It lets activity stand in for learning. It routes ambiguity to whoever can produce the most convincing artifact. That’s how an autonomous company becomes an efficient producer of stale assumptions.
An exocorp needs task-like work. It must not become a task-shaped mind.