The brain that bridges understanding and execution
Deterministic plans. Secure handoffs. Every source checked.
The Orchestrator is the deterministic core of Interactor Agent OS. It reads intent from UKB, pulls memory and data from UDB, finds the right tool in SKB, and asks Auth Manager for the right credentials — then runs every step in a plan you can audit. It is the difference between an AI that talks and an AI that ships work.
How the Orchestrator sits in Agent OS
Plans use UKB + UDB. Tools come from SKB. Credentials come from Auth Manager.
Why an LLM alone never makes it to production
Three failure modes that quietly kill agent quality.
When the model picks which sources to query, it skips the ones that matter on the third Tuesday of every month.
Sub-agents spawned in the browser share the same token. One prompt injection and the whole org is exposed.
Unstructured chat memory gets summarized and silently loses the only number the agent needed to act.
What the Orchestrator does
Four jobs that turn an LLM into a working agent.
Deterministic plans, not vibes
Every request resolves to an auditable plan: which sources to check, which tools to run, in which order, with which credentials. The plan is logged, replayable, and never depends on the model 'remembering.'
Server-side handoff with credential isolation
Specialists are spawned server-side. Each one gets only the credentials and scope it needs for its step. Prompt injection in a sub-agent can't escalate beyond its slice.
State machine + parallel threads + halts
Long-running work runs as a workflow with explicit states, parallel threads, and halts for human approval. Survives restarts, retries, and partial outages.
Graceful degradation when pieces fail
Each Agent OS piece fails independently. When a connector is down, the Orchestrator falls back to a generic-but-functional path and tells you what was skipped — instead of silently dropping the capability.
From request to result
The four-step cycle, every time.
Understand
Resolve intent against UKB business definitions and UDB memory. Identify what the user really means.
Plan
Build an auditable step plan: sources to check, tools to call, credentials per step.
Execute
Run server-side. Each specialist gets isolated credentials. Parallel where safe, sequential where required.
Validate
Confirm every source was checked, persist structured state to UDB, log every transition for replay.
Orchestration honestly compared
What you get out of the box vs. what the alternatives leave you to build.
| Capability | Interactor | ChatGPT / Cowork | Build from scratch |
|---|---|---|---|
| Deterministic execution plan | Yes — auditable | No — LLM decides | Yes — 1+ month |
| Secure agent-to-agent handoff | Server-side, isolated | Client-side, shared token | Yes — 3+ months |
| Graceful degradation | Built in | Capability disappears | Depends on architecture |
| Embeddable in your product | Multi-tenant, API-first | Standalone app only | That's the whole point |
| Time to production | Weeks | N/A — not embeddable | 12–18 months |
Want to see it run on your stack?
We'll wire the Orchestrator to one of your real workflows and show you the plan, the handoffs, and the audit log.
