Supervisor + sub-agents with routing
The supervisor inspects each user message, picks an action (a specific sub-agent or supervisor itself for small talk), and runs it. routing_info in the chat response tells you which action was selected and why.
CatalogLatency ~2-5s for simple supervisor decisions; longer when a sub-agent uses RAG or runs a longer prompt Async false Rate Limit 60 req/min per API key Max Input Per sub-agent model context_window
cn8/agent
The Agent service runs multi-step AI workflows where a supervisor agent receives the user request and, at each step,
Learn more about Agent Chat & RAGsyncInstant previewagentllmautomation
Agent is built in your dashboard
Agents are configured, not prompted once — define your supervisor and sub-agents, wire up their collections and routing, then talk to the whole team through one endpoint.
1
Create an agent and its sub-agents
2
Configure routing, tools and collections
3
Chat with it from your app via core-agent-chat
No account yet? Start free — 100 credits, no card.
Overview
The Agent service runs multi-step AI workflows where a supervisor agent receives the user request and, at each step, routes to the right sub-agent based on the request intent and the sub-agent triggers (keywords/description). Sub-agents are specialists with their own action profile (persona, goal, response style), optional RAG over a collection, and their own model + temperature. The supervisor and sub-agents share a graph definition (you describe it during create / update). Ideal for customer-facing helper bots, support triage, and any flow that benefits from intent-based routing across multiple specialists.
Key capabilities
Rich sub-agent definition
Each sub-agent has trigger {keywords, description}, priority, action {persona, goal, response_style}, model_name, temperature, optional output_schema, and optional RAG (use_rag + collection_key).
Per-sub-agent RAG
Sub-agents can be RAG-enabled (use_rag:true + collection_key). When the supervisor routes a question to that sub-agent, it retrieves from the linked collection before answering.
Sync REST and Streaming SSE
Send via POST core-agent-chat for a full response. Add stream:true to the same endpoint for OpenAI-compatible SSE streaming (chat.completion.chunk events ending with [DONE]).
Conversations per agent
Agent calls open or continue conversation_key threads. List, inspect or delete via the agent-conversation endpoints.
When to use it
Helper bot for your customer base
A single supervisor serves your customers; routes by intent (FAQ, product, billing, technical) to dedicated sub-agents. Consistent tone, with escalation when needed.
Support triage
Incoming requests classified by intent and routed to billing / technical / general support sub-agents.
RAG over multiple knowledge bases
Different sub-agents can read from different collections — e.g., 'product-docs' for one sub-agent, 'help-center' for another. Supervisor picks the right one per question.
Mixed reasoning + retrieval
Combine sub-agents with RAG (knowledge questions) and sub-agents without RAG (general reasoning). The supervisor routes by intent.
Input & output
input
Agent configuration (name, system_message, model_name, temperature, optional collection_ids and per-sub-agent action profiles), and chat messages with optional conversation_key
JSON bodyPath parameters (agent_key, sub_agent_key, conversation_key)
output
Agent metadata, sub-agents (with trigger/action), graph state, and chat responses with routing_info and (optionally) sources
JSONSSE stream when stream:true
Guides & tips
When to use Agent vs Chatbot
- Chatbot: single LLM + RAG. Best for Q&A over a single knowledge base.
- Agent: supervisor + multiple sub-agents, each with its own action profile and (optional) RAG. Best when intents diverge enough that a single chatbot would overload its instructions, or when different sub-agents should hit different collections.
Routing through trigger and action
- trigger.keywords: word list the supervisor matches against the user message.
- trigger.description: free-text intent description; used by the supervisor to disambiguate when keywords overlap.
- action.persona: persona/role of the answering sub-agent (e.g. customer_support / friendly).
- action.goal: what the sub-agent should achieve (primary verb + instruction).
- action.response_style: format/tone/language for the response.
- Higher priority values are considered first when multiple sub-agents could match.
Per-sub-agent RAG
- Set use_rag:true and collection_key on a sub-agent to enable retrieval just for that specialist.
- The supervisor itself does NOT RAG; only the routed sub-agent does. The sub-agent retrieves from its collection_key, builds context, and answers.
- sources in the chat response is empty when no RAG sub-agent was selected, or when RAG returned no relevant chunks.
Field naming quirks (vs chatbot)
- agent_key is consistent everywhere: in the path for details/update/delete and in the request body for core-agent-chat. (Chatbot is inconsistent — uses chatbot_id only in the chat request body. Agent does not have that quirk.)
- sub_agent_key uses an underscore (matches the JSON field name) — not subagent_key.
- Prefixes: ag_ for agents, sa_ for sub-agents, cv_ for conversations, cl_ for collections.
- core-agent-graph is PUT (not GET / POST). Calling it with another verb returns 405.
Specs
Schema
Request body
agent_keyrequiredstringAgent identifier (ag_ prefix). Field name is consistent across the agent endpoints (unlike core-chat which uses chatbot_id).
messagerequiredstringUser message
conversation_keystringOptional cv_-prefixed key to continue an existing conversation. Omit to start a new one.
streamboolean · default: falseSet true to receive the response as SSE (OpenAI-compatible chunks).
Response
data.responsestringFinal user-facing response text.
data.agent_keystringEchoed agent_key (ag_ prefix).
data.conversation_keystringConversation identifier (cv_ prefix). Pass back to continue.
data.routing_infoobjectRouting decision: { selected_action ('SUPERVISOR' or 'SUB_AGENT'), action_name, reason, intent }.
data.frontend_triggerobjectOptional payload the agent emits to trigger frontend behavior (e.g. open a form).
data.data_collectionobjectOptional structured data the agent wants to collect from the user.
data.sourcesarrayRAG sources used by the selected sub-agent (empty when use_rag is false or no relevant chunks).
Pricing
Pay for create/update operations and chat. List, details, and delete are free.
| Service | Unit | Price |
|---|---|---|
| Create Agent | item | $1.0/agent |
| Update Agent / Update Graph / Add Sub-Agent / Update Sub-Agent | item | $0.5/operation |
| Chat (REST or SSE) | token | $0.001/call (currently flat — see note below) |
| List, Details, Delete | item | Free |
core-agent-chat streaming bills per token (2 credits per 1K); non-streaming calls currently bill a negligible flat amount until token metering lands there too.
Multi-step agent runs (supervisor + multiple sub-agent calls) do more underlying model work than a single LLM call — the current flat billing does not reflect this.