What an agent sees and can do
The problem it solves
Section titled “The problem it solves”An agent in a terminal lives as long as the terminal: close it, and the context is gone. On a board, agents wait for people all the time (a plan to accept, a question, a tool to approve), and a wait can last minutes or days. A ticket must survive that, a restart of the board and a failed API call, without starting over and without an agent sitting idle on a process the whole time.
How it works
Section titled “How it works”Runs, sessions and resumes
Section titled “Runs, sessions and resumes”- A run is one agent process. The runner claims a ticket from To Do, moves it to In Progress, starts the agent CLI in the ticket’s worktree and streams everything it does onto the timeline.
- A session is the agent’s conversation, saved on the ticket at the end of every run (and when a run fails or waits out a limit).
- A resume is the next run continuing that session. When the ticket returns to To Do (you reply, approve a tool, answer a question, or a background task it waits on finishes), the runner resumes the session and hands the agent what happened as its next message.
So nothing is lost when a ticket parks: the next run has the whole conversation, the same branch and the same worktree, which is committed after every run. A resumed run gets a short reminder of the board’s rules rather than the full instructions again. Two things do not survive the end of a run: a background process the agent started itself (the board’s own background tasks do), and an Allow once tool grant.
If the engine changes between runs (you switch the model from Claude to Codex), or the saved conversation cannot be found, the next run starts a fresh session with the ticket’s timeline replayed into its prompt, and says so on the ticket. Restart from scratch discards the session on purpose.
A long session is compacted before it resumes once it passes Compaction threshold (75% of the context by default; Settings > Agents > Context & retries), and parked tickets are compacted while they wait. Compaction is Claude Code only.
How every run ends
Section titled “How every run ends”An agent must end each run in one of three ways, and its instructions say so:
| Ends by | Tool | The ticket goes to |
|---|---|---|
| Finishing | finish_ticket | In Review, after its verification checks pass (Hold agents to a quality bar). |
| Asking | request_action for free-form input, or a question with clickable choices | Pending Action, until you answer. |
| Parking on work | await_background_tasks, await_subtickets | Pending Action, woken automatically when the tasks or children finish. |
This is why the board never loses track of a ticket: its column always says who acts next. A run that ends with the ticket still In Progress gets a safety net. On Claude Code, the board first asks the agent whether it is finished, blocked or not done: finished moves the ticket to In Review with a note, blocked parks it. Otherwise the board resumes the session once, and if the next run ends the same way it parks the ticket for you: Run finished without calling finish_ticket or request_action.
The board tools an agent has
Section titled “The board tools an agent has”Every agent gets the board’s own MCP server, so it works the board the way you do: read tickets, diffs and the Knowledge Base; comment, tag and attach artifacts; file a plan; create subtickets and Loops; start background tasks and use the ticket’s terminal; message another ticket. The full list is MCP tools.
Most of those run freely. The ones that change something you would want a say in ask you first, by parking the ticket on a permission request:
| Asks you | Tool |
|---|---|
| Change a ticket’s working directory or base branch | update_ticket |
| Rename its branch, or move it to another repo | set_branch, set_repo_binding |
| Merge or revert a ticket | merge_ticket, revert_ticket |
| Create a ticket that is not its own subticket, or delete a ticket | create_ticket, delete_ticket |
| Delete a Knowledge Base page or space, or publish its own page | delete_kb_page, delete_kb_space, organize_kb_page |
| Weaken a verification check after you accepted the plan | set_verification_checks |
| Change where plugins come from | set_plugin_source |
For its own shell commands and file writes the agent goes through the permission gate: a
dangerous command (a recursive delete outside its worktree, sudo, git push, a forced
reset), a command on the ask list, or a write outside its worktree parks the ticket for you.
Before anything is filed, the agent must say why it needs it; that answer is what you read on
the panel. See The permission gate.
Agents talking to agents
Section titled “Agents talking to agents”An agent can send a message to another ticket with send_ticket_message. It lands on both
timelines (sent to agent #N, from agent #N) and reaches the other agent as its next
message: straight away if it is running, held if it is parked on you, and otherwise it queues
the ticket. In an orchestration, a child’s questions and plans go to its orchestrator first
(Split big work into subtickets).
The engines side by side
Section titled “The engines side by side”The engine follows the ticket’s Model: pick a Claude model and it runs on Claude Code, a GPT or Codex model on Codex, a Cursor model on Cursor. The model list groups them by engine.
| Claude Code | Codex | Cursor | |
|---|---|---|---|
| Permission gate | Every tool | Every approval the app server asks for; exec transport is ungated | None: runs with --force and skips the board’s approvals |
| The board’s MCP servers | Yes | Yes | No: Cursor reads its own MCP configuration |
| Plans | Yes | Yes, in a read-only sandbox | Yes, in ask mode |
| Resume | Yes | Yes, while the thread exists | Yes |
| Command tickets and skills | Yes | Skills yes, command tickets no | No |
| Compaction, the finished-or-blocked check | Yes | No | No |
Each run posts an Engine parity note on the ticket for any rule its engine cannot enforce. Treat a Cursor run like running the CLI yourself: the board neither gates its tools nor, unless Cursor is configured with the board’s MCP server, gives it the tools to finish or ask. See Run Codex or Cursor instead of Claude Code.
Retries, stalls and limits
Section titled “Retries, stalls and limits”| What went wrong | What the board does |
|---|---|
| A transient API error (a dropped connection, a timeout, a 5xx, overloaded, rate limited) | Resumes the session after a backoff, up to Transient error retries times (4). Then it parks the ticket. |
| A request that stalls: no output while waiting on the model | The stall watchdog cuts it after Stalled request timeout (s) (300) and treats it as a transient error. A long tool call is never cut. |
| A usage limit | Parks the ticket and resumes it by itself when the limit resets, or sooner if you sign in another account. Cancel auto-resume on the timeline card stops that. |
| A run that genuinely fails | Parks the ticket with the error. With Retry queue on in the ticket’s toolbar, it is retried up to 5 times, an hour apart at most. |
| The prompt is too long | Summarises the session, starts a fresh one from the summary and continues. |
What you control
Section titled “What you control”- The model, and so the engine, of each ticket, and the Default model in Settings > Agents.
- Transient error retries, the backoff and Stalled request timeout (s) in Settings > Agents > Context & retries.
- Each ticket’s Retry queue.
- Every permission: what always asks, what is allowed, and for how long a grant lasts (Approve a tool request).
Limits and trade-offs
Section titled “Limits and trade-offs”- A resumed session costs its whole context again on every run; compaction trims it but is Claude Code only.
- The stall watchdog reads Claude Code’s progress messages; on Codex and Cursor it rarely has anything to go on.
- A usage limit message says Claude even on another engine.
- The retry queue is per ticket; there is no board-wide list of what is waiting to retry.
Where you meet it on the board
Section titled “Where you meet it on the board”- The timeline of a running ticket, and its column: In Progress while a run is live, Pending Action while it waits on you (Answer what the board asks you).
- Resume → To Do on a parked ticket, and Reply to agent in the reply box.
- The permission panel, and the Engine parity notes.
Related
Section titled “Related”- Follow and steer a running agent, to watch and redirect a run.
- Worktrees and branches, for where a run works.
- The auto-runner, for how the runner picks tickets.