Agent Orchestration
Multi-step execution, tool calls, and retry — handled inside the engine, not in your application code.
The orchestrator runs inside the engine on every intent call — invisible to callers. It decides whether to use single-shot or multi-step agentic execution, which tools to invoke, and how many reasoning steps to take. You call an intent; you never manage prompts, tool schemas, or agent loops directly.
What the engine handles
Automatic mode selection
Inspects intent complexity and routes to single-shot or multi-step execution automatically.
Managed tool registry
Tools are pre-registered per domain — DB lookups, document retrieval, scoring functions, external APIs.
Built-in error recovery
Retry logic, exponential backoff, and fallback paths are handled at the engine layer.
Full execution trace
Every call returns steps taken, tool calls made, latency per step, and agent mode used.
Agent Runtime API
Beyond per-intent orchestration, you can define standing agents — configured entities with their own capabilities, tools, and memory — and run them directly via the Agent Runtime API.
Two doors, one agent
Agents are reachable both from the dashboard (JWT-authenticated, below) and from your own backend via API key (/v1/agents — see Agents API Reference). Both call the same underlying service, so an agent created, deployed, or run through either one is immediately consistent through the other.
Dashboard (JWT)
GET /dashboard/agent-runtime # list agents
POST /dashboard/agent-runtime # create an agent
GET /dashboard/agent-runtime/:agentId # get an agent
PATCH /dashboard/agent-runtime/:agentId # update an agent
POST /dashboard/agent-runtime/:agentId/deploy # activate the agent
DELETE /dashboard/agent-runtime/:agentId # delete an agent (soft — sets status to inactive)
POST /dashboard/agent-runtime/:agentId/run # run the agent
GET /dashboard/agent-runtime/:agentId/runs # list runs
GET /dashboard/agent-runtime/:agentId/runs/:runId # get a run + its stepsAPI key
GET /v1/agents # flat catalog of active agents
POST /v1/agents # create an agent (draft status)
GET /v1/agents/:agentKey # get an agent
PATCH /v1/agents/:agentKey # update an agent
POST /v1/agents/:agentKey/deploy # activate the agent
DELETE /v1/agents/:agentKey # delete an agent (soft — sets status to inactive)
POST /v1/agents/:agentKey/run # run the agent
GET /v1/agents/:agentKey/runs # list runs
GET /v1/agents/:agentKey/runs/:runId # get a run + its steps
GET /v1/agents/:agentKey/sessions # list sessions
GET /v1/agents/:agentKey/sessions/:sessionId/transcript # full conversation transcriptAgents are created in draft status — use the deploy endpoint to activate one for execution; setting status: "active" directly via update is rejected (409 DEPLOY_REQUIRED). Full field reference: Agents API Reference, or use the JavaScript or Python SDK.
Run an agent:
POST https://api.liyaengine.ai/dashboard/agent-runtime/agt_01HZ.../run
Authorization: Bearer <jwt>
Content-Type: application/json
{
"input": { "message": "Summarize open tickets from the last 24 hours" }
}Response:
{
"success": true,
"data": {
"run_id": "run_01HZ...",
"session_id": "ses_01HZ...",
"status": "completed",
"output": "Here's a summary of tickets opened in the last 24 hours...",
"steps": 2,
"total_cost": 0.0043,
"total_latency_ms": 480
}
}output is the agent's final text response, and steps here is just a count. Each run is persisted with its full step-by-step execution graph — step_number, type (llm_call / tool_execution), tool_name, tool_input/tool_output, cost, latency_ms per step — queryable via GET .../runs/:runId, the same data the dashboard's Agent Runtime UI renders.