Overview
The Orchestration Engine is where workflow logic lives: what triggers a flow, what state it tracks across steps, when it requires a human approval, and what happens if a step fails. It is distinct from the Core Engine - the Core Engine reasons about a single request; the Orchestration Engine decides what sequence of requests, tool calls, and approvals make up a complete workflow.
Flows are versioned with full history and rollback. When an agent is deployed, the current version is locked; changes go to a new version and are deployed explicitly, so what's running in production is always traceable to a specific version.
Known path
Review path
Design principle
Branching paths always return to versioned evidence - so every run is owned, repeatable, and reversible.
How It Works
- Trigger - a flow starts from a call event, a cron schedule, an incoming webhook, or a chat/API request.
- Author - the flow is authored visually, with branching, conditions, loops, and tool-call nodes, or generated from a plain-English description via the NL builder.
- Configure - connector instances are assigned to tool-call nodes, and escalation/approval rules are configured per node.
- Deploy - the current flow version is locked and deployed; live traffic runs against this version only.
- Execute - on each interaction, the engine evaluates the current node, dispatches tool calls, enforces approval gates, and handles retries.
- Record - the outcome, transcript, and sentiment are written to the database on completion.
Exceptions, Retries & Auditability
| Capability | What it does |
|---|---|
| HITL gates | Human approval required for actions above the configured risk threshold - enforced at the orchestration layer, not in application code. |
| Retries & compensation | Failed tool calls retry with configurable back-off; compensation logic handles partial completions. |
| Version history | Every flow change is tracked with a full diff between any two versions. |
| Rollback | Revert to a previous version instantly without a redeployment pipeline. |
| Multi-agent coordination | One agent can delegate a subtask to another agent for complex, multi-step workflows. |
Illustrative Example
The following is illustrative, not a specific deployment.
A workflow collects information from a caller, checks whether the requested action (e.g. a refund above a threshold) requires approval, routes it to a human reviewer if so, and - once approved - dispatches the authorised action to the connected system. If the connector call fails, the engine retries with back-off; if it still fails, the flow records a partial-completion outcome rather than silently reporting success.
FAQ
Is this a no-code tool with no limits?
Flows can be authored visually or via natural language, but every flow still runs inside the platform's defined node types (branches, conditions, tool calls, approval gates) - it is not an unconstrained no-code builder.
How is an approval gate enforced?
At the orchestration layer, per flow node - the action does not execute until the configured approver responds.
What happens if a flow version has a bug in production?
Roll back to the previous version in one click; the previous version becomes live without a redeployment pipeline.
Can multiple agents coordinate on one task?
Yes - one agent can delegate a subtask to another agent as part of a multi-step workflow.
Does this replace the reasoning layer?
No - it coordinates around it. Reasoning happens in the Core Engine; this layer decides the sequence, approvals, and retries.
Related
- Core Engine - the reasoning runtime that executes each flow node
- Voice Engine - the voice pipeline that triggers flows on each call
- Security & Governance - HITL gates and RBAC on flow deployment
- UK AI Platform hub - all 8 component pages