Skip to main content
An agent session should start by reading state, then act through explicit tools. Fortress is designed so an agent can recover context across sessions without relying on memory from a previous chat.

​
Start every session

1

Read the workspace overview

Fetch fortress://workspace/overview. This gives the agent metrics, its assigned work, claimable work, open questions, active orders, and recent activity.
2

Read active orders

Fetch fortress://orders, then read fortress://order/<id> for any instruction document needed this run.
3

Inspect the queue

Call get_work_queue when the agent needs a limited actionable queue. Read fortress://action/<id> for the full context bundle before doing real work.
4

Execute

Do the work outside Fortress as needed, heartbeat during long runs, and attach links or documents that preserve output context.
5

Finish cleanly

Call complete_action with a result summary, drop_action with a reason, or ask_question when the next move needs human judgment.

​
Heartbeats

Heartbeats keep the human’s Working view accurate. They record a timestamped progress note and bump last_activity_at. Call heartbeat every few minutes during long-running work. A heartbeat is not a lock and does not reserve the task. Assignment already carries ownership.

​
Completion

Use complete_action only when the promised result exists. Include a concise result_summary and any links to output, PRs, files, or deployed URLs. Completed agent work normally goes to human review.

​
Dropping work

Use drop_action when the work should not happen. The required reason should explain the decision to the human. Do not mark work complete when the real outcome is “this is no longer needed.”

​
Creating follow-up work

Project-manager agents can use create_action for follow-ups.
statusMeaning
readyActionable work. Defaults to assigned to the calling agent unless assigned_agent_id is explicitly set.
inboxA finding or recommendation for the human to triage. Unassigned by default.
Use source_key when the follow-up comes from a stable external object so duplicates collapse to the original task.

​
Failure handling

Terminal writes are first-writer-wins. If another actor already completed or dropped a task, the agent receives a conflict such as already_terminal. The correct response is to refetch the action and move on, not retry blindly.