Why We Open-Sourced Our AI Agent Platform (And What OpenZosma Actually Is)
We open-sourced our entire AI agent platform under Apache 2.0. Here's why, what OpenZosma does, and why proprietary agent platforms are the wrong answer.
In early 2025, we counted the AI agent platforms that had launched in the previous six months. We stopped at 40. By the time we finished the spreadsheet, five more had appeared.
Every single one was solving the same five problems: how do you orchestrate multi-step agent workflows? How do you sandbox agent-generated code so it doesn't destroy your database? How do you connect agents to external tools securely? How do you handle authentication across a dozen different SaaS APIs? How do you make this work for multiple tenants without them seeing each other's data?
Forty companies. Five problems. Zero shared infrastructure.
That's when we decided to open-source everything we'd built. Not the consulting layer. Not the managed hosting. The core platform. The code that actually runs agents, sandboxes execution, connects tools, and keeps users isolated from each other. Apache 2.0. Fork it, self-host it, build on top of it, contribute back if you want.
This post explains why, what OpenZosma actually does, and why we think open-source agent infrastructure is the only approach that makes sense.
The problem we kept running into
Before we wrote a single line of OpenZosma, we spent months talking to teams building AI agents. Startups. Enterprise innovation teams. Solo developers. The conversations all sounded the same:
"We got the agent to work in a notebook. Now we need to run it for real users and everything breaks."
The "everything breaks" part was remarkably consistent. Here's what they were all rebuilding from scratch:
Orchestration. An agent doesn't just call an API once. It plans, executes, observes, adjusts, and repeats. Managing that loop — deciding when to retry, when to abort, when to ask the user for clarification — is a state machine with a dozen edge cases. Every team was writing their own.
Sandboxing. Agents generate code. SQL queries, Python scripts, shell commands. If you run that code without isolation, you're one bad prompt away from data loss. We watched a demo where an agent's SQL query accidentally dropped a view that three dashboards depended on. The team spent two days recovering. Every team we talked to had a similar story or was about to.
Tool integration. Every data source speaks a different language. Stripe wants API keys. PostgreSQL wants connection strings. HubSpot wants OAuth tokens with refresh flows. Building reliable, authenticated connections to external tools is plumbing work. Expensive, tedious, unforgiving plumbing work. And every team was doing it alone.
Authentication and multi-tenancy. If you're running agents for multiple users or multiple organizations, User A's agent must never see User B's data. This isn't a feature you bolt on. It's an architectural requirement that shapes how you design execution, storage, and networking from day one.
Forty platforms. All building the same foundation. None of them sharing it. That's not a market. That's a collective waste of engineering hours that could have been spent on the parts that actually differentiate: the agent logic, the domain expertise, the user experience.
Why proprietary platforms are the wrong answer
Some of those 40 platforms will succeed as businesses. Most won't. But even the successful ones have a structural problem: they're asking you to trust their code with your data, and they won't let you read it.
Here's what that means in practice:
You can't inspect the code. When something goes wrong — the agent returns a wrong number, accesses a table it shouldn't, leaks data in a log — you can't look at the source to understand why. You file a support ticket. You wait. You get a response that may or may not address the actual issue. You have no way to verify.
You can't customize for your use case. Every business has weird edge cases. Your CRM has custom fields nobody else uses. Your database has a schema that evolved over a decade. Your compliance requirements include a specific audit format. A proprietary platform serves the common case. Your edge cases are your problem.
Vendor lock-in compounds. Month one, you connect your database. Month three, you add your CRM. Month six, you've built workflows, trained your team, and accumulated institutional knowledge in a system you don't control. When the platform raises prices 40% (it will), changes its API with 30 days notice (it will), or gets acquired and shuttered (it happens), you're stuck. Migration means rebuilding all of it.
Pricing scales against you. Most agent platforms charge per query, per agent, or per tool connection. The more you use it, the more it costs. The more successful your AI deployment becomes, the more expensive it gets. Your ROI shrinks as your usage grows. That's backwards.
I'm not saying proprietary software is always bad. I'm saying that for infrastructure — the layer that handles your data, your security, your execution — opaque code is a risk you don't need to take. Especially when open-source code that does the same thing exists.
The open-core model: what's open, what's not
OpenZosma is fully open source under Apache 2.0. Not "source available." Not "open source but you need a license for production." Apache 2.0. The same license used by Kubernetes, TensorFlow, and Android.
You can:
- Self-host it on your own infrastructure
- Read every line of code that handles your data
- Modify it for your specific use case
- Fork it and never contribute back (though we'd love it if you did)
- Use it in commercial products without paying us anything
The cloud version — Zosma Cloud — adds convenience, not capability. Managed hosting so you don't have to run your own servers. Billing and usage analytics. Enterprise features like SSO and audit log exports. Priority support. If you want to self-host and build your own versions of these, go for it. The core platform is the same code either way.
This model works because the value isn't in hiding the plumbing. The value is in making the plumbing work so well that people would rather pay us to manage it than manage it themselves. That's the same model HashiCorp used with Terraform before their license change (which, for the record, we disagree with — and that's why we chose Apache 2.0 specifically).
What OpenZosma actually does
In plain English: OpenZosma is a platform for running AI agents. You define what your agent does. OpenZosma handles how it runs — safely, at scale, connected to your tools.
More specifically:
You bring the agent logic. This could be a LangChain chain, a custom prompt pipeline, a CrewAI crew, or a hand-rolled agent you wrote yourself. OpenZosma doesn't care how you build your agent's brain. It cares about running that brain safely in production.
OpenZosma provides the execution environment. Per-user sandboxing via OpenShell. Each session runs in isolation with defined resource bounds — memory limits, execution timeouts, query caps. If an agent goes wild, the blast radius is contained to that session.
OpenZosma handles tool connectivity. Through MCP (Model Context Protocol), your agent connects to external data sources and services. PostgreSQL, Stripe, HubSpot, Slack, Google Drive — any tool with an MCP server. There are over 10,000 public MCP servers as of early 2026. Your agent doesn't need to know how each API works. It just uses the tool.
OpenZosma manages agent communication. Through A2A (Agent-to-Agent Protocol), specialized agents collaborate on complex tasks. Your billing agent can hand off to your support agent without sharing internal state. They communicate through a standardized protocol, not custom API calls.
OpenZosma logs everything. Every tool call, every query, every intermediate result. Full audit trail. When someone asks "where did this number come from?", you can show them the exact chain of actions that produced it.
If you read our post on what an agentic harness is, you already understand the architecture. OpenZosma is our implementation of that harness — the governance layer that makes it safe for AI to touch real business data.
Key architecture decisions and why we made them
Architecture is a series of trade-offs. Here are the ones we chose and why.
Hono for the API layer
We evaluated Express, Fastify, and Hono. Express is battle-tested but shows its age — callback patterns, middleware ordering quirks, performance that hasn't kept up. Fastify is fast but we found the plugin system added complexity we didn't need. Hono is lightweight, TypeScript-native, and runs on any JavaScript runtime (Node.js, Deno, Bun, edge runtimes).
The deciding factor wasn't benchmarks. It was developer experience. Hono's type inference means you catch routing errors at compile time, not at 2am in production. For a platform where API correctness matters — these endpoints handle your data — that's worth more than a few milliseconds of latency.
Per-user sandboxing via OpenShell
We built OpenShell because nothing that existed did what we needed. gVisor and Firecracker are great for container isolation, but they're infrastructure-level solutions. We needed application-level sandboxing with per-session resource limits, language-agnostic code execution, and tight integration with our audit logging.
OpenShell gives each user session an isolated execution environment. Memory limits. CPU quotas. Network restrictions. Execution timeouts. When User A's agent runs a query, it physically cannot access User B's sandbox. Not at the application level — at the execution level.
We mentioned this in our post on building production agents vs. GPT wrappers — the first time an agent ran SELECT * on a 200GB table with no LIMIT clause, we learned why sandboxing isn't optional. OpenShell exists because that lesson hurt.
A2A protocol for agent communication
Real business problems don't live in one system. "What's our most profitable customer segment?" might require one agent to pull sales data, another to calculate support costs, and a third to factor in marketing spend.
A2A (Agent-to-Agent Protocol) lets agents built on different platforms communicate without sharing internal logic or proprietary data. It's like HTTP for agents. Your LangGraph agent can collaborate with someone else's CrewAI agent through a standardized protocol. No vendor lock-in at the agent level either.
MCP for tool integration
MCP is USB-C for AI tools. Before MCP, every agent platform built its own connector for PostgreSQL, its own connector for Stripe, its own connector for Slack. With MCP, there's a universal protocol. One standard, 10,000+ public servers, 97M+ monthly SDK downloads.
We didn't build OpenZosma to compete with MCP. We built it to use MCP. The tool integration layer is a thin wrapper around the protocol. If there's an MCP server for it, OpenZosma can connect to it. If there isn't, you can write one — the protocol is open, and the SDK is well-documented.
Apache 2.0 for the license
We chose Apache 2.0 specifically because it's permissive. You can use OpenZosma in commercial products. You can fork it. You don't have to contribute your changes back (though the community benefits when you do). There's no "source available" gotcha, no usage restrictions, no "you need a license if you have more than 50 employees."
We considered AGPL. We rejected it. AGPL's network use clause creates legal ambiguity for anyone using the software as a service. If we're telling you to trust our code, we should make it easy for you to use it without talking to a lawyer first.
The India angle
Zosma is built out of India. Not outsourced to India. Built here. Designed here. The architecture decisions, the protocol choices, the product direction — all made by a team that lives and works in India.
I bring this up because there's a persistent narrative that Indian tech companies build things "cheap." That we're the cost-effective alternative. The "good enough" option.
That's not what this is.
OpenZosma's architecture — per-user sandboxing, protocol-native tool integration, multi-agent orchestration — is not a budget version of what Silicon Valley builds. It's what we believe is the right way to build agent infrastructure. Hono over Express. MCP over custom connectors. Apache 2.0 over proprietary licenses. These are opinions, not compromises.
Some of the best infrastructure software in the world is built outside the valley. Kubernetes was designed at Google but its adoption was global. PostgreSQL has contributors from dozens of countries. The next wave of infrastructure software won't come from one geography. It'll come from wherever the best engineers with the best opinions are working. We're working here.
How to get started
If you've read this far, you're probably either curious or skeptical. Both are fine. Here's how to find out for yourself.
Star the repo. github.com/zosma-ai/openzosma. Read the code. We want you to. If something looks wrong, open an issue. If something looks missing, open a PR. The code is the documentation.
Spin it up locally. One command:
docker compose upThat gives you a local OpenZosma instance with a sample agent, a sandboxed execution environment, and the MCP tool registry. Connect your own database, add your own tools, and start building.
Join the community. We have a Discord where people share agent architectures, MCP connectors they've built, and debugging help. There's no gatekeeping. Whether you're running OpenZosma in production or just kicked the tires with Docker, you're welcome.
Why this matters
Every company that's building AI agents in 2026 is rebuilding the same infrastructure. Orchestration. Sandboxing. Tool connectivity. Auth. Multi-tenancy. They're doing it alone, in proprietary codebases, and the result is a fragmented ecosystem where nothing works together.
OpenZosma is our answer to that fragmentation. A shared foundation. Inspectable code. A license that lets you build on it without restrictions. And a community that makes it better faster than any single company could.
We didn't open-source OpenZosma because we're altruists. We open-sourced it because we believe agent infrastructure should be a commons. Like Linux. Like Kubernetes. Like PostgreSQL. The layer that handles your data and your security should be the layer you can read, modify, and trust.
If you're building AI agents and you're tired of rebuilding the same plumbing, give it a look. The code is right there.