Thread events

Read the durable log with GET /v1/threads/{threadId}/events. Every event carries seq, eventId, threadId, turnId, type, and occurredAt. Everything else depends on type.

​

Event types

If you see a tool_intent with no tool_result after it, that call is parked on a wait. reveal on a tool_result is how tool_search works: it names the tool families and tools that result made callable for the rest of the thread.

​

Compaction

compacting and compacted both carry a compaction object:

​

Thread status

The thread record reports one coarse status: GET /v1/threads?state=waiting is the one accepted filter on the thread list. It gives you the queue of threads waiting on a person, and each thread summary carries pendingWaits.

​

Submit modes

POST /v1/threads/{threadId}/messages takes an optional mode:

​

Content blocks

content is an ordered array of blocks, on both user and assistant messages: One message holds at most 40 blocks and 512 KiB of encoded JSON.

​

Streams

GET /v1/threads/{threadId}/events/stream, GET /v1/agents/{agentId}/events/stream, and GET /v1/events/stream push Server-Sent Events for one thread, one agent, or the whole workspace. They are best-effort activity hints, not a replay log. Whenever correctness matters, reconnect and read the durable log.