Introducing OpenGeni: An Agentic Runtime for Organizations

OpenGeni architecture

The Infrastructure Agents Guide laid out the architecture. OpenGeni is the implementation — an open-source agentic runtime built for orgs, not single developers.

When we open-sourced the Infrastructure Agents Guide a few months ago, the response we kept hearing was a version of the same question:

"Great. Now where's the code?"

That's fair. A 13-chapter reference architecture is useful, but most teams don't have the time or the desire to assemble all the layers themselves. They want an opinionated implementation they can fork, run, and trust.

Today we're open-sourcing OpenGeni. It's a self-hostable managed agent service for long-running infrastructure work, built on the same architectural principles described in the guide. MIT licensed. Available on GitHub now.

→ github.com/Cloudgeni-ai/opengeni

Why another agent runtime?

There's no shortage of open-source agent projects. We respect what OpenClaw, the pi runtime, and similar tools have done — they're excellent at what they're built for, which is being one developer's agent. It doesn't matter whether you run them on your laptop, your Mac mini, or a cloud VM you spun up yourself. The architecture assumes one human, one workspace, one set of credentials. Giving other people access to it, is something the design actively works against.

But exactly the problem we hear from platform teams.

Their problem looks more like this: ten engineers, each running their own agent setup, each with their own credentials, each with their own MCP servers, each with their own opinions about what tools the agent should have. The agents do useful work. Nobody's quite sure what they did. Nobody's quite sure what they had access to. And when someone leaves, the institutional knowledge of "how the agents are wired" walks out the door with them.

A single-user agent runtime doesn't scale to that situation. It was never trying to.

The other path teams consider is the guardrailed offerings from the hyperscalers. These exist, and they're safer by default. But they're also closed — bound to a single cloud's services, with the agent's tools and workflows fixed by what the vendor decided to ship. The moment you want to add a custom tool, integrate a non-vendor system, or define a workflow that isn't on the menu, you're stuck.

You end up with two bad choices: powerful but ungoverned, or governed but underpowered.

What we believe

Safe AI adoption at an organization isn't a single-agent problem. It's a platform problem.

It needs four things, and they all need to be solved together:

Centralized data access. The agent should pull from the same source of truth your team already uses — not from whatever a developer happened to wire in locally.
Centralized credentials. Long-lived keys in .env files don't scale safely past one person. The platform issues scoped, short-lived credentials per task.
Defined workflows. What the agent does, and in what order, is a deliberate design decision — not an emergent property of someone's prompt.
A simple internal interface. End users — your engineers — shouldn't need to know how the agent works. They should ask for a thing and get it.

These principles are what the Infrastructure Agents Guide describes in detail. OpenGeni is the implementation of all four, in one runtime.

What's in the box

OpenGeni isn't a framework or an SDK you assemble. It's a service you run.

┌─────────────────────────────────────────────────────────┐
│                  YOUR INTERNAL USERS                    │
│         (engineers asking for an infra change)          │
└──────────────────────────┬──────────────────────────────┘
                           │
                ┌──────────▼──────────┐
                │   SIMPLE INTERFACE  │   ← chat, API, or CI
                └──────────┬──────────┘
                           │
              ┌────────────▼────────────┐
              │     OPENGENI RUNTIME    │
              │  Workflows · Sessions   │
              │  Tools · Skills · Audit │
              └────────────┬────────────┘
                           │
        ┌──────────────────┼──────────────────┐
        ▼                  ▼                  ▼
┌───────────────┐  ┌───────────────┐  ┌───────────────┐
│  CREDENTIALS  │  │   SANDBOXED   │  │ OBSERVABILITY │
│   (scoped,    │  │   EXECUTION   │  │  (traces,     │
│   short-lived)│  │               │  │   audit logs) │
└───────┬───────┘  └───────┬───────┘  └───────────────┘
        │                  │
        ▼                  ▼
┌─────────────────────────────────────────┐
│            YOUR INFRASTRUCTURE          │
│       AWS / Azure / GCP / OCI           │
└─────────────────────────────────────────┘

Out of the box you get:

A workflow engine for defining what the agent does and in what order, with explicit human-in-the-loop checkpoints where you want them.
A credentials broker that issues short-lived, scoped tokens per task instead of handing the agent a service principal for life.
Sandboxed execution for any tool that touches infrastructure, so a bad call can't cascade beyond the sandbox.
Pull-request-based change control — the agent opens diffs, CI validates, humans approve. The same pipeline applies whether the change came from a person or an agent.
Session and audit logging that ties every action back to the user who requested it.
A simple chat-and-API interface your team can use without thinking about any of the above.

If you've read the guide, this is the reference architecture, made concrete.

OpenGeni and Cloudgeni

People ask whether OpenGeni replaces Cloudgeni. It doesn't.

Cloudgeni is the opinionated, productized version. Same foundations, but it ships with a particular set of workflows already designed and battle-tested for the problems we hear most: keeping drift away, managing your IaC, resolving compliance and security findings, and making every engineer follow the infrastructure standards your platform team has defined. Plug-in-and-go for those use cases, with the SLAs and enterprise support to match.

OpenGeni is the foundation. If your workflows look like others', Cloudgeni is the faster path. If they don't — if you have a uniquely opinionated platform team, a non-standard tech stack, or an internal workflow that isn't on our roadmap — OpenGeni gives you the runtime to build it yourself, on the same architectural principles we use ourselves.

Same engine and destination. Different cars.

Who this is for

Platform teams building an internal developer platform where AI agents are first-class participants, not bolted-on copilots.
SREs who want infrastructure agents to operate at the same level of governance their humans already do.
Engineering leaders who want a path to safely scale AI adoption across the org, without each team reinventing credentials, sandboxing, and audit from scratch.
Builders who've read the Infrastructure Agents Guide and want a working reference implementation to start from.

If you're a solo developer who wants your own agent, OpenClaw is probably what you want. If you're an org that wants AI to do real infrastructure work across multiple teams, multiple clouds, and multiple workflows, OpenGeni is built for you.

Go run it

The repo is live. MIT licensed. Self-hostable on your own infra, in your own cloud, with your own credentials.

→ github.com/Cloudgeni-ai/opengeni

If you want the same architectural layers without running them yourself, that's what Cloudgeni is for. But either way, the runtime should be solid. Build on it.

Found a gap? Have a workflow you wish OpenGeni shipped with? Open an issue or start a discussion on the repo. We're shipping fast and would rather hear from you now than later.