THE STACK
Our AI agent orchestration platform is eleven layers, and none of them is a product we resell. This page names each layer, says what it does, and says why we chose that shape. Where a vendor appears, it is an example of a category.
What an AI agent orchestration platform actually is
An AI agent orchestration platform is the layer that turns several autonomous agents into one working system: it plans the work, dispatches each task to the agent that owns it, holds shared state, retries what fails, enforces what each agent may touch, and records all of it.
Most teams discover they need one on the day their second agent ships. One agent is a script with good manners. Two agents with a shared inbox is a distributed system, with all of the ordering, retry and partial-failure problems that phrase implies.
Everything below sits under a single rule: capability categories, not a fixed vendor list. Any specific tool we name today will be a different tool within a year, and the architecture has to outlive that.
Eleven layers, and why each one is shaped this way
Models
Multi-provider by default, with the right model chosen per task rather than per company. Routing decisions run on measured quality against our eval suite, latency and cost per task, not on brand preference. A classification step that a small model handles at a fraction of the price does not get a frontier model because a frontier model is what the demo used. Why this matters to you: your cost per task falls over time instead of being fixed on the day you signed.
Retrieval and knowledge
Chunking tuned to your document shapes, embeddings, hybrid search that combines dense and keyword retrieval, a re-ranking pass, and citations on every answer. Permissions are applied at retrieval, so an agent answering a question can only see what the person it is answering for could see. Why this matters to you: wrong answers are usually a retrieval failure, not a model failure, and this is the layer that fixes them. Deeper: RAG and knowledge systems
Memory and context
Three kinds, kept apart on purpose: short-term working state for the current task, episodic memory of what this agent has already done, and an organizational knowledge layer that outlives any single run. Context is budgeted per call rather than stuffed, because a bloated context window is both the slowest and the least accurate way to run an agent. Why this matters to you: an agent that remembers the last three tickets from the same customer behaves like a colleague rather than a form.
Orchestration
A planner that decomposes a process into tasks, a durable task queue, explicit handoffs between agents, retries with backoff, compensation for partial failure, and long-running work that survives a restart. Every task carries a correlation id from intake to outcome. Why this matters to you: processes finish. Without this layer, one failed step quietly strands the work and nobody finds out until a customer asks. Deeper: Agent orchestration
Tools and gateway
Agents never hold raw credentials. Every tool call goes through a gateway that holds the secrets, applies per-agent permissions, rate-limits, validates arguments against a schema and logs the call. Adding a tool is a permission grant, not a code change inside the agent. Why this matters to you: you can answer “what could this agent possibly do?” by reading a list, not by reading its prompt.
Evals
Offline suites built from your real cases, live sampling against those suites in production, and drift alarms when the pass rate moves. Evals are written at the blueprint stage and are the gate for every model swap. Why this matters to you: it is the difference between knowing the system still works and assuming it. Deeper: Fine-tuning and evaluation
Fine-tuning and distillation
Used when prompting has hit a ceiling, when a task is narrow and high-volume, or when a smaller model would clear the bar with training it cannot get from instructions. Not used because it sounds serious. For most tasks, better retrieval and a tighter prompt beat a tuned model at a fraction of the effort. Why this matters to you: we will talk you out of a fine-tune more often than into one.
Observability
Traces spanning the whole process rather than one model call, cost attributed per task and per agent, latency percentiles, tool-call outcomes and a dashboard your team can read without us. Any single output can be reconstructed from its trace months later. Why this matters to you: when someone asks why an agent did that, the answer takes minutes.
Data engineering
Pipelines with a defined freshness contract, vector stores, permission models carried through from the source system, and PII detection and handling before anything is indexed. Retrieval quality is a data problem long before it is a model problem. Why this matters to you: the agent reads the right data, at the right age, and never sees what it should not. Deeper: Data engineering for AI
Deployment
Your cloud, our cloud, or a split where inference runs in your tenancy and orchestration runs in ours. The architecture is the same in all three, which is what makes the choice yours rather than ours. Why this matters to you: data residency stops being a negotiation.
Security
Secrets held in a managed store and never in a prompt, network isolation between agents and your systems, scoped credentials per agent, and a kill switch that stops a single agent or the whole hive without a deployment. Why this matters to you: the blast radius of a misbehaving agent is a decision you made in advance. Deeper: How we govern all of this
PLAIN ABOUT THIS
Where vendors fit
We name categories on this site, not a delivered vendor list. When a card above says “a managed secret store”, the category is the commitment and the specific product is a build-time choice made with your security team. The same is true of model providers, vector stores, queues and tracing backends.
That is not evasion. A vendor list on a marketing page ages within a quarter, and worse, it reads as a claim that we have already built against every name on it. What we will do on a call is walk through the exact components we would propose for your environment, and why.
How the layers fit together
A single static diagram, described in text below it for anyone who cannot see it. Request enters at intake, the planner decomposes it, the task queue dispatches to agents, each agent reaches the gateway for tools and retrieval, every step writes to the trace and audit log, and the escalation path exits to a person.
text description (rendered, not alt alone)
Work arrives at intake and becomes a task graph. The planner assigns each task to the agent that owns it. Agents reach data through retrieval and reach systems through the tool gateway, which holds every credential. Each action writes a trace and an audit entry. Anything outside an agent’s boundary leaves the graph and arrives with a person, context attached.
HONESTLY
The honest limits
This is not a product you can log into. There is no self-serve tier and no free trial, because every one of the eleven layers above is configured against your systems, your data and your risk appetite.
It is also not model-agnostic in the marketing sense. Swapping a model is a routing change plus an eval run, and if the new model fails the suite it does not ship. That is a deliberate constraint, and it is the reason a swap is safe.
And we do not run your infrastructure unless you ask us to. Plenty of clients take the whole stack in-house after stage 6, which is why the runbooks are written for a reader who is not us.
The same stack, twenty-four ways
Every agent in the library runs on these eleven layers. What changes per agent is the tools it may reach, the data it may read and the boundary it works inside. Nothing else is bespoke.
How we build it, stage by stage · All 19 services
Who builds and runs it, and how we think about autonomy: About URU Forge.