Databricks Omnigent decides how your agents run. It does not decide what they know. Atlan, the context layer for AI agents, supplies that second half: certified definitions, lineage, ownership, and policy context served through the Atlan MCP server to Claude Code, Codex, Cursor, Pi, and custom agents alike. The two layers sit at different points in the stack, so the real design question is where each agent gets its business meaning once you stop standardizing on a single harness.
| Dimension | Databricks Omnigent | Neutral context layer |
|---|---|---|
| Primary role | Runs agents | Informs agents |
| What it controls | Tool calls, LLM requests, and file operations | Business meaning |
| Core capabilities | Composition, policies, and sandboxing | Definitions, lineage, and ownership |
| Portability | Swaps harnesses | Keeps context usable across every harness |
| Interfaces | A uniform agent API | Open protocols such as MCP and A2A |
| Risk it reduces | Runaway costs and unsafe actions | Conflicting agent answers |
Why does Databricks Omnigent matter?
According to the Databricks announcement (June 13, 2026), Omnigent is an open-source meta-harness released under the Apache 2.0 license. It sits above the agents a team already uses, including Claude Code, Codex, Pi, and custom agents, and makes them interoperable. The Databricks release notes list Omnigent as a Beta feature from June 17, 2026.
The pitch is easy to follow. Teams now run several coding assistants and agent SDKs side by side, and each one carries its own configuration, sessions, and permission model. A meta-harness is a different layer from a framework: it wraps harnesses instead of replacing them, and the harness engineering work moves up one level.
Omnigent bets on three things: composing agents, controlling them with policies, and collaborating live with teammates. The Omnigent on Databricks documentation describes the result as a common layer that lets you swap or combine harnesses without rewriting, with policies and sandboxing on top.
Why was Omnigent built, and what does it fix for engineers?
Omnigent targets the friction that shows up once a team uses more than one harness. Engineers copy text and code between tools by hand. They keep separate harness, SDK, and model configurations current. They stitch sessions together across tools with little structure, and they rewrite code when they swap one harness for another. Omnigent attacks continuity and consistency across those agents, SDKs, and harnesses.
It stops there. Omnigent does not decide which definition of “active customer” an agent should apply, who owns a metric, or whether a column holds restricted data. That job belongs to a context layer that no single harness owns, which is the argument behind single-stack lock-in versus a neutral context layer.
How does the Databricks Omnigent meta-harness work?
Most harnesses share a shape: a chat interface that accepts files and makes tool calls, often reachable from a web app and a terminal UI. Codex has the Codex SDK, which controls local Codex agents programmatically. Claude Code has the Claude Agent SDK, which runs the same agent loop as a library in Python and TypeScript. Omnigent wraps layers like these to give you cross-harness support through three features.
- Composition lets you define a harness-agnostic agent, pick its runtime, prompts, and LLM, and run subagents of one agent on different harnesses. The agent YAML specification lists the harness values you can pick, from
claude-sdkandcodextocursor,pi, and custom ACP agents. The custom agents documentation shows an agent defined in a short YAML file with harness, model, prompt, MCP, and policy sections. - Control applies policies to every tool call, LLM request, and file operation. A policy can allow an action, ask for approval, or deny it, and it can track session state such as cumulative spend. Omnibox adds an OS-level sandbox with filesystem isolation, a default-deny network proxy, and placeholder credentials instead of real secrets.
- Collaboration lets teammates share live sessions that run on one or more harnesses.
How to set up the Databricks Omnigent meta-harness
You install the omni command first. The install guide offers curl, uv, and Homebrew routes and expects Python 3.12 or later, Node.js 22, and tmux. After omni setup configures credentials, you choose one of three ways to work.
- Coding agents
- Built-in multi-agent orchestrators
- Custom agents
Omnigent setup with coding agents
The coding agents page covers spinning up agents with commands such as omni claude and omni codex. You can also import existing sessions with omnigent import --harness claude --session <session-id>.
Omnigent setup with built-in multi-agent orchestrators
Pick this route when one workflow should span several harnesses. The built-in agents page lists two orchestrators.
- Polly breaks a coding task into subtasks and hands them to agents on different harnesses, each in its own git worktree. Run
omni polly. - Debby is a multi-model brainstorming partner that queries more than one model and supports extended debate. Run
omni debby.
Omnigent setup with custom agents
Choose the custom agents route when you want your own agents and orchestrators. The built-in orchestrators are plain YAML, so they double as templates. Behind every route, the Omnigent server and runner do the same work.
- The server persists every conversation, message, and tool call in Postgres or SQLite, holds the catalog of registered specs, proxies MCP tool calls with server-side policy enforcement, and handles built-in accounts or OIDC/SSO.
- A runner, one per session, executes the agent loop, manages the harness, runs tools, and streams events back to the server.
- Web, terminal, and mobile interfaces talk to the server, never to the runner directly.
On Databricks, the Omnigent documentation describes a fully managed server and integration with Foundation Model APIs and Unity Gateway. Databricks Sandbox (Beta) can host an agent harness, and the Databricks announcement names Databricks Apps, Lakebase, and Unity Catalog among its integration points. Unity Gateway governs LLM, MCP server, and coding-agent traffic, and our Unity AI Gateway explainer covers how that control plane fits next to a context layer.
None of this, wherever you run it, tells an agent what your tables mean. Policies govern what an agent may do. Sandboxes contain what it can reach. Neither carries organizational grounding, awareness of systems outside the harness, or the tribal knowledge that decides whether an answer is right. That gap is business context for AI, and it follows the agent whichever harness runs it.
What is a neutral context layer and how does it work?
A context layer is an architectural component between an organization’s enterprise systems and its AI agents. It accumulates and curates knowledge about systems, processes, and ways of working so agents can retrieve semantic context, entity resolution, permission resolution, freshness, lineage, and provenance. Our guide to what an enterprise context layer actually is goes deeper on each of those.
A context layer earns the word neutral when it meets four tests.
- No vendor lock-in. It stores business logic, rules, policies, and definitions in open formats, so the knowledge stays available to every agent whichever harness it runs on. Open table formats help here: Apache Iceberg lets multiple engines, including Spark, Flink, and Trino, read the same tables safely.
- Standard protocols. It serves context over Model Context Protocol (MCP), an open standard for connecting AI applications to external systems, and speaks A2A, the open standard for agent-to-agent communication. The Open Semantic Interchange initiative, announced September 23, 2025 with Atlan among its partners, defines a vendor-neutral semantic model specification. Our pieces on why MCP matters for agents, MCP versus A2A, and the Google A2A protocol cover how the three fit together.
- Tool-agnostic. The semantic layer for AI agents does not hang off one harness, one agent SDK, or one foundation model provider, which keeps switching costs low.
- Humans on the loop. People certify and label context, so the layer stays high-signal. The difference between a context layer and a semantic layer matters here, because certification covers more than metric definitions.
Databricks Omnigent vs. neutral context layer: key differences
The two layers answer different questions about the same agent.
| Question | Databricks Omnigent | Neutral context layer |
|---|---|---|
| What role does it play? | Makes harnesses and agents interchangeable with little effort | Grounds agents in organizational knowledge |
| Where does it sit? | Across and above harnesses, agent frameworks, and coding assistants | Between the harness or meta-harness and enterprise systems such as databases, documentation, and infrastructure |
| What do agents get from it? | Sandboxed environments with their own sessions | Curated context about the business: definitions, quality, lineage, and policy rules |
| What problem does it solve? | Too many harnesses force constant translation, so an API layer absorbs it | Organizational knowledge sits in many shapes and places, so a governed layer serves it |
| Is it vendor-locked? | Omnigent is Apache 2.0 licensed and the repository is public, so you can run it on your own infrastructure or on Databricks | A truly neutral layer is not locked to one vendor |
On Databricks, agents can also draw on metadata already registered in Unity Catalog, such as Unity Catalog metrics and Genie ontology. That covers the data assets Unity Catalog manages. Large organizations also keep context in systems outside it: other warehouses, BI tools, ticketing and documentation systems, and the people who know why a definition changed. Our look at Genie context requirements shows the same boundary from inside one Databricks product, and the Agent Bricks overview shows it again for agents built on the platform.
When several agents from several harnesses answer the same question, enterprise context silos turn into conflicting answers. Context management across multi-agent systems breaks without one shared layer, and a meta-harness that lets you mix harnesses freely raises the stakes on that layer. A neutral context layer for enterprise AI such as Atlan gives every agent the same governed answer, whichever harness it runs on.
How does Atlan provide a neutral context layer for the Omnigent meta-harness?
Atlan is the Context Layer for AI. Its Context Lakehouse stores metadata in Apache Iceberg tables, so context stays readable by SQL engines without going through Atlan. That is the open-formats test from the previous section, applied to Atlan’s own storage.
The delivery route for agents is MCP. According to the Atlan MCP documentation (2026), Atlan MCP is a hosted server on every tenant, implements the open Model Context Protocol, and respects the permissions already set in Atlan. The MCP tools reference lists tools for semantic search, asset search, lineage traversal, and business glossary work, each marked Read, Write, or Admin. Our explainer on how the Atlan MCP server builds context walks through them, and MCP for data lineage shows what queryable lineage gives an agent.
Behind that interface, Atlan builds three things for agentic retrieval.
- An Enterprise Data Graph captures assets, ownership, and granular lineage across enterprise systems, ready for graph traversal. It is the same knowledge graph for AI agents idea applied to your estate.
- An Active Ontology holds a business-specific glossary plus domain and metric definitions, aligned with the Open Semantic Interchange standard.
- Context Engineering Studio builds Context Repos for specific use cases and runs evaluations on them, and Context Agents work from the same context.
Freshness and certification decide whether an agent can trust what it reads. Context freshness and context poisoning both get worse as you add harnesses, because each new agent is another reader of whatever is stale or wrong.
How can an Omnigent agent use the Atlan MCP server?
Two documented routes exist, and both use standard MCP configuration.
On your own infrastructure, the Omnigent tools documentation shows a remote MCP server declared under tools in the agent YAML with type: mcp and a url, plus optional headers for credentials and a tools allow-list. An allow-list matters in practice: expose the read-only search, lineage, and glossary tools first and keep Write and Admin tools off until you have reviewed them.
tools:
atlan:
type: mcp
url: https://<your-atlan-tenant>/mcp
tools: [semantic_search, traverse_lineage]
On Databricks, the MCP Services documentation describes registering an external MCP server as a Unity Catalog securable, with EXECUTE grants, tool selection, service policies, and audit logging. Registration happens through the UI or REST API. The URL above is a placeholder: use the endpoint and authentication method from the Atlan MCP documentation for your tenant.
What should you check before wiring context into a multi-harness setup?
A meta-harness makes it cheap to add a fourth harness and expensive to notice that all four answer from different definitions. Five checks catch most of the damage before it ships.
- List the harnesses and the context each one reads. Each harness loads its own instruction files, memory, and tools. The agent harness failures and anti-patterns are mostly context that one harness has and another lacks.
- Name the five or six business terms agents get wrong most often. Revenue, active customer, churn, and a handful of others carry most of the disagreement. Put one certified definition for each in one governed place.
- Route lookups through one interface. MCP gives every harness the same entry point, so a definition changes once.
- Test with the same question on every harness. A question that returns different numbers on two harnesses points to a context gap, not a harness bug. This is where data quality for agent harnesses pays off.
- Decide who certifies. Context without an owner drifts, and what makes data AI-ready starts with named owners.
Best AI agent harness tools compares the runtimes themselves, and how to build an AI agent harness covers the engineering underneath. This page covers the part neither one reaches.
Databricks Omnigent vs. neutral context layer for AI: moving forward
Coding assistants and harnesses such as Claude Code, Codex, Cursor, Antigravity, and Pi each ship with their own structure. Demand to cut the friction between them keeps rising, both for multi-agent work and for moving from one harness to another. Omnigent answers that with a harness for harnesses: a uniform API for composition, control, and collaboration, deployable on your own infrastructure or on Databricks.
It leaves the context problem open. A neutral context layer pulls context from enterprise systems and serves it through open protocols, which is how Atlan built its enterprise context layer. An Omnigent agent can reach it through MCP today. What stays unsettled is how much of the certification work teams will automate and how much they will keep human, and that choice shapes every agent you add.
FAQs about Databricks Omnigent vs. neutral context layer for AI agents
1. What is Databricks Omnigent? Is it another agent framework?
Omnigent is an open-source meta-harness that sits on top of coding assistants, agent SDKs, and harnesses. It lets you work with several harnesses at once, including separate ones for subagents. It is not an agent framework. It is a harness for harnesses.
2. Which AI agents or harnesses does Databricks Omnigent support?
Databricks names Claude Code, Codex, Pi, and custom agents, and the Omnigent documentation also covers Cursor, Copilot, Hermes, and Devin. The agent YAML specification lists harness values for Claude, OpenAI Agents SDK, Codex, Cursor, Pi, Antigravity, Qwen Code, Kimi, Kiro, Copilot, Hermes, and custom ACP agents. Support levels vary by harness, so check the current documentation before you commit.
3. Is Omnigent only available in Databricks?
No. Omnigent is an open-source project under the Apache 2.0 license. You can run it on your own machine or server with credentials for the harnesses you use. Databricks also offers a managed deployment.
4. Where and how do you run Omnigent agents?
You can run Omnigent agents locally or on Databricks. After you install omni with curl, uv, or Homebrew, you start agents with commands such as omni claude or omni polly. A local run opens a web interface, which the documentation lists at http://localhost:6767.
5. Can an Omnigent agent use the Atlan MCP server?
Yes, through standard MCP configuration. On your own infrastructure, declare the Atlan MCP server under tools in the agent YAML and limit it with a tool allow-list. On Databricks, you can register it as an MCP Service in Unity Catalog. The agent then reaches asset search, business glossary, lineage, and more, under the permissions set in Atlan.
Sources
- Introducing Omnigent: A Meta-Harness to Combine, Control and Share Your Agents, Databricks, 2026. https://www.databricks.com/blog/introducing-omnigent-meta-harness-combine-control-and-share-your-agents
- June 2026 release notes, Databricks Documentation. https://docs.databricks.com/aws/en/release-notes/product/2026/june
- Omnigent on Databricks, Databricks Documentation. https://docs.databricks.com/aws/en/omnigent/
- Omnigent server and runner, Omnigent Docs. https://omnigent.ai/docs/deploy/overview
- Contextual policies, Omnigent Docs. https://omnigent.ai/docs/policies/overview
- Omnibox, Omnigent Docs. https://omnigent.ai/docs/omnibox
- Install, Omnigent Docs. https://omnigent.ai/quickstart/install
- Coding agents, Omnigent Docs. https://omnigent.ai/docs/use/coding-agents
- Built-in multi-agent orchestrators, Omnigent Docs. https://omnigent.ai/docs/use/builtin-agents
- Custom agents, Omnigent Docs. https://omnigent.ai/docs/use/custom-agents
- MCP and tools, Omnigent Docs. https://omnigent.ai/docs/build/tools
- Agent YAML specification, omnigent-ai/omnigent, GitHub. https://github.com/omnigent-ai/omnigent/blob/main/docs/AGENT_YAML_SPEC.md
- omnigent-ai/omnigent repository (Apache 2.0), GitHub. https://github.com/omnigent-ai/omnigent
- Databricks Sandbox, Databricks Documentation. https://docs.databricks.com/aws/en/compute/serverless/sandbox
- Databricks Apps, Databricks Documentation. https://docs.databricks.com/aws/en/dev-tools/databricks-apps/
- Unity Gateway overview, Databricks Documentation. https://docs.databricks.com/aws/en/ai-gateway/
- Connect agents to tools with MCP Services, Databricks Documentation. https://docs.databricks.com/aws/en/agents/mcp-tools/mcp-services
- Codex SDK, OpenAI Codex Documentation. https://learn.chatgpt.com/docs/codex-sdk
- Agent SDK overview, Claude Code Docs, Anthropic. https://code.claude.com/docs/en/agent-sdk/overview
- What is the Model Context Protocol (MCP)?, modelcontextprotocol.io. https://modelcontextprotocol.io/docs/getting-started/intro
- Agent2Agent (A2A) Protocol, Linux Foundation. https://a2a-protocol.org/latest/
- Apache Iceberg, Apache Software Foundation. https://iceberg.apache.org/
- Snowflake, Salesforce, dbt Labs, and More Revolutionize Data Readiness for AI with Open Semantic Interchange Initiative, Snowflake, 2025. https://snowflake.com/en/news/press-releases/snowflake-salesforce-dbt-labs-and-more-revolutionize-data-readiness-for-ai-with-open-semantic-interchange-initiative
- Atlan MCP overview, Atlan Documentation, 2026. https://docs.atlan.com/product/capabilities/atlan-ai/how-tos/atlan-mcp-overview
- Atlan MCP tools reference, Atlan Documentation, 2026. https://docs.atlan.com/product/capabilities/atlan-ai/references/mcp-tools
- Context Lakehouse, Atlan, 2026. https://atlan.com/context-lakehouse/
