Invoking means asking AgentOS to run a hosted agent and return its output. AgentOS handles the LLM calls, tool routing, and execution — you supply an input and consume the result.
This page is about hosted agents. If your own code runs the agent and you only report what happened, that's the opposite flow — see Reporting runs.
Invoke only works for runtime_type: hosted agents. Non-hosted agents are run by your code and reported via the ingest API.
your call ──▶ run created (status: running)
│
├─ LLM ⇄ tool loop (each tool call logged as an event)
│
├─ pauses? ──▶ awaiting_approval / awaiting_input (HTTP 202)
│ └─ you approve / answer ─▶ resumes
│
└─ done ──▶ status: completed, { output }
A run can finish in one request, or pause mid-flight if the agent calls an approval-gated tool (see Approvals) or asks the operator a question (the ask_human tool). A paused invoke returns 202 with the run id — you resume it by approving/answering from the dashboard or API, and the agent continues. See Paused runs.
A hosted agent can be triggered from several surfaces. The run's trigger_type records where it came from:
| Surface | How | trigger_type |
|---|---|---|
| Dashboard | the Run button on the agent page | manual |
| Schedule | a cron schedule (Scheduling) | scheduled |
| HTTP / SDK | POST /api/v1/agents/:id/invoke or client.invoke() | sdk |
| Webhook | an inbound webhook trigger | webhook |
| Agent → agent | the invoke_agent tool / pipelines | agent |
| MCP | runs_invoke in the AgentOS MCP server | sdk |
trigger_type is a read-only field recorded on the run — it reflects where the run came from. Callers don't pass it on the invoke endpoint; agent in particular is set by the platform for sub-runs and can't be supplied by a caller.
The rest of this page covers the HTTP / SDK path, which all the others build on.
import { AgentOS } from "@agentos-sdk/core";
const client = new AgentOS({ agentId: "<agentId>", apiKey: "aos_ws_…" });
const { runId, output } = await client.invoke({ query: "Summarise the Q1 report" });
console.log(output.summary);
Authenticate with a workspace key (aos_ws_…) or an agent key scoped to that agent. See Authentication.
Response
{ "data": { "run_id": "uuid", "output": { "summary": "…" } }, "error": null }
What input is — and isn't. input is the run's data, handed to the agent as context. It's advisory, not binding: the model reads and uses it, but can interpret or ignore it. What the agent must do is defined by its system prompt. If you need a value to reliably shape behaviour, put it in the system prompt or pass it as a prompt variable (which is injected into the prompt) — not in input. Only an agent's output_schema hard-constrains anything, and that's the output shape.
| Field | Type | Purpose |
|---|---|---|
input | object | The data the agent operates on. Defaults to {}. |
prompt_variables | { KEY: string } | Fill {{KEY}} placeholders in the system prompt. Override schedule/config values. See Prompt variables. |
session_id | uuid | Continue a server-managed conversation — AgentOS loads and saves history. See Memory. |
start_session | boolean | Begin a new server-managed session; the response returns the new session_id. |
external_user_id | string | Your own id for the end-user a session belongs to (multi-user chat). Only valid with session_id or start_session. |
history | array | Client-managed history instead of a session. Mutually exclusive with session_id. |
parent_run_id | uuid | Link this run as a child of another run (agent-to-agent), shown as a tree in the UI. |
stream | boolean | Stream tokens + tool events as they happen (see below). |
Pass stream: true to receive a text/event-stream of progressive events instead of a buffered JSON body — useful for chat UIs.
curl -N -X POST https://agentos-ai.dev/api/v1/agents/<agentId>/invoke \
-H "Authorization: Bearer aos_ws_…" \
-H "Content-Type: application/json" \
-d '{ "input": { "query": "…" }, "stream": true }'
Event types: chunk (token text), tool (a tool call's status), and a terminal done — or awaiting_approval (with approval_id) if the run pauses for approval, or error. Note: a ask_human pause currently resolves the stream as done; use buffered mode if you need to handle awaiting_input distinctly.
stream: true is incompatible with agents that have an output_schema set — streamed chunks would expose raw text before the JSON is assembled. Use buffered mode for structured-output agents.
If the agent calls an approval-gated tool or ask_human, the buffered invoke returns HTTP 202 with the run id and no output yet:
{ "data": { "run_id": "uuid", "awaiting_approval": { "approval_id": "uuid" }, "output": null }, "error": null }
{
"data": {
"run_id": "uuid",
"awaiting_input": {
"request_id": "uuid",
"question": "Which account should I charge?",
"options": ["Account A", "Account B"]
},
"output": null
},
"error": null
}
question is always present (show it to your user); options appears only when the agent offered choices.
Resume an approval from /approvals or the API; resume a human-input request by answering it from the run page or the API. The run then continues and reaches completed.
Same envelope as the rest of the HTTP API:
| Code | HTTP | Meaning |
|---|---|---|
UNAUTHENTICATED | 401 | Missing, invalid, or revoked key |
FORBIDDEN | 403 | Key scoped to a different agent, or no workspace |
NOT_FOUND | 404 | Agent (or parent_run_id) not found |
VALIDATION_ERROR | 400 | Bad body, or invoking a non-hosted / paused agent |
RATE_LIMITED | 429 | Too many requests |
See the HTTP API reference for the exact endpoint, and Hosted vs non-hosted for when to invoke vs ingest.