A runtime can stop an agent from overspending or running a forbidden command. It cannot tell that agent which policy governs the table it just queried. Atlan’s context layer for AI fills that gap by serving definitions, ownership, and lineage from an Enterprise Data Graph over MCP, so the runtime keeps control of execution and the agent gets the meaning of the data from a layer that no single harness or host owns.
The runtime has four parts to understand:
- Server: The coordinator that stores sessions, tool calls, skills, and policies and handles authentication.
- Runner: The per-session process that launches the harness, runs tools, and streams events back to the server.
- Host: The machine or sandbox where a runner executes, from a laptop to a Databricks Sandbox.
- UI: The browser, terminal, desktop, mobile, or REST API surface, which never talks to the runner directly.
| What it is | The execution layer for agents defined in Omnigent, an open-source meta-harness released under the Apache 2.0 license |
| Components | A server, a per-session runner, and a UI; only the server needs deployment |
| Where agents run | Your machine, a self-hosted server, a cloud sandbox host, or a Databricks Sandbox |
| Managed option | Omnigent on Databricks, currently in Beta, with a Databricks-operated server |
| What it controls | Which harness runs, which tools are reachable, which actions need approval, and what the agent can see on disk and network |
| What it does not supply | Definitions, owners, lineage, and data policy from your systems of record |
Why does Omnigent need a runtime at all?
An Omnigent agent is a definition, and a definition does nothing until something executes it. According to the Omnigent project (2026), Omnigent is an open-source meta-harness: a common orchestration layer over coding agents such as Claude Code, Codex, Cursor, OpenCode, Hermes, and Pi. Custom agents are declared in a short YAML file that sets the executor, the model, the prompt, the tools, and the policies.
That split matters because teams now pick their own agent harnesses, and the choice rarely stays uniform across a company. A meta-harness gives security and platform teams one place to apply rules, while the difference between a harness and a framework stays an engineering decision made per team. The runtime is what turns the YAML into a running session, and it is where the policies and isolation you configured take effect. For the product-level view, the sibling guide on what Databricks Omnigent is covers the meta-harness idea itself.
Teams that treat the runtime as an afterthought tend to hit the failure modes catalogued in agent harness anti-patterns: unbounded loops, tools nobody approved, and sessions nobody can reconstruct. The runtime exists to make those failures visible and bounded.
What does the Omnigent runtime architecture look like?
According to the Omnigent documentation (2026), Omnigent has three components: the server, the runner, and the UI. Only the server needs deployment. Runners attach to it from hosts, and UIs connect to it from wherever people work.
The server
The server is the central coordinator. Per the same documentation, it persists session history in Postgres or SQLite, holds artifacts, the agent catalog, and skill definitions, proxies MCP tool calls with server-side policy enforcement, and handles authentication through built-in accounts or OIDC/SSO. The deployment README describes it as a FastAPI app that serves HTTP and SSE routes, terminal WebSockets, persistence, and the web UI.
The server runs no model calls and no tools. The README states that its image carries no harness SDKs and no LLM API keys, which is why no agent code runs inside it.
The runner
The runner is the per-session process that executes the agent loop. It launches the harness you chose or your custom agent, runs tools, and streams events back to the server. It dials in to the server over a tunnel, so a runner on a laptop and a runner in a cloud sandbox look the same to the server.
A host is a machine you register with the server, and the runner executes on it. You register your own machine with omni host <server-url>. On Kubernetes, a session created with host_type: managed spawns a dedicated runner pod, per the deployment documentation.
The UI
The web, terminal, desktop, and mobile clients and the REST API all talk to the server and never to the runner directly. That one rule means policy and history live in a single place, whichever surface someone uses to start a session.
Omnibox
Omnibox is Omnigent’s OS-level sandbox. It uses bubblewrap and seccomp on Linux and Seatbelt on macOS, and every process the agent spawns inherits the boundary. It limits the filesystem to approved paths, sends HTTP(S) traffic through a default-deny proxy with an explicit allow-list, and hands the agent placeholder tokens while the proxy substitutes real credentials only for approved requests.
Where can an Omnigent runner run?
The same agent definition can run on four kinds of host. The choice decides who operates the server, where credentials live, and whose model access the agent uses.
| Environment | Server | Host | Model access |
|---|---|---|---|
| Your own machine | Installed locally, available only to you | Your machine or VM | Your own keys and subscriptions |
| Self-hosted server | Docker Compose, Kubernetes, or Databricks Apps; shared across users | Any registered host or sandbox | Your own keys and subscriptions |
| Cloud sandbox host | Your server, local or self-hosted | One sandbox per session | Provider credentials stay on the launching process; keys reach the sandbox through the provider’s secret store or copied environment variables |
| Omnigent on Databricks | Operated by Databricks | Your own machine or a Databricks Sandbox | Foundation Model APIs through Unity Gateway |
The server and sandbox rows draw on the deployment documentation and the cloud sandbox host page, which lists Modal, Daytona, Blaxel, Islo, Gensee, NVIDIA OpenShell, and Boxlite as supported providers. The project README also names E2B. The last row comes from the Databricks Omnigent documentation.
Two details change real decisions. A Databricks Sandbox is in Beta, has fixed 4 vCPUs and 8 GB of memory, and the documentation says it places no restrictions on network egress. Egress control is therefore something your policies and Omnibox have to supply, not something the sandbox gives you. And per the Omnigent on Databricks documentation, you cannot bring your own API keys when you use Sandbox hosts; model access goes through Unity Gateway.
What does Databricks run in Omnigent on Databricks?
With the managed option, Databricks operates the server. According to Databricks (2026), that server integrates with your workspace’s identity provider, model access runs through Foundation Model APIs and Unity Gateway, and Databricks Sandboxes are available as hosts. Omnigent on Databricks is in Beta, and it requires the Omnigent preview, a workspace region that supports Unity Gateway, and, for Sandbox hosts, the Sandbox preview.
In practice that moves six responsibilities off your team:
- Server operation. Databricks runs the coordinator that holds sessions, tool calls, and policies.
- Identity. Sign-in follows your workspace identity provider instead of a separate account system.
- Model access. Calls to frontier models route through Unity Gateway, which Databricks describes as the control plane that routes every model and MCP request, enforces rate limits and cost controls, and records usage.
- Hosts. A Databricks Sandbox keeps running when your own machine is off, and per the quickstart, credentials stay within Databricks.
- Policy enforcement. Built-in contextual policies apply, and custom policies are written in Common Expression Language (CEL). Custom Python policies are not supported.
- Tool governance. MCP Services let you register an external MCP server as a Unity Catalog securable, with an
EXECUTEgrant, administrator-selected tools, service policies, and audit logging in system tables.
You still decide which agents exist, which tools they get, and which actions should pause for a person. The managed server does not make those calls for you.
How do policies decide what an agent may do?
Omnigent policies intercept every action and return one of three decisions: allow, ask (pause for user approval), or deny. Policies run in order, and the first one to return a decision wins. They are contextual because each policy keeps state across the session, so a cost cap can count spend over many turns and a rate limit can persist through a conversation.
Rules stack at three levels: session rules set by the user, agent-level rules set by the developer in the agent config, and server-wide rules set by an administrator. All three apply at the same time. A company-wide spending cap, a developer’s repository restriction, and a user’s own approval gate can all be active in one session.
This is where agent identity and guardrails become a team agreement rather than a product setting. Someone has to own each server-wide rule, decide what an unanswered ask does, and review the policy list as agents change, which is the day-to-day work of AI agent governance. The enterprise AI agent guardrails checklist and the guide to AI agent identity cover the questions to settle first. The reasoning also connects to securing multi-agent systems, because a meta-harness makes mixed-agent sessions the normal case.
How do Omnigent agents get context into the runtime?
Omnigent gives an agent several channels for context. Instructions and skills travel with the agent definition. Skills deserve the same review as code an agent will follow, which is the point of enterprise skill safety. Tools declared in the agent YAML bring in the rest: MCP servers over local or remote HTTP/SSE transport, Python functions, sub-agents, and built-in tools that include Hindsight memory.
For governed access on Databricks, Unity Catalog MCP Services control which MCP servers and tools an agent can use in a workspace. That settles who may call a tool. It does not settle what the data behind the tool means.
Skills, instructions, and memory describe how one agent should work. They cannot hold the organization’s accumulated knowledge about its data: which revenue definition finance signed off, who owns a table, which column carries a retention rule. That knowledge sits in systems of record and in people’s heads, which creates the context gap that coding agents already show. Context management and memory management solve different problems, and a runtime’s session memory addresses only the second.
Atlan’s demonstration shows the pattern: a builder connects an agent framework in Cursor to Atlan MCP, and the agent assembles itself from governed context instead of hand-fed prompts.
Because the runtime is meant to span harnesses, the context source has to span them too. A context layer tied to one host, harness, or platform would fragment again the moment a team switched tools, which is the cost laid out in the guide to single-stack lock-in versus a neutral context layer. The sibling comparison of Omnigent and a neutral context layer takes that tension further.
How do Omnigent agents get the context they need from Atlan?
The context layer connects to the systems where an organization’s knowledge lives. The Databricks connector crawls Unity Catalog metadata and builds lineage in Unity Catalog-enabled workspaces. The result lands in the Enterprise Data Graph, which stores assets, ownership, quality signals, and lineage in one place that context for Databricks and every other platform can share.
Three capabilities sit on top of that graph:
- Business meaning. Glossary terms, domains, and metrics give agents the organization’s own language. The active ontology and the wider knowledge graph show how that vocabulary becomes queryable.
- Governed delivery. Atlan MCP is a hosted server that supports OAuth, where each person signs in with their own account and tools run with their own permissions, and API keys for automation. Supported clients include Cursor, Codex, Google ADK, and Databricks. The explainer on the MCP server covers what it exposes.
- Versioned context. Context Engineering Studio gives teams a place to build Context Repos, bounded units of context, before agents depend on them.
To connect an Omnigent agent, declare the Atlan MCP server as a remote MCP tool in the agent YAML, as described in the Omnigent tools documentation. On Omnigent on Databricks, you can instead register it as a Unity Catalog MCP Service, so the same grants, service policies, and audit logs that govern other tools govern this one. Whichever route you pick, the MCP gateway versus context layer distinction applies: a gateway controls who reaches a tool, and a context layer decides what the tool returns.
What should a team settle before an Omnigent agent goes live?
Four decisions fall to the team whichever host you choose. Settle them before the first production run.
- Where the host runs and what it can reach. Name the machine or sandbox, then check egress. A Databricks Sandbox places no network restrictions, so decide whether Omnibox rules or a proxy will.
- Which policies exist and who owns them. Write down the server-wide, agent, and session rules, and decide what happens when an ask goes unanswered.
- Where state lives. Session history sits in the server database. Decide who can read it and how long it stays, and pair it with AI agent observability practice so traces and context can be compared.
- Which context the agent reads, and from where. Confirm that definitions, owners, and lineage are queryable at run time, supported by context engineering for AI agents rather than a one-off prompt.
The fourth decision is the one runtimes leave open. A context observability practice shows whether the context an agent used was fresh and correct, and the broader discipline of harness engineering treats the context layer as part of the harness rather than an accessory to it.
Moving forward with the Omnigent agent runtime
Omnigent runs agents from any supported harness through one server, one set of policies, and a runner on whichever host fits the job. The runtime has three components, and only the server needs deployment. Omnigent on Databricks takes the server off your hands while it remains in Beta, with regional limits and a fixed policy language.
What the runtime cannot do is tell an agent what your data means. The teams that get value from it will treat the context layer for AI agents as a separate decision, one that has to outlast any single harness. Which of your agents would give a wrong answer today if the runtime worked perfectly and the context were missing?
FAQs about the Databricks Omnigent agent runtime
1. Where does an Omnigent agent actually run?
An Omnigent agent runs in a runner process on a host that you register with the server. The host can be your own machine, a self-hosted server, a cloud sandbox from a supported provider, or a Databricks Sandbox when you use Omnigent on Databricks. The server coordinates the session and stores its history, but no agent code runs inside it.
2. Can you run Omnigent without Databricks?
Yes. Omnigent is open source under the Apache 2.0 license. You can run it on your own machine, deploy the server with Docker Compose or Kubernetes, or host it on Databricks Apps. Omnigent on Databricks is the managed option, and it is currently in Beta.
3. Is there a difference between Databricks Sandbox and Omnibox?
Yes. A Databricks Sandbox is a managed host, meaning the isolated compute where a runner executes. Omnibox is Omnigent’s OS-level sandbox that wraps the agent process with filesystem isolation, a default-deny network proxy, and credential injection. They address different layers, so a runner on a Databricks Sandbox can still use Omnibox.
4. Which cloud sandboxes does Omnigent support?
Omnigent documents support for Modal, Daytona, Blaxel, Islo, Gensee, NVIDIA OpenShell, and Boxlite as cloud sandbox hosts, with one sandbox per session. The project README also names E2B. Databricks adds its own managed Databricks Sandbox, which is in Beta and limited to supported regions.
5. Can you connect Atlan to Omnigent agents?
Yes, through MCP. Omnigent agents can declare remote MCP servers in their YAML, and Atlan MCP is a hosted server that supports OAuth and API key authentication. On Omnigent on Databricks, you can also register an external MCP server as a Unity Catalog MCP Service so that grants and policies govern its use.
6. Does the Omnigent runtime provide business context to agents?
No. The runtime provides execution, policy, sandboxing, and session storage. Agents get instructions, skills, tools, and memory from their definition, but definitions, ownership, lineage, and data policy from enterprise systems must be supplied through tools such as an MCP server connected to a context layer.
Sources
- Omnigent on Databricks, Databricks Documentation, 2026. https://docs.databricks.com/aws/en/omnigent/
- Omnigent quickstart, Databricks Documentation, 2026. https://docs.databricks.com/aws/en/omnigent/quickstart
- Databricks Sandbox, Databricks Documentation, 2026. https://docs.databricks.com/aws/en/compute/serverless/sandbox
- Databricks Apps, Databricks Documentation, 2026. https://docs.databricks.com/aws/en/dev-tools/databricks-apps/
- Connect agents to tools with MCP Services, Databricks Documentation, 2026. https://docs.databricks.com/aws/en/agents/mcp-tools/mcp-services
- AI governance guide (Unity Gateway), Databricks Documentation, 2026. https://docs.databricks.com/aws/en/ai-gateway/ai-governance
- omnigent-ai/omnigent, Omnigent project on GitHub, 2026. https://github.com/omnigent-ai/omnigent
- Omnigent server deployment README, Omnigent project on GitHub, 2026. https://github.com/omnigent-ai/omnigent/blob/main/deploy/README.md
- Shared Server, Omnigent Documentation, 2026. https://omnigent.ai/docs/deploy/overview
- Cloud Sandbox Host, Omnigent Documentation, 2026. https://omnigent.ai/docs/deploy/cloud-sandbox-host
- Omnibox, Omnigent Documentation, 2026. https://omnigent.ai/docs/omnibox
- Contextual Policies, Omnigent Documentation, 2026. https://omnigent.ai/docs/policies/overview
- Custom Agents, Omnigent Documentation, 2026. https://omnigent.ai/docs/use/custom-agents
- MCP and Tools, Omnigent Documentation, 2026. https://omnigent.ai/docs/build/tools
- Set up Atlan MCP, Atlan Documentation, 2026. https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/remote-mcp-overview
- How to crawl Databricks in Atlan, Atlan Documentation, 2026. https://docs.atlan.com/apps/connectors/data-warehouses/databricks/how-tos/crawl-databricks
