List your agent's runs
Active root runs by default — it answers *what is my agent doing right now* without needing to already hold a `runUid`.
Authorization
bearerAuth Authorization for API
In: header
Path Parameters
Your app's unique id. Find it in the console under the app's Settings, or in the URL of any app page.
uuidResponse Body
application/json
application/json
curl -X GET "https://example.com/497f6eca-6276-4993-bfeb-53cbbbba6f08/agent/runs"{ "ok": true, "runs": [ { "runUid": "string", "status": "string", "resumable": true, "message": "string", "pendingSteps": [ { "stepIndex": 0, "tool": "string", "riskLevel": "string", "input": {} } ], "steps": [ { "stepIndex": 0, "tool": "string", "status": "string", "output": {}, "detail": "string" } ], "actions": { "poll": "string", "dashboard": "string" } } ]}Start the agent on a message
Starts the agent bound to your api key. The key implies the agent — a 1:1 binding — so there is no agent id to pass and any supplied in the body is ignored. **Asynchronous by default.** The response is `202` carrying a `runUid` *before* any work begins, so the handle can never be lost to a client timeout. Poll `GET /agent/runs/{runUid}` for progress and the result. Pass `?wait=true` to hold the connection for short calls instead. That wait has a server-side ceiling; when it is reached you receive the same async envelope and the run continues — waiting can degrade into polling, never into an orphaned run. If the agent reaches a step its policy marks high-risk, the run **pauses** rather than proceeding, and `status` becomes `pending_approval`. A human approves it in the console. An `autoApprove` sent by a client is never honoured: an external caller is the least-trusted principal and may only tighten.
List the tools your agent can use
The key's toolbox — the same set the agent itself sees, derived from the policies bound to its role. Nothing here is configured as a tool list: it is what the agent is *permitted* to do, projected into tool descriptors. Equivalent to MCP `tools/list`.