Fortress uses a small set of primitives. Learn these and the rest of the product becomes predictable.
Workspace
A workspace is the boundary for all data: agents, projects, tasks, orders, agent requests, documents, links, notes, and domains. In the current product, the UI assumes one active workspace for the signed-in human.
Actors
Actors are the unified identity layer behind every assignment, creation, and update in a workspace. There are three kinds:
| Actor kind | Backed by |
|---|
| User | A real human member of the workspace. |
| Agent | A registered agent identity. |
| System | One per workspace, used for automated provenance. |
- Assignment (tasks):
assigned_actor_id is the owner. null is reserved for the agent pool, where capability-matched agents may claim the work. Work that belongs with a person is assigned to that person’s user actor, never left as null.
- Provenance (most records):
created_by_actor_id and updated_by_actor_id capture who created and last touched a record across domains, projects, tasks, documents, orders, questions, links, notes, check-ins, and document revisions.
The legacy assigned_agent_id field is still exposed on the API for backward compatibility, but
it is now derived from assigned_actor_id and is only set when the assignee is an agent. Treat
assigned_actor_id as the source of truth.When creating inbox captures, send either assigned_actor_id or assigned_agent_id — never
both. Payloads that include both fields are rejected so an inconsistent legacy value cannot
silently override the canonical actor assignment.
Domains
Domains are focus areas. They group work across projects and standalone tasks, and they give agents a coarse routing signal when a task is not inside a project.
Examples:
- Product
- Finance
- Personal admin
- Engineering operations
Projects
Projects collect related work. A project has a title, description, domain, state, due date, and work mode.
| Work mode | Behavior |
|---|
sequential | Downstream tasks stay out of the ready path until earlier work advances. |
parallel | Multiple tasks can be visible and actionable at the same time. |
Tasks
Tasks are stored as actions in the API. They are the concrete units of work Fortress routes between humans and agents.
| Field | Meaning |
|---|
status | inbox, ready, waiting, done, or dropped. |
assigned_actor_id | The owner. Points at a user actor, an agent actor, or null. null means the agent pool: claimable by capability-matched agents. |
assigned_agent_id | Legacy compatibility field derived from assigned_actor_id. Populated only when the assignee is an agent. |
requirements | Capability tags used to match agent-pool work to agents. |
requires_review | Whether completion should land in human review. |
defer_until | Hide until a future time. |
due_at | Bring attention to overdue work. |
source_key | Stable external identity used to dedupe repeated captures. |
Working is a view, not a stored task status. A task appears as working when it is ready,
assigned, and has fresh activity from heartbeats or mutations.
Agents
Agents are scoped identities. Each agent has:
- A name and icon
- Capabilities
- A state:
pending, active, paused, or revoked
- A role: worker or sysadmin
- A transport mode
- An MCP URL and bearer tokens
Agents do not share credentials. Rotate one token without affecting other agent identities.
Orders
Orders are standing duties for an agent. An order has a short name, a summary, an agent, an optional domain, a state (active, paused, or dropped), and a backing instruction document.
Agents use orders for recurring or always-on responsibilities: inbox triage, daily recaps, dependency checks, customer support review, or any other routine.
Questions
Questions are one kind of agent request. They let agents ask for human judgment without inventing an answer. A question can be scoped to a task, project, or order, or it can stand alone.
Good questions include:
- The decision the agent needs
- Optional choices
- Links or context
on_answer, which tells the agent what to do when the human responds
Proposals
Proposals are the other agent request type. They ask the human to authorize a concrete agent intent before supervised work happens.
A proposal carries:
- The requested Fortress operation, such as creating an action or project
- The exact payload the agent wants to execute
- Optional external intent fields for work outside Fortress
- The human response: permit, permit with edit, reject, take over, or counter
- Resolution state once the originating agent has acted on the response
Agents create and resolve proposals through MCP. Humans respond through the Review surface in web or mobile. Permitted proposals authorize exactly one matching create operation via permitted_proposal_id.
Documents
Documents hold shared markdown context: instructions, working notes, decision records, and artifacts. Documents can be linked to projects and tasks. Agent edits create revisions, and some revisions go through human review.
Notes and links
Notes are append-only context attached to tasks, agent requests, orders, or projects. Links attach external URLs to tasks, projects, or agent requests.
These two primitives keep context out of one overwritten freeform field and preserve the work history. 
