OMA: An Open-Source Managed Agent Platform That Decouples Brain, Sandbox, and State
Teams can now run long-lived, stateful AI tasks on their own infrastructure with managed-agent abstractions taken from Anthropic's design, without locking business logic to a vendor's cloud. The separation of brain, sandbox, and state is a concrete pattern for building reliable, auditable agent pipelines that survive crashes and enforce credential boundaries.
OMA (open-managed-agents) is a self-hosted managed-agent platform that takes over the operational side of running AI agents in production. It centralizes the recurring problems that appear once models and tools are wired up: resuming long tasks after interruptions, keeping credentials out of generated code, persisting files, reaching internal tools, and tracing execution and cost. Business teams define an Agent's role, skills, and tools via API, then submit tasks and receive events, while the platform handles the runtime.
The architecture splits three concerns. The Platform manages sessions, permissions, and resources; the Brain (built on DeepSeek Harness) runs the agent loop outside the sandbox; and the Sandbox (Tencent's CubeSandbox in the cloud, an E2B-compatible local gateway for development) only executes commands. This decoupling means the first response doesn't wait for sandbox startup, and a sandbox crash doesn't kill in-flight reasoning. Session state, events, and files live independently so they can be rebuilt after failures. Credentials are injected by platform-side proxies and never enter the sandbox, while a FUSE-based virtual filesystem gives each session a task-ordered view without exposing the physical object storage.
For private network tools, OMA uses a reverse-connection tunnel based on OpenAI's tunnel-client, letting a cloud agent call MCP servers behind a firewall with nothing but outbound HTTPS. Observability records model and tool calls on a timeline, plus aggregated requests, tokens, costs, and failures. The project is a heavy backend infrastructure effort, and the team plans to add agent evaluation based on actual task outputs.
Choosing a non-public protocol like CCRv2 over a standard reveals a gap in the ecosystem: no common wire-level contract for agent runtime coordination, so platforms end up binding to a single vendor's protocol and betting on its stability.
The decision to mark executed-but-unlogged tool calls as unknown result and block instead of replaying is the right trade-off for side-effectful operations, but it sets a high bar for idempotency that business logic must meet.
FUSE-as-virtualization turns the filesystem into a product surface: per-session directory trees, read-only skills, writable outputs, and stable paths across sandbox replacements. That is a pattern worth copying for any multi-tenant agent platform, especially when skills are distributed as ZIPs.
Using OpenAI's tunnel-client while aligning with Anthropic's Tunnels API shows how protocol compatibility lets a project mix components from competing vendors, but the same compat layer adds integration and upgrade burden.
Regarding recovery from long-task interruptions, we added an extra rule in our local execution scenario: for short interruptions, just resume from the original session; for interruptions exceeding one hour, first ask the person who assigned the task whether to continue. The reason is that after long interruptions, the main code and requirements themselves may have changed, so directly continuing would be editing on outdated context. Would like to ask whether OMA's Session recovery has considered this 'confirm before resume' step?