You don’t have to move anything.
The same definition deploys to your own cluster or to any of the three hyperscaler agent runtimes. A team that picked a cloud two years ago keeps it. You still get one place that can answer for all four.
The same runtime lands on all four.
What gets deployed is a standard PromptKit package and the compiled pack, the same two things whatever the target. Guardrails, redaction and in-process evaluation are the runtime’s job, so they hold wherever it lands.
Traces come back over OTLP, straight to your control plane, without touching the host cloud’s telemetry on the way. The plane itself never leaves your cluster.
One pack is deployed by four open adapters to four runtimes. Guardrails, redaction and in-process evaluation run on the agent itself, wherever it landed. Each agent then pushes its telemetry over OTLP back to the Omnia control plane, which always runs in your own cluster.
The deployers are open source and the interface is public, so a target we don’t cover is one you can add.
Every agent you’re running, wherever it runs.
The ones in your cluster, the ones on Bedrock, the one somebody started on Vertex last quarter. They come up in one list with a version and a status against each, and you can open any of them without changing console.
The table below names what doesn’t follow an agent onto someone else’s platform: rules on tool arguments are Omnia’s own today, and the memory tiers are whatever that platform gives you.
Not everything travels.
Everything works in your own cluster. If your organisationorganization’s already picked a cloud, most of it still does. Here’s what doesn’t.
| Capability | Your cluster | AgentCore | Vertex | Foundry |
|---|---|---|---|---|
| Guardrailsin-process on the runtime | available | available | available | available |
| Redactionbefore the model, the recording and the memory write | available | available | available | available |
| Evaluationon the agent, or on the plane against its telemetry | available | available | available | available |
| Telemetry and auditpushed to your plane over OTLP | available | available | available | available |
| Modelsany provider, including the host’s own | available | available | available | available |
| Tool policyrules on the arguments, not only the tool | available | pending | pending | pending |
| Self-hosted toolstools that live inside your network | available | pending | pending | pending |
| Multi-tier memoryfour tiers, with a precedence rule | available | pending | pending | pending |
| Agent-to-agentone agent’s skills as another’s tools | available | pending | pending | pending |
| Progressive rolloutcanary, blue/green, sticky sessions, self-firing rollback | available | not supported | not supported | not supported |
| Voiceduplex speech, in and out | available | not supported | not supported | available |
| Concurrencymany sessions per instance, autoscaling | available | not supported | not supported | not supported |
Pending is our gap: the runtime could carry it and we haven’t built it yet. Not supported is the host’s, and there’s nothing for us to build.
This table will change. The hyperscalers keep shipping agent capabilities and we pick them up where they’re worth having, so cells move from pending to available. Our own new work usually starts as pending too. When a cell changes, this table is where it changes.