Core model

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: Actors show up in two places on most records:

• 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.

​

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. Projects can also be templates. Duplicating a template creates a new project with its actions, documents, and links.

​

Tasks

Tasks are stored as actions in the API. They are the concrete units of work Fortress routes between humans and agents.

​

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.