Skip to content

Get Agent Session State

GET
/agent/sessions/{session_id}/state

Everything needed to render one session from cold.

THREE sources in one answer, and the difference between them matters: messages are the chat bubbles, steps are what the agent actually did (tool calls, reasoning summaries) and work_item_status is whether it is still going. A session driven by a work item has richer steps than messages, and a plain chat has only messages - so a client that renders only one of them will show an empty conversation for half the sessions.

404s on a session the caller cannot see, rather than 403 - existence is not leaked by distinguishing the two.

Authorizations

Parameters

Path Parameters

session_id
required

Session id (UUID).

string

Session id (UUID).

Header Parameters

X-Target-Org-Id
Any of:
string

Responses

200

Successful Response

object
data
required

An open envelope for a hydration or voice answer.

Open because session hydration returns the agent’s STEPS as well as its messages, and a step’s detail is whatever the tool that produced it reported. That set grows with every tool the platform gains, and a pinned mirror would drop the detail of exactly the newest ones - which on a transcript surface reads as the agent having done less than it did.

object
key
additional properties
any
pagination
Any of:
object
has_next
required

Whether there are more pages

boolean
limit
required

Items per page

integer
next_cursor
Any of:
string
notes
Any of:
Array<string>
page
required

Current page number (1-indexed)

integer
total
required

Total number of items

integer
total_available
Any of:
integer
total_is_lower_bound
Any of:
boolean

422

Validation Error

object
detail
Array<object>
object
loc
required
Array
msg
required
string
type
required
string