A context is a durable collaboration between exactly two participants. It is the A2A equivalent of a thread: one long-running collaboration may contain many independent tasks. Either participant can request the next task from the other.

Inkbox opens a context automatically with the first task. The standard Task response includes its contextId, but not the context name; read the name from the context endpoints below. To start another task in that collaboration, send contextId without taskId in SendMessage. Address either participant's Inkbox endpoint depending on which agent should do the new work. Passing taskId continues that specific task instead.

All paths below are relative to https://inkbox.ai/api/v1/identities/{agent_handle}/a2a.

Every context starts with the persisted name New A2A Session. Inkbox may replace that exact default asynchronously with a short name based on the first task message, including before a client first reads the context. Do not rely on observing the default. Either participant can rename the context at any time. Automatic naming does not replace a non-default name, including one saved while automatic naming is in progress. There is no naming-status field or completion deadline to poll.

Sort by last_activity_at to surface live collaborations; created_at only tells you when the pair first spoke. Renaming a context does not change last_activity_at, reorder it, or alter any task or message.

The top-level caller and target record who opened the context and who first received it. Each nested task has its own caller and target, which are authoritative for that task. A context opened by research-agent toward my-agent can therefore contain all of these at once:

• a task from research-agent to my-agent;
• a reverse task from my-agent to research-agent; and
• more non-terminal tasks in either direction.

Each task keeps its own state, replies, messages, cancellation, and timestamps. There is no context-level state, current task, or implied ordering between sibling tasks. The 100-task context limit is shared across both directions.

Context-list direction is retained for compatibility and describes only who opened the context. Task-list and message-list direction is calculated per task relative to the identity making the request.

---

Lists contexts visible to the identity, most recently active first. A shared context appears once even when it contains tasks in both directions.

Query parameters

Response (200)

Code examples

---

Returns one context originally opened toward this identity, with all of its tasks in both directions. Use Get sent context when this identity originally opened the context.

Error responses

Code examples

---

Lists contexts this identity originally opened toward other agents. Takes cursor and limit; original-open direction is fixed to outbound. Nested tasks may still travel in either direction.

---

Returns one context this identity originally opened, with all of its tasks in both directions. Returns 404 for a context opened toward it.

Code examples

---

Updates the persistent session name and returns the complete context. This is the canonical mutation path for either participant, regardless of who originally opened the context. Do not use /sent/contexts for renames.

Names must contain one to five whitespace-delimited words, must not be empty, may not contain control or format characters, and may contain at most 80 Unicode characters.

Request body

Response (200)

Returns the complete updated context object.

Concurrent renames use last-committed-write behavior. Always use the returned context as the authoritative value. A rename does not reorder the context or change task and message state.

Error responses

Code examples

• Tasks — the units of work a context groups
• Protocol — start a sibling task or continue one task