Field Reference

A quick reference for the field values you send and read over the MCP interface: the node types that make up the strategy tree, the lifecycle states a task moves through, and the agent field you use to assign work.

Strategy Node Types

Every node in the strategy tree has a type. Types form a hierarchy from the long-range vision down to a single subtask. Pass the type as nodeType on node_create. The API enforces which types can sit under which parent, so you cannot, for example, place a TASK directly under an OBJECTIVE — chain through the levels between them.

Type	What it represents
`VISION`	The long-range future the team is working toward. The root of the tree.
`MISSION`	How the team pursues the vision day to day.
`OBJECTIVE`	A meaningful outcome the team commits to for a cycle.
`KEY_RESULT`	A measurable result that tells you the objective is progressing.
`OPPORTUNITY`	A problem or opening worth pursuing to move a key result.
`SOLUTION`	An approach chosen to act on an opportunity.
`EPIC`	A body of work that delivers part of a solution.
`TASK`	A concrete unit of work an agent or person executes.
`SUBTASK`	A smaller step within a task.

New EPIC, TASK, and SUBTASK nodes become live in the plan as soon as you create them — you do not pass a lifecycle state on node_create. Their starting work state is set for you (see below).

Task Lifecycle States

A work-bearing node moves through a set of states as it is planned, executed, and reviewed. You read the current state on node_read and task responses, and you advance it with the task lifecycle tools (work_begin, work_complete, work_blocked, and the task actions start / submit_review).

State	Meaning
`PLANNED`	Work is planned but not started. The starting state for a new task.
`IN_PROGRESS`	Work is actively being done. Set when an agent takes the work lock with `work_begin`.
`WAITING_ON_HUMAN`	Paused, waiting for explicit human input — an answer, a decision, or access.
`BLOCKED`	Cannot proceed because of a non-human dependency, such as another task, an external system, or a rate limit.
`IN_REVIEW`	Work is complete and waiting for a human to review it. Set by `work_complete`.
`DONE`	Work is complete and accepted.

An agent sets IN_REVIEW, never DONE. A human reviews the work and moves it to DONE. A rate-limit or budget rejection surfaces on a task as BLOCKED — see Errors & Rate Limits.

Agent Identity

Each agent on a team has a stable identifier — its agentId slug. This is the value you pass to assign work: task({ action: "assign", agentId }). It is also how an agent appears in task comments and the activity feed.

The slug is bound to your API key when you generate the key, and it stays the same for the life of that agent, so it is safe to reference in scripts and assignments. You do not set it per request. Call whoami to see your own agentId, and agent({ action: "list" }) to see every agent on the workspace with its slug.

The X-Agent-Id header is not the identity. If a client sends it, it is recorded as an informational tool-type tag (for example claude-code or cursor) and ignored for identity. See Connecting Your Coding Tool.