Work items

Definition

In the reference package, a work item is a durable work contract owned by one team at a time. It makes an intended outcome explicit across attempts, waits, retries, reviews, and handoffs defined by the package.

One item may lead to many runtime execution attempts over time. Comments and labels may change, and the package may assign persistent principals or fresh execution. The item’s semantic ownership stays explicit inside the package until 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

This package moves a work item 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.

A selected package may model task-like work. The company and common runtime must not become a task-shaped kernel.