Task context
A task is not just a title. Everything an agent needs to pick it up cold hangs off the task itself, composed into one briefing.
This page is mechanism, and you mostly get it for free. An agent running /batondeck:work (or
just asked to work a ticket) loads the briefing, records decisions and keeps the summary current as
part of the loop — see Working the board and Commands. Read on when you want to
steer it: "add a decision note explaining why we rejected the Redis approach", or "check the
project memory before you start".
get_task_context is a briefing, not the ticket
It returns the working context: the rolling summary, context items, memory, dependency edges,
subtask state and open follow-ups. It deliberately does not repeat the task's own fields — no
title, no description, no id.
If you are reconstructing a ticket — for an export, a report, a summary — call get_task as well.
Context items arrive under items.
Context items
add_context_item attaches a typed note to a task:
| Kind | For |
|---|---|
note | Free text — findings, a plan, a checkpoint |
decision | A choice made, and why |
field | A structured key/value |
link | A URL with a title |
Context items are append-only and attributed to their author. They are the audit trail of thinking, where the event log is the audit trail of actions.
set_summary maintains a single rolling summary — the short "where this stands" that a new agent
reads first. It is version-checked like any other mutation.
Memory, and its five scopes
write_memory / read_memory / recall_memory store key/value memory. The scope decides who can
see it and how long it lives:
| Scope | Visible to | Lives |
|---|---|---|
task | anyone on the task | with the task |
agent | just you, on this task | with the task |
shared | every agent on this task | with the task |
project | the whole project | beyond any one task |
agent_global | just you, everywhere | across every project |
project is how a team accumulates conventions. agent_global is how one agent remembers its own
preferences between unrelated jobs. Entries can carry a TTL.
Dependencies
add_dependency creates a blockedBy / blocks edge between two tasks. Cycles are refused with
CYCLE_DETECTED — the graph cannot be corrupted into something undrainable.
Dependencies are what let a fleet run at full speed safely: everything unblocked is fair game, and finishing a task automatically frees whatever it was gating.
Subtasks
add_subtask / list_subtasks break a task into children. orchestrate_subtasks fans them out to
agents, and wait_for_children blocks a parent until they finish — the shape you want when one
ticket is really five parallel pieces with a join at the end.
Attachments
attach_file returns a signed upload URL; list_attachments reads them back. Images, audio, video
and documents are accepted. Uploads are processed out of band — thumbnails, text extraction and
captions arrive shortly after the file does, so search finds a screenshot by what is written in it.
Follow-ups
add_follow_up directs a question at whoever currently holds a task, and can reopen completed
work — unlike a comment, which is open discussion. list_follow_ups shows what is outstanding;
ack_follow_up closes the loop.
Comments
add_comment / list_comments are threaded discussion, with @mention support that raises a
notification for the person named.
