Skip to main content
Execute agents already configured. For building and configuring agents, see Build Agents.

Run Agents

For Python and Node.js client libraries, see Orq SDKs.
Send a message to an agent using the Responses API:
The call waits for the agent to finish and returns a completed response object:

Streaming

Set stream: true to receive incremental output as server-sent events. The response arrives in chunks as the Agent produces it.
The stream emits server-sent events as the agent produces output:

Pass Variables

Pass variables in the variables field of the execution request:
To define which variables the agent uses and configure templating, see Build Agents: Variables and Templates.

Attach Files

Attach files in the content array of an input message item:
  • Images: Via URL (image_url). For base64-encoded images, also set mime_type (e.g. image/jpeg).
  • PDFs: Data URI only (file_data). Pass the file as data:application/pdf;base64,<base64-data>. URL links are not supported for PDFs.
Verify the chosen model supports the file types in use. Vision models are required for image and PDF processing.
Attach an image via URL:
Attach a PDF via base64:

Continue a Conversation

After receiving a response, continue the conversation by passing the previously received response id as previous_response_id in the next request. The agent maintains full context from previous exchanges.
The continuation returns a new response id for the extended conversation. The agent retains full context from all prior turns.

Use Memory Stores

To call the Agent with a memory store, we’ll use the Responses API with an Embedded message and Linked memory.
Multiple memory stores per call are supported. Ensure the entity_id sent during the calls maps the same way to all previously declared memory stores during agent creation.

Attach Metadata

Attach arbitrary key-value pairs to a response using the metadata field. Metadata is stored on the response and visible in traces. Use it to tag runs by session, user, environment, or any other dimension useful for filtering in Observability. Values must be strings.
The metadata is returned on the response object:

Use Tools

Pass tools in the tools array of any Responses API call. Multiple tools of different types can appear in the same request. Each tool type supports Inline (definition embedded in the request) or Pre-saved (created once in Studio, referenced by ID). HTTP and Built-ins are pre-saved or platform-managed only.
Define a custom function schema. The model decides when to call it, fills the parameters, and returns a function_call output item. Choose Inline to embed the schema in the request, or Pre-saved to reuse a schema stored in Studio.
Define a function schema inline. The model decides when to call it, fills the parameters, and returns a function_call output item. The application executes the function and sends the result back.Step 1: Send the request with a function tool:
The response contains a function_call output item when the model decides to use the tool:
The model only emits a function_call item when it decides to use the tool. Check output[0].type === "function_call" before proceeding to Step 2; if the model answered directly, read the text from response.output[0].content[0].text instead. Pass tool_choice: "required" to force a tool call.
Step 2: Execute the function and return the result:Pass previous_response_id and a function_call_output input item with the matching call_id. Include the same tools array so the model can make additional calls if needed.
Function tool fields:
Connect to any MCP-compatible server. This lets the agent read from and write to external services like Linear, Slack, or GitHub without writing any integration code. Choose Inline to supply the server URL per-request, or Pre-saved to reference a saved server by key with credentials stored on the platform.
Supply the MCP server URL directly in the request. The tool catalog is fetched from the server on each call. Use for one-off calls or when the server has not yet been saved under Tools. Provide server_url (inline) or key (pre-saved), not both.
Per-request credentialsUse {{variable}} placeholders in headers and supply values at call time. The secret: true wrapper keeps token values out of traces and logs:
server_url must use http or https and be reachable from Orq.ai. URLs whose host resolves to a loopback, link-local, private (RFC 1918), unspecified, or cloud-metadata address are rejected.
Reference an HTTP tool saved in Studio using orq:http and its tool_id. Orq.ai executes the HTTP request against the configured endpoint and returns the result to the model. No execution logic needed in the application.Add timeout (seconds, 1 to 600) to the tool reference to override the request timeout configured on the tool for this call. Tool references in agent settings accept the same field to set a per-agent override.
To create and manage HTTP tools, see Create Tools.
Orq.ai includes platform-managed tools that require no configuration. Reference them by type alone. No credentials or execution logic needed in the application.
Built-in tools execute automatically on Orq.ai infrastructure. Results are fed back to the model within the same request; no function_call_output round-trip needed.

Control Tool Calls

Controls whether and which tool the model calls. Applies to all tool types.
Default when tools are present. The model decides on each turn whether to call a tool or answer directly. Use this for conversational agents where tool use is situational.
The model must call at least one tool before producing a final response. Use when a tool call is always necessary: for example, a retrieval step before every answer.
The model must not call any tool. Tools remain present in the request (the model can see their schemas) but cannot invoke them. Use to temporarily disable tools without removing them from the request.
Force the model to call one named function. Pass { "type": "function", "name": "<function name>" }, replacing <function name> with the exact name from the tool definition. Use when the application must extract structured data from a known function schema.

Filter Tools

MCP servers can expose dozens of tools. Use allowed_tools on any MCP entry (inline or pre-saved) to narrow what the model sees. Tools outside the filter are invisible to the model and cannot be invoked. allowed_tools applies only to MCP tools; it has no effect on function, HTTP, or built-in tools.
Expose only the listed tools by name. The model cannot see or call any tool not in the list.
Expose only tools the server marks as readOnlyHint: true. Use to prevent the model from calling any mutating operations. The server must annotate tools with readOnlyHint for this filter to have effect.
Intersection filter: expose only tools that are both read-only AND in the named list.

Streaming Events

Set stream: true on any request with tools. See Streaming for setup and base event shapes. For function tools, act on response.output_item.done: it carries the complete function_call item with arguments and call_id ready for Step 2. MCP server calls also emit three additional events: MCP output items use type: "mcp_call". Function tool output items use type: "function_call". Match on type when processing output on the client.

Observability

Every tool invocation appears in traces as a child span of the agent loop. All tool spans: MCP spans only:

Error Reference

HTTP 400, type: "invalid_request"The server_url uses a bad scheme or resolves to a disallowed address (loopback, link-local, private RFC 1918, unspecified, or cloud-metadata).
HTTP 400, type: "invalid_request"The key passed in the request does not match any tool saved in the workspace.
HTTP 400, type: "invalid_request"The MCP server rejected the connection during the initialization handshake.
HTTP 400, type: "invalid_request"The MCP server was not reachable or returned a malformed response during tool discovery.
HTTP 500, type: "internal_error"An unexpected error occurred on the Orq.ai side. Retry with exponential backoff.
HTTP 200, output item with status: "failed"The tool call was routed successfully but the tool itself raised an error. The overall HTTP response is 200 because the request succeeded; inspect output[n].output for the error detail.

Limits

Schedule Agents

Run an agent on a recurring cadence without holding open an HTTP connection. Each scheduled run follows the same execution path, tracing, and billing as a direct API call.

Create a Schedule

Open the agent and go to the Schedules tab. Click New schedule to open the form.
Agent schedule creation form showing Name, Frequency toggle with Hourly, Daily, and Weekly options, Time, Summary, Input, Variables, and Metadata fields.

Create a new schedule from the Schedules tab on an agent.

VariablesUse the Variables section to define values that the agent needs on each run. Variables are sent alongside the input as a distinct payload field, and can be consumed by the agent’s instructions, any configured tool, or a subagent wherever the variable is wired up.
For example, a support agent with an HTTP tool that looks up a customer in an external system can receive customer_id=1234 from the schedule and use it to query the right record on every run. See the screenshot below.
Variables cannot be referenced inside the Input field itself. Wire them into the agent’s instructions, a tool, or a subagent instead.MetadataUse the Metadata section to attach arbitrary key-value pairs to every response generated by this schedule. Metadata is not passed to the agent: it is stored on the trace and can be used to filter traces in Observability, identify which schedule triggered a run, or tag responses for downstream processing.Click Create to activate the schedule. It starts firing at the next matching time.
A saved agent schedule entry showing the schedule name, frequency, next run time, and the configured variables and metadata key-value pairs.

A created schedule showing configured variables and metadata.

List & Retrieve

All schedules for the agent are listed in the Schedules tab. Click a schedule row to open its details, including trigger count and last fired time.

Pause and Resume

Click on the schedule row, then click Enable to toggle the schedule on or off. Field edits saved while paused take effect on the next active run.

Trigger On Demand

Runs the schedule’s payload immediately without affecting its regular cadence. Useful for smoke-testing a new schedule or manually re-running a missed execution.
Returns 202 Accepted with:
The run appears in traces as a schedule.<agent_key> leading span roughly 10 seconds later, carrying orq.schedule_id and the full agent execution chain. Schedule-driven cost and token usage appear in usage reports alongside HTTP-invoked runs. Inactive schedules return 400 schedule_inactive.

Delete

Click on the schedule row, then click Delete. The action is immediate and permanent.

Examples

memory_entity_id attaches a Memory Store entity to every run. The agent can read from and write to the store on each firing, accumulating context across executions.
Secret values are redacted from traces and stripped from the stored payload’s observable form.

Agent and Task States

Agent execution can take a long time. If the agent appears to be hanging, it is most likely still running. Wait and check the panel again later.
Agent states:Task states:

Multi-Agent Workflows

Multi-agent workflows are configured at the agent level. Each agent in a team is created individually, then the orchestrator references sub-agents through its team_of_agents configuration.The Description field on each sub-agent is critical: orchestrators use it to decide when to delegate.
To configure multi-agent setups, see Build Agents: Instructions for how to write descriptions that enable effective delegation.

Traces

The Traces tab in the agent page shows execution logs filtered to the agent automatically.
Traces tab for the bank_creditcard_agent showing a list of invoke-agent runs with timestamps, duration, and cost, filtered to this agent.

Agent-specific traces with automatic filtering.

Trace data includes:
  • Execution history with timestamps
  • Input and output for each call
  • Token usage and cost per execution
  • Execution duration and performance metrics
  • Errors and debugging information
  • Tool calls executed (function, HTTP, code, or MCP calls)
  • Knowledge retrieval results and RAG context
  • Memory store interactions

Trace Views

Each trace can be inspected in three views:
The Trace view shows the full execution tree for a single agent run. Each step is displayed hierarchically, including LLM calls, tool invocations, knowledge retrievals, and memory interactions.
Trace view showing the single-product-agent span tree with nested invoke-agent, gpt-4o chat-completion, and current_date spans, with properties panel on the right.

Creating Custom Views

Save frequently used filter combinations as reusable views:
  1. Set the desired filters.
  2. Click All Rows (top right).
  3. Select Create New View.
  4. Give the view a title.
  5. Optionally check Set view private (default is shared with project members).
For advanced filtering and cross-agent analysis, see Traces.