The Agent Control Plane: Omnigent on Kubernetes

Infrastructure engineers have been orchestrating services for years. Load balancers in front of application servers. Sidecars for telemetry. Policy enforcement at the ingress. The pattern is so familiar it borders on boring.

Now the same question is arriving at the agent layer.

Databricks recently open-sourced Omnigent, calling it a “meta-harness”: a layer that wraps individual AI agent harnesses, including Claude Code, Codex, and custom implementations, behind a common API. Sessions, policies, and skills travel with you regardless of which model or harness is running underneath. It is an abstraction over the reality of juggling multiple agent tools simultaneously and manually copying context between them.

The concept is not novel if you have ever self-hosted an AI agent. When I set up a self-hosted research agent on EKS, the same questions surfaced: where does state live, who controls network boundaries, how do you expose the agent to callers without exposing the whole machine? Omnigent formalizes those questions into a coherent product.

What the Meta-Harness Actually Is

There are three pieces worth understanding before thinking about deployment.

The runner wraps an underlying agent in a sandboxed session. It intercepts network requests, applies policy, and mediates the agent’s access to the outside world. This is where the interesting security work happens.

The server manages sessions, policies, and sharing. It is what lets you define a rule like “require human approval before any git push that follows a package installation” without patching the agent itself. Policies here are stateful and contextual, not simple allow/deny lists.

The database is where session state, audit logs, and policy configurations persist. It needs to outlive individual runner processes or pods.

If you have deployed any stateful web service to Kubernetes before, you have already solved this problem in a different domain. The topology is the same.

The Kubernetes Shape of the Problem

Running Omnigent on a cluster is not a novel infrastructure problem. It has the same shape as services you have probably deployed before: a server component that should be horizontally scalable, which means it has to be stateless; a runner component that wraps a subprocess and is inherently single-session by nature; and a shared database that both can reach.

The deployment manifests, the Service definitions, the Ingress rules, none of that is the interesting part. The question that deserves real thought is the network interception boundary. The runner needs to sit between the agent and outbound traffic to enforce policies. Where that lands in your existing cluster topology, and how it interacts with your network policies and egress controls, is the question worth sketching out before writing any YAML.

The database configuration is the first real fork in the road:

# Single-instance local or demo
DATABASE_URL=sqlite:////data/artifacts/chat.db

# Production: any managed Postgres will do
DATABASE_URL=postgresql://user:pass@postgres-host:5432/omnigent

SQLite works for a single-instance local setup, but it stores data on the pod’s local disk. On Kubernetes, that means data lives and dies with the pod unless you have mounted persistent storage explicitly. Start with SQLite only if you understand exactly what you are giving up.

Postgres is the right choice the moment you care about persistence or want more than one server replica. Any managed Postgres instance, whether in-cluster or external, works. The key constraint is network reachability from your pod CIDR. The initial migration on a fresh Postgres deployment takes around a minute; give your startup probe enough time or your first deploy will fail a healthcheck it should pass.

The rest of the Kubernetes questions are the same ones you answer for any stateful service: where do secrets live, how does the runner get credentials for the agents it wraps, and who can reach the server from outside the cluster.

Quick Starts Without the Operations Cost

If you want to understand how Omnigent behaves before committing to an infrastructure decision, a HuggingFace Docker Space is the fastest path to the UI. You can have it running in a few minutes. The important thing to understand going in: HuggingFace Spaces use ephemeral disk storage by default. If you configure SQLite, your session history and policies will be gone on the next container restart. Treat it as an exploration environment, not a place to build anything you care about keeping.

For teams already on the Databricks platform, managed Omnigent on Databricks is the opposite end of the spectrum. You get the meta-harness without operating it yourself, with the Databricks security and governance model already in place. If your organization’s agents and data already live in that ecosystem, this is the obvious starting point.

The interesting space is in between: self-hosted on infrastructure you control, with policies tailored to your team’s actual risk model, not a vendor’s defaults.

The Part That Actually Matters

The deployment question has a tractable answer. The policy question is harder and more interesting.

Omnigent’s policy system is stateful. A rule can say: after this agent downloads a package, require human approval before it can push to a remote repository. That is not a static allow/deny list; it is a state machine layered over the agent’s actions. Your policies encode your organization’s threat model for agent behavior.

What would yours look like? Cost limits that pause an agent before an expensive API call. Approval gates before any write touches a shared environment. Audit trails that span model switches so you know which model made which decision during an incident.

Kubernetes operators have been managing stateful systems declaratively for years. The instinct is the same here: define what correct agent behavior looks like, then let the system enforce it rather than supervising every session by hand.

The agent layer is getting the infrastructure treatment it has always needed. The only question is whether you define what that looks like for your team, or let someone else decide.

I have not had the chance to run Omnigent in a real cluster myself yet; other projects have had my attention. It is already on my list and I will post a follow-up once I have hands-on time with an actual deployment.