Databricks developed Omnigent, an open-source meta-harness that addresses operational challenges of managing AI agents across their 3,000+ engineering organization. The platform solves fragmentation issues where teams were using multiple AI coding assistants (Claude Code, Codex, Cursor, etc.) by creating a unified layer that enables composition across different harnesses, collaboration through shared sessions, and control via policies for cost and security. The system features a server-client architecture where sessions persist independently of local machines, smart routing to optimize model selection, and extensible plugins for harnesses and sandboxes. Since open-sourcing, Omnigent has gained 8,000 stars and 360+ community contributors, fundamentally changing how teams collaborate on AI-assisted development work.
Databricks encountered significant operational challenges managing AI agents across their organization of over 3,000 engineers. Teams were using various AI coding assistants including Claude Code, Codex, Cursor, and others, leading to a fragmented ecosystem where adoption was easy but operation was difficult. Engineers were resorting to workarounds like sending Claude markdown files via Slack to share agent work, setting up private worktrees with pseudo-code for collaboration, and reconfiguring MCP servers when switching between different harnesses. This pain point drove the development of Omnigent, an open-source meta-harness that sits as a unified layer above individual AI agent harnesses.
The Omnigent architecture consists of two primary components connected by a common API. The server side stores sessions, policies, MCP servers, skills, and custom agents in a centralized location. The runner side executes actual agent work and can be a laptop, dev box, Kubernetes pod, or cloud sandbox. This separation is fundamental to the platform’s capabilities, as it decouples session state from execution environment. Multiple surfaces including terminal, web UI, and native desktop applications all communicate through the same API, enabling seamless transitions between interfaces.
The architecture enables sessions to persist independently of any single machine or terminal. An engineer can initiate work on their laptop, close it, and resume from a phone or different machine. The server maintains websocket connections to runners and orchestrates communication between different execution environments. This design choice provides the foundation for the platform’s three core value propositions: composition across harnesses, collaboration between humans and agents, and control through policies.
Omnigent supports over a dozen harnesses out of the box, with a plugin SDK allowing anyone to add integrations without modifying core code. The platform automatically detects existing harness configurations on local machines, including subscriptions, MCP servers, and skills, requiring no migration effort. Engineers can switch between harnesses mid-session or orchestrate multiple harnesses simultaneously for different tasks.
The Poly agent demonstrates sophisticated multi-agent orchestration capabilities. Defined as a YAML configuration, Poly acts as a multi-agent coding orchestrator that can fan out tasks across different harnesses in parallel. In the demonstrated scenario, Poly examined GitHub issues and delegated work to Claude Code, Codex, Cursor, and OpenCode sub-agents simultaneously, monitoring their progress and ensuring task completion. Each sub-agent operated in its own terminal session while Poly coordinated at a higher level. This composition allows teams to leverage harness-specific strengths, such as having one model implement code while another reviews it, without managing separate contexts manually.
The custom agent system uses simple YAML specifications defining system prompts, models, tools, and even other agents as tools. This allows agents to be composed hierarchically, with different harnesses at different layers. Agents remain portable, shareable across teams, and subject to the same sandboxing and policies as built-in functionality. The Atlassian team demonstrated this extensibility by building their custom Robo harness and integrating it with Omnigent without touching the core codebase.
The collaboration capabilities address a common enterprise pattern where an engineer builds context with an agent over an extended period, then hits a blocker requiring teammate input. Rather than copying history or responses into Slack, sessions can be shared in read-only or full-edit mode. Shared users appear as online in the session, can view all files and artifacts, and in edit mode can drive the session with full context already established.
The artifact commenting system works similarly to collaborative document editing. Users can comment on code, markdown, HTML, and PDFs directly in the UI. Comments accumulate as inline annotations, and an “address all” button injects them as prompts to the agent. This creates a review workflow where human feedback is seamlessly integrated into the agent’s context without manual copying or context switching.
The platform tracks thousands of sessions daily across Databricks’ engineering organization. The stickiness is evident from user behavior where downtime notifications from users often arrive faster than automated monitoring alerts. The shift from individual, isolated agent sessions to shared, persistent sessions has fundamentally changed collaboration patterns within the organization.
Unlike traditional tools that evaluate individual actions in isolation, Omnigent policies see entire sessions including incoming data and requested actions. This holistic view enables more sophisticated decision-making. Policies are defined in Python and can allow, deny, or request human approval for actions. The platform ships with a library of built-in policies, and teams can add custom policies without core modifications. Red Hat community members developed policies to detect and stop agents stuck in loops, demonstrating the extensibility of the policy system.
Cost management represents a critical production concern addressed through multiple mechanisms. The budget policy system provides soft checkpoints rather than hard limits. For example, with a $100 monthly budget, the system prompts at $20 spending with options to continue, stop, or downgrade to cheaper models. This graduated approach prevents hard failures while maintaining cost awareness. Per-session budgets, per-user daily caps, and server-wide limits can all be configured and enforced centrally.
Smart routing tackles the common problem of over-provisioning model capacity for simple tasks. The auto option uses a lightweight classifier to examine tasks and select appropriate harnesses and models. Simple questions like “what is the capital of France” route to fast, inexpensive models like GPT-5 Nano, while complex tasks like “explain this complete codebase and give me a diagram” route to frontier models like Opus. This routing happens transparently to users while significantly reducing costs for workloads with mixed complexity. The routing system is pluggable, allowing integration with custom routing providers or gateway services.
Policy enforcement happens at the server level through tool hooks that intercept harness calls. Before a harness executes an action, policies run to validate compliance. This architecture ensures policies apply consistently regardless of which harness is being used or where it’s running. Server-wide policies configured by administrators apply to all users and sessions, addressing enterprise governance requirements that were difficult with laptop-local agent configurations.
Omnigent provides multiple layers of security through its Omnibox OS-level sandbox and integration with cloud sandbox providers. Omnibox operates natively on Linux, macOS, and Windows, containing agents at the operating system level regardless of execution environment. Even when using cloud sandboxes from providers like Modal, Daytona, E2B, or plain Kubernetes, the OS-level sandbox layer remains active, ensuring defense in depth.
The security model includes credential injection via proxy, ensuring agents never see raw secrets or credentials. This reduces blast radius in case of agent compromise or unexpected behavior. The server’s visibility into all prompts, tool calls, and file modifications enables sophisticated security policies beyond simple allow/deny rules. Policies can examine patterns across sessions, detect anomalous behavior, and enforce context-aware restrictions.
Cloud sandbox integration enables always-on agent sessions. Work initiated on a laptop continues in cloud sandboxes after the laptop closes, with progress visible from any device including mobile. The Databricks sandbox runs agents directly inside Databricks workspaces, integrating with existing infrastructure. All sandbox providers are implemented as plugins, allowing organizations to bring their own devbox setups without requiring pull requests to the core project.
The smart routing system addresses inefficient resource utilization where users habitually select the largest, most expensive models for all tasks. The classifier evaluates task complexity and automatically selects appropriate model tiers. This optimization happens transparently while maintaining the user experience. The routing logic is harness-aware, meaning it considers which harness might be best suited for specific task types, not just which model size.
The demonstration showed routing a simple factual question to GPT-5 Nano while directing a complex codebase analysis task to Opus. This differentiation reduces costs substantially for organizations running thousands of agent sessions daily. The routing system is pluggable via the SDK, allowing organizations to integrate their own routing logic, custom model catalogs, or enterprise routing gateways without modifying Omnigent core code.
The automation panel enables scheduled task execution on any configured host or sandbox. Users define prompts, execution frequency, and target infrastructure. Common use cases at Databricks include PR sweeps that review pull requests every morning and add comments, news digests aggregating company activity weekly, and periodic maintenance tasks. These automations leverage the same session management, policy enforcement, and multi-harness capabilities as interactive sessions.
The automation capability transforms agents from interactive assistants to autonomous workers handling routine tasks. The server-based architecture ensures automations continue executing regardless of individual laptop availability. Policies apply to automated sessions just as they do to human-initiated sessions, maintaining consistent governance.
Omnigent reached 8,000 GitHub stars approximately seven weeks after open sourcing. Over 3,000 pull requests have been merged with 360+ community contributors. The project maintains truly open development with roadmap discussions, PR reviews, and design documents publicly available on GitHub. Community contributions merge daily through standard review processes without additional gatekeeping. The Discord community at discord.gg/omnigent provides direct access to the development team for feature discussions and implementation support.
Internal Databricks usage spans 3,000+ engineers running thousands of sessions daily. The platform has become critical infrastructure, with user reports of downtime often arriving faster than monitoring alerts. Teams have shifted from sharing screenshots and markdown exports to sharing live sessions, fundamentally changing collaboration workflows. The production deployment demonstrates the platform’s ability to operate at enterprise scale with complex governance requirements.
The session synchronization architecture keeps three interfaces in sync: chat UI, web terminal, and local terminal. Any input to any interface immediately reflects across all others. This real-time synchronization uses websocket connections between clients and the server, with the server managing state consistency. The embedded browser within the desktop application allows commenting directly on rendered web applications, with comments fed back to the agent as prompts.
The database-backed session storage enables session rehydration. When an agent process dies or a runner goes offline, restarting loads full conversation history from the database and continues from the last known state. This persistence layer makes sessions resilient to infrastructure failures and execution environment changes. The compaction strategy delegates to individual harnesses, allowing Claude sessions to use Claude’s native compaction and Codex sessions to use Codex’s approach. This design avoids reinventing compaction logic while supporting harness-specific behaviors.
The harness integration uses tool hooks that intercept calls before execution. This interception point enables policy enforcement, cost tracking, and audit logging without modifying harness code. The plugin SDK for harnesses, sandboxes, and routing providers follows a pattern similar to other extensible systems, aiming for the level of extensibility achieved by tools like Pi. Plugins can ship independently of core Omnigent releases, allowing the ecosystem to evolve without central coordination.
The platform addresses real operational pain points experienced at scale, particularly around fragmentation, collaboration, and governance. The architectural separation of session state from execution environment is sound and enables the core value propositions. The policy system’s session-level visibility represents a meaningful improvement over action-level policies in terms of context-aware decision-making.
However, several considerations warrant attention. The reliance on harness-specific compaction means the platform inherits whatever limitations or issues those harnesses have with long-running sessions. The concern raised during Q&A about context rot from repeated compaction is valid and not directly addressed by the platform. The smart routing classifier’s accuracy and decision-making logic are not detailed, making it difficult to assess whether it consistently makes appropriate routing choices for edge cases.
The session sharing and collaboration features assume network connectivity and introduce potential security considerations around who can access shared sessions and what data they contain. The server becomes a critical point of control and potential failure, though the architecture does provide for session persistence. Organizations adopting Omnigent need to carefully consider their server deployment topology, authentication mechanisms, and data residency requirements.
The plugin ecosystem’s success depends on sustained community engagement and clear SDK documentation. While early signs are positive with 360+ contributors, maintaining this momentum and ensuring quality control for third-party plugins presents ongoing challenges. The claim of complete open source development is substantiated by the public roadmap and design docs, though the ultimate test is whether the project maintains this openness as it matures and potentially commercializes.
Cost savings from smart routing and budget policies are likely real but depend heavily on workload characteristics. Organizations with genuinely mixed-complexity tasks will see more benefit than those with uniformly complex requirements. The policy enforcement’s effectiveness depends on how well policies are designed and maintained, requiring ongoing investment from platform teams.
The production adoption at Databricks with 3,000+ engineers provides strong evidence that the platform solves real problems at scale. The rapid community uptake and contributor engagement suggest the pain points are widely felt beyond Databricks. Whether the meta-harness architecture becomes a lasting pattern in the industry or represents a transitional solution as harnesses themselves evolve remains to be seen. The platform’s value proposition is strongest in heterogeneous environments where multiple harnesses and models are genuinely needed rather than in organizations standardized on a single tool.
Stripe, processing approximately 1.3% of global GDP, has evolved from traditional ML-based fraud detection to deploying transformer-based foundation models for payments that process every transaction in under 100ms. The company built a domain-specific foundation model treating charges as tokens and behavior sequences as context windows, ingesting tens of billions of transactions to power fraud detection, improving card-testing detection from 59% to 97% accuracy for large merchants. Stripe also launched the Agentic Commerce Protocol (ACP) jointly with OpenAI to standardize how agents discover and purchase from merchant catalogs, complemented by internal AI adoption reaching 8,500 employees daily using LLM tools, with 65-70% of engineers using AI coding assistants and achieving significant productivity gains like reducing payment method integrations from 2 months to 2 weeks.
Cognition, the company behind Devon, discusses their journey building production-ready autonomous coding agents that operate in cloud environments. The conversation with Walden Yan (Co-founder, CPO at Cognition) and Cole Murray (creator of Open Inspect) explores the architectural decisions, infrastructure challenges, and production considerations for deploying AI agents that can autonomously write, test, and merge code. They discuss the shift from local IDE-based AI assistants to background agents that work autonomously in cloud environments, the technical infrastructure required to support this paradigm (including VM management, sandbox security, and state management), and real-world use cases like automated incident response, customer support triage, and continuous security scanning. The discussion covers how Devon now contributes 80% of commits on Cognition's repositories (up from 16% in January), representing a fundamental shift in how engineering teams work with AI.
Notion, a knowledge work platform serving enterprise customers, spent multiple years (2022-2026) iterating through four to five complete rebuilds of their agent infrastructure before shipping Custom Agents to production. The core problem was enabling users to automate complex workflows across their workspaces while maintaining enterprise-grade reliability, security, and cost efficiency. Their solution involved building a sophisticated agent harness with progressive tool disclosure, SQL-like database abstractions, markdown-based interfaces optimized for LLM consumption, and a comprehensive evaluation framework. The result was a production system handling over 100 tools, serving majority-agent traffic for search, and enabling workflows like automated bug triaging, email processing, and meeting notes capture that fundamentally changed how their company and customers operate.
