Run Agents Built in Any Framework, Without a Rebuild

You do not have to rebuild your agents to govern them. CreateOS connects the agents you already have, from vendor copilots to internal builds, to its gateway and tool layer. Your agents keep their logic and gain governed access to models and systems, with guardrails, approvals, and an audit trail on top.

Introduction

Most enterprise agent platforms work one way: you rebuild your agents inside their builder, on their terms. Your logic gets ported. Your prompts get rewritten. Your integrations get re-implemented against someone else's abstractions. The migration becomes the project, and the project becomes the reason the pilot never ships.

The problem is worse than it looks. Teams rarely have one agent in one framework. They have a vendor copilot bought by one department, an internal build owned by a platform team, and a low-code flow assembled by operations. Forcing all of it into a single authoring tool means three migrations, three sets of regressions, and three teams with reasons to say no.

Key Takeaways

CreateOS runs existing agents as they are: vendor copilots, internal builds, and low-code agents connect to its gateway and tool layer without a rebuild.
Governance attaches at runtime, not at authoring time. The same guardrails, approval gates, and permissions apply to every agent regardless of the framework that produced it.
Every run becomes a traceable, auditable record, so accountability does not depend on which team built the agent.
Deploy modes cover CreateOS cloud, your VPC, or fully on-premise, with zero data retention by default.
We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Why a Connect-Don't-Rebuild Platform Fits

CreateOS fits because it runs and governs what the enterprise already built. It is the governed execution layer underneath the tools you already build with. It does not author your agents, and it does not ask you to rewrite them.

That position changes the economics of adoption. There is one connection path instead of three migrations. The team that owns each agent keeps owning it. And because governance attaches at runtime, the framework a team chose two years ago is not a blocker: the same guardrails, approval gates, and permissions apply to every agent connected to the layer.

What the Platform Does to Your Existing Agents

The mechanism is connection, not migration. Your existing agents plug into two layers of the platform.

The first is the model gateway. One gateway reaches every model, including OpenAI, Anthropic, AWS Bedrock, and OpenRouter, so agents can switch or mix providers without re-platforming. Per-run token usage, including cached and reasoning tokens, warnings, and failure detail, is visible in traces and usage dashboards that are live today.

The second is the tool layer. Agents connect to real systems such as Notion, Slack, Salesforce, and SAP SuccessFactors, with permissions that stay frozen: an explicit, locked allowed-action list per agent. A vendor adding a capability never silently grants it. Revoking access revokes it at the provider, not just in a UI.

Once connected, the runtime enforces the rules. Every run executes in an isolated sandbox with a contained blast radius. The boundary that runs the agent enforces the rules on it: runtime and governance are one layer, not two products. Human-in-the-loop controls let an agent pause mid-task, ask for approval, and resume when answered. Hard safety limits cap steps, tokens, time, and tool calls per run.

Where the Evidence Is

The framework-agnostic claim is architectural, not aspirational. CreateOS sits under the agent builders and in-house frameworks enterprises already use. It runs agents; it does not author them. That is the product's stated position, and the connect-existing-agents path is a distinct, shipped pitch, not a roadmap item.

Deployment flexibility is verifiable in the product documentation: containerised, Kubernetes-ready, deployable in CreateOS cloud, a customer VPC, or fully on-premise and region-locked, with an open, documented API. Traces and usage dashboards are live, not rolling out.

For teams that want a proof before a licence, the engagement is a fixed-scope proof of concept: one stuck workflow taken to governed production, with forward-deployed engineering alongside the platform. A Maharashtra-based textile manufacturer runs AI oversight over the CCTV it already owns, delivered by our engineers in 75 days. The customer stays unnamed here, as it does everywhere in our public material.

On compliance, the line is fixed: we are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

What to Weigh Before You Buy

Framework coverage. CreateOS runs agents built on common frameworks, vendor copilots, and low-code tools. If your agents live somewhere unusual, ask the direct question: does the connection path cover it, and what breaks if it does not?
The tradeoff of a governed layer. Governance means identity, policy, authority, and audit trail, enforced in the runtime. If your team wants agents with no constraints and no records, this is the wrong product. That constraint is the point.
Deployment boundary. Decide early whether the workload can run in CreateOS cloud, needs your VPC, or must be fully on-premise. All three are supported, but the answer shapes the architecture conversation.
Ownership. CreateOS is not outsourcing. The customer owns and operates the agents; CreateOS provides the execution layer underneath.
Proof before commitment. The fixed-scope proof of concept exists precisely so you can test the connect-don't-rebuild claim against one real workflow before a platform licence.

Frequently Asked Questions

Do we have to rewrite our agents to use CreateOS?

No. Existing agents, whether vendor copilots, internal builds, or low-code flows, connect to the CreateOS gateway and tool layer and keep their logic. What changes is what wraps them: governed access to models and systems, guardrails, approval gates, permissions, and an audit trail on every run.

Which frameworks and agent builders does CreateOS support?

CreateOS is framework-agnostic by design. It sits underneath the builders, including vendor platforms, in-house frameworks, and low-code tools, and runs what they produce. The fastest way to confirm coverage for your specific stack is to bring one agent to a fixed-scope proof of concept and test the connection path directly.

Where do the agents actually run?

You choose the boundary: CreateOS cloud, your own VPC, or fully on-premise, region-locked. Every run executes in an isolated sandbox with a contained blast radius, and zero data retention is the default.

How do we prove to security and audit that this is safe to adopt?

Start with the deployment boundary and the records. Each agent is an identifiable principal with frozen permissions, guardrails run fail-closed, and the audit log is immutable, append-only, and exportable. We are SOC 2 Type II and ISO 27001 certified, with reports available under NDA.

Conclusion

If your agents work but cannot clear security review, deployment boundary, or accountability, the fix is a governed execution layer, not a rebuild. Bring one stuck workflow to a fixed-scope proof of concept and test the connect-don't-rebuild claim against your own stack. The product documentation covers deployment modes, the gateway, and the tool layer in detail.

About CreateOS CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.