Use a CRHQ instance as your product's agent runtime — sessions, agents, skills and streaming through a scoped API.
CRHQ isn't only an operator console — it's an agent runtime your product can build on. If your app needs AI agents that hold long conversations, execute skills, delegate work and stream output, you can drive a CRHQ instance through its API instead of building that machinery yourself.
| Capability | What it means for your product |
|---|---|
| Sessions | Durable agent conversations with full history, status, and cost tracking |
| Agents | Register an agent once (instructions + skills + model); every session bound to it inherits the full setup |
| Skills | Your agent can use every skill installed on the instance — delegation, scheduling, artifacts, browsing |
| Queueing & concurrency | Two requests can never start two turns on one session; the platform queues, parks and drains safely |
| Restart resilience | If the instance restarts mid-turn, every in-flight session auto-resumes |
| Model management | Subscription rotation across accounts, model selection and cost attribution are handled below your API calls |
| Streaming | Token-by-token output over WebSocket, with buffered replay across reconnects |
Your product talks to one CRHQ instance with a scoped API key — a credential limited to the session lifecycle. It cannot touch the instance's settings, credentials, or other tenants' data.
Your product (web app, SaaS, internal tool)
│ scoped key: sessions:write + sessions:read
▼
CRHQ instance ── sessions ── agents ── skills ── models
Because an agent turn runs real tools, a scoped key is pinned to the specific agents it may run — so a product can only ever execute the agent you designed for it. See Scoped API Keys.
A typical flow:
The full endpoint-by-endpoint contract is in the Integration API Reference.
GeneratePRD — a PRD-writing SaaS — runs its intake interviews and document generation entirely on a CRHQ instance. Its backend is a thin adapter over six CRHQ endpoints; everything agentic (the interview agent, the generation pipeline, delegation between agents, skill execution) is native CRHQ. The product's users never see CRHQ — they see the product.
The v1 surface covers the session lifecycle. Planned extensions, driven by real products building on CRHQ:
agents:manage / skills:manage / jobs:manage scopes — create and update agents, skills, and background jobs programmatically, so your product's "agents" and "skills" features are CRHQ-native instead of a parallel system you have to build and maintain.If you're building on CRHQ and hit a wall the API doesn't cover, tell your instance operator — this surface grows from real integration needs.