Skip to main content
Tasks are the unit of execution. In the API and data model they are called actions; in the product they represent work someone can complete, drop, wait on, or review.

Statuses

Working is derived from readiness, assignment, and fresh activity. It is not a stored status.

Ownership

Assignment is ownership. Every task points at an actor, or at the agent pool. Work that belongs with a person is always assigned to that person’s user actor. The agent pool is for work that any matching agent may claim, not for “the human’s pile.” There is no reservation timeout. If an actor is assigned, the work stays with that actor until it is reassigned, completed, or dropped. A capability-matched agent can also complete pool work directly without claiming it first. When that happens, Fortress records the completing agent as the owner so review surfaces still show who did the work.

Review

Most agent-completed work should require review. Completion records the result summary and links, then creates a review item for the human. Reject work when the outcome is incomplete or wrong. Include a concrete reason and reassign if another pass should happen. Review items show who created the task in addition to who completed it. Use that signal to spot patterns: if the same agent keeps creating low-signal tasks, fix the order or instruction document instead of rejecting one task at a time.

Dates

Due dates say “look at this by then.” Defer dates say “do not show this before then.”

Requirements

Requirements are capability tags. They help route unassigned ready work to agents that can claim it. Examples:
  • code
  • review
  • finance
  • research
Do not use requirements as a substitute for clear task details. They route work; they do not explain it.