Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.orq.ai/llms.txt

Use this file to discover all available pages before exploring further.

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:
curl -X POST https://api.orq.ai/v2/agents/my-agent/responses \
  -H "Authorization: Bearer $ORQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "background": false,
  "message": {
    "role": "user",
    "parts": [
      {
        "kind": "text",
        "text": "Help me plan a microservices architecture for our e-commerce platform."
      }
    ]
  }
}'
With background: false (default), the call waits for the agent to finish and returns a completed task object including an output array:
{
  "id": "01K6D8QESESZ6SAXQPJPFQXPFT",
  "contextId": "0ae12412-cdea-408e-a165-9ff8086db400",
  "kind": "task",
  "status": {
    "state": "completed",
    "timestamp": "2025-09-30T12:14:35.123Z",
    "message": {
      "role": "agent",
      "parts": [{ "kind": "text", "text": "Here's a microservices architecture..." }]
    }
  },
  "output": [
    {
      "parts": [{ "kind": "text", "text": "Here's a microservices architecture..." }]
    }
  ],
  "metadata": {
    "orq_agent_key": "my-agent"
  }
}
Set background: true to return immediately without waiting: the response will have status.state: "submitted" and no output. Use the returned id to continue the conversation.

Pass Variables

Pass variables in the variables field of the execution request:
curl -X POST https://api.orq.ai/v2/agents/my-agent/responses \
  -H "Authorization: Bearer $ORQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message": {
      "role": "user",
      "parts": [{"kind": "text", "text": "I need help with my account."}]
    },
    "variables": {
      "user_name": "John Smith",
      "user_role": "admin",
      "company_name": "Acme Corp"
    }
  }'
To define which variables the agent uses and configure templating, see Build Agents: Variables and Templates.

Attach Files

Attach files in the parts array of the message:
  • Images: Via URL (uri) or base64 encoding (bytes)
  • PDFs: Base64 encoding only (bytes). URI links are not supported for PDFs.
  • MIME Types: Required. Specify the correct mimeType (e.g. image/jpeg, application/pdf).
Verify the chosen model supports the file types in use. Vision models are required for image and PDF processing.
Attach an image via URL:
curl -X POST https://api.orq.ai/v2/agents/image-classifier/responses \
  -H "Authorization: Bearer $ORQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "message": {
    "role": "user",
    "parts": [
      {
        "kind": "text",
        "text": "What can you see in this image?"
      },
      {
        "kind": "file",
        "file": {
          "uri": "https://example.com/image.jpg",
          "mimeType": "image/jpeg",
          "name": "image.jpg"
        }
      }
    ]
  }
}'
Attach a PDF via base64: Convert the file to base64 first:
Python
import base64

def file_to_base64(file_path: str) -> str:
    with open(file_path, "rb") as file:
        return base64.b64encode(file.read()).decode("utf-8")

pdf_base64 = file_to_base64("path/to/document.pdf")
Then include it in the message:
{
  "kind": "file",
  "file": {
    "bytes": "<base64-encoded-content>",
    "mimeType": "application/pdf",
    "name": "document.pdf"
  }
}

Continue a Task

After receiving a task response, continue the conversation by passing the previously received task_id in the next request. The agent maintains full context from previous exchanges.When polling task state, a task in input-required state means the agent is waiting and ready for continuation (the agent is in inactive state). Pass the same task_id to resume.
curl -X POST https://api.orq.ai/v2/agents/my-agent/responses \
  -H "Authorization: Bearer $ORQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "task_id": "01K6D8QESESZ6SAXQPJPFQXPFT",
  "background": false,
  "message": {
    "role": "user",
    "parts": [
      {
        "kind": "text",
        "text": "Can you expand on the challenges section?"
      }
    ]
  }
}'
The continuation returns a new task 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.
curl -X POST https://api.orq.ai/v2/agents/agent-memories/responses \
  -H "Authorization: Bearer $ORQ_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
  "memory": {
    "entity_id": "customer_456"
  },
  "message": {
    "role": "user",
    "parts": [
      {
        "kind": "text",
        "text": "Do you remember what is my name?"
      }
    ]
  }
}'
You can use multiple memory stores per call, ensure that the entity_id sent during the calls maps the same way to all previously declared memory stores during agent creation.

Schedule Agents

Run an agent on a recurring or one-off 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 UTC, Summary, Input, Variables, and Metadata fields.
FieldDescription
NameA display label for the schedule in the UI. Required. Not sent to the agent.
FrequencyHourly, Daily, or Weekly.
Time (UTC)The hour the schedule fires. Shown for Daily and Weekly.
Pick the dayDay of the week to fire. Shown for Weekly only.
SummaryAuto-generated human-readable description of the schedule.
InputThe user message sent to the agent on each firing. Required, since every agent invocation needs a user message.
VariablesKey-value pairs passed to the agent on each run. See below.
MetadataKey-value pairs attached to every response this schedule generates. See below.
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.

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.
curl -X POST https://api.orq.ai/v3/agents/ops_digest/schedules/{schedule_id}/execution \
  -H "Authorization: Bearer $ORQ_API_KEY"
Returns 202 Accepted with:
{
  "status": "triggered",
  "schedule_id": "01KPN29WWKSK0VDPJNTKZPVNRB"
}
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.

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:
StateDescription
ActiveExecution in progress; continuation requests blocked
InactiveWaiting for user input or tool results; ready for continuation
ErrorExecution failed; continuation blocked
Approval RequiredTool execution requires manual approval (coming soon)
Task states:
StateDescription
SubmittedTask created and queued for execution
WorkingAgent actively processing
Input RequiredWaiting for user input or tool results
CompletedTask finished successfully
FailedTask encountered an error
CanceledTask was manually canceled

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.
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.