In May we published "Introducing OpenGeni: An Agentic Runtime for Organizations" on the Cloudgeni blog. It was the launch post: here is the runtime, here is why it exists, go run it.
This is a rewrite of that article. We're doing it for two reasons. First, most of it turned out to be true, and the parts that held up deserve restating for everyone who found us after May. Second, some of it we'd now say differently, and a few things we simply got wrong. A summer of production use, nearly 2,000 commits, and a lot of conversations with security teams will do that.
So: the original argument, kept where it held, revised where it didn't, and extended with what the runtime taught us since.
The argument, restated
The original post started from an observation we still stand behind: building an agent demo takes a weekend. Making it production-ready (durable state, queueing, approvals, sandboxing, budgets, an audit trail) is the other 90%, and every team rebuilds that 90% from scratch.
We'd seen the failure mode up close. Ten engineers, each running their own agent setup, each with their own credentials, each with their own idea of what the agent is allowed to touch. Nobody's quite sure what any of them did. The tooling available at the time forced a false choice: powerful but ungoverned, or governed but underpowered.
Opengeni is our answer to that: an open, self-hostable service for long-running, side-effectful AI agents. Durable sessions, replayable event history, human approvals, governed credentials and memory, and a choice of where every session runs, all behind one HTTP API your product builds on.
The distinction we drew in May matters even more now that the agent space is louder: Opengeni is the runtime, not the agent. Any SDK gives you the loop. The loop, on its own, holds credentials, forgets everything on restart, streams to nobody, stops whenever the model feels done, and answers to no one. None of that survives a security review. The runtime is everything around the loop that makes it survivable.
First, a correction
The original post said Opengeni is MIT licensed. That was wrong, and the live post still says it. Opengeni is Apache-2.0, all the way down: the API, the web app, the workers, the Helm chart, the reference Terraform. No restricted core, no enterprise-only self-hosting, no gated tier. Since "actually open" is a load-bearing part of our pitch, we'd rather correct the record loudly than quietly.
What held up
The May post said safe agent adoption requires solving four things at once: centralized data access, centralized credentials, deliberately designed agent behavior, and an interface simple enough that end users don't need to understand the machinery. That framing survived contact with reality almost intact. It just got a lot more specific:
Credentials became Variable Sets: named, encrypted secret collections scoped to an organization, a workspace, or a single person, with exactly one permissioned plaintext read path and value-free audit everywhere else. Agents get scoped, short-lived access per task. The long-lived key taped to a cron job is the thing this replaces.
Data access became documents, retrieval, and governed memory (more on memory below, because that's where the real lesson was).
The simple interface became more than a chat window. The React console is just one client of the API. Slack turned into a first-class front end: a task inbox, reaction summon, scheduled runs. And an embedding SaaS product can put the whole runtime behind its own brand.
Sandboxed execution grew into eleven compute targets, from Docker to Modal to Cloudflare to your own hardware. One of those eleven changed our roadmap, and it gets its own section.
What we'd revise: workflows were the wrong noun
The one piece of the original framing we'd genuinely walk back is "defined workflows." In May we argued organizations need deliberately designed agent workflows: which actions, in what sequence. What we've since watched, in our own operations and in customer environments, is that configured workflows follow a predefined path, and the path is exactly what changes. The interesting work is the run where step three fails and the agent has to try something the workflow author didn't anticipate.
So Opengeni moved from workflows to goals. A goal is a durable statement of the outcome, and while it's active, the runtime keeps waking the session until the agent either completes it with evidence or pauses it with a rationale. Humans can steer mid-run, approve or deny individual actions, pause a whole subtree, or rewrite the goal. The structure lives in the guardrails, not in a flowchart.
Which leads directly into the biggest thing we learned.
What we learned since
1. The most common agent failure isn't hallucination. It's premature victory.
The model declares success and stops, three steps before the job is done. No prompt fixes this reliably, because stopping is the model's default. Goals flip that default: stopping becomes an explicit act, backed by a durable obligation in Postgres that survives worker deaths and restarts. The runtime nags so your engineers don't have to.
And deliberately, there is no cap on run length. Runs legitimately last days. Our longest continuous goal-driven session so far ran for 18 days, self-healing across provider hiccups and restarts the whole way. We bound execution with budgets and explicit human control, never with a timer that guesses the agent must be stuck.
2. Reliability is a runtime property, not a model property.
Every one of our reliability lessons reduced to the same shape: the model was fine, the platform wasn't. So the architecture became an exercise in deciding what's allowed to be lost. Postgres remembers; NATS broadcasts. The durable event log is the source of truth, the realtime bus is a nudge, and the orchestrator coordinates without ever holding the conversation. Any of those can blink and the run survives, replayable from the log.
The same principle applies to failure itself. A provider outage, a context overflow, an exhausted budget: these idle the session with its context preserved, they don't kill it. Even a failed session revives when the next message arrives. Only an explicit cancel is terminal. Unglamorous, and exactly the difference between a runtime you trust and one you babysit.
3. "Can it run on our machines?" is not a preference. It's a compliance requirement.
This was the single most common question we heard at Cloudgeni, and for banks, healthcare vendors, and the public sector it's a hard gate. So the biggest addition since May is Connected Machines: your own always-on hardware as a first-class compute target, co-equal with every cloud sandbox. The machine dials out to the control plane, so nothing needs to be routable to it. The platform never mints or pushes credentials onto it, never clones repositories onto its real disk, and never provisions or kills it. Enrollment is a loud, consented device flow with one-click revocation, and the whole feature is off by default until an operator turns it on.
One honest caveat, because honesty is cheaper than a churned deployment: a Connected Machine keeps command execution local, but strict data locality needs the whole path local, model included. We say this in the docs too.
4. Memory has to be governed like a credential, not scribbled like a scratchpad.
Agents that forget everything redo work. Agents that remember everything, unsupervised, become a liability: one wrong "fact" self-reinforcing across every future run. The original post's "centralized data access" undersold this problem.
Today Opengeni keeps three stores with three jobs: the exact conversation history the model sees, the control state that manages pauses and approvals, and the append-only audit timeline that is never fed back to the model. On top of that sits reviewed workspace memory: agents propose memories, and a human (or your API) approves them before they become retrieval context. Learning is a policy you set per workspace, from off to suggest to automatic, and every activation is auditable and revocable. We retired the blanket "agent writes whatever it wants to memory" tool from the default surface, and we don't miss it.
5. The model is a swappable dependency, not an identity.
Since May the hosted-agent world has kept proving why this matters: products deprecated within a year of launch, tools absorbed into other tools, pricing rewritten under running workloads. A hosted vendor's roadmap becomes your roadmap.
Opengeni treats the model as a governed route. Direct OpenAI, Azure OpenAI (including keyless Azure AD auth), a gateway with pinned fallback routes, or any provider you declare in a config file. The newest piece: your team's existing ChatGPT/Codex and SuperGrok subscriptions plug in as first-class capacity, with per-workspace rotation, cooldown, and durable capacity recovery. When a subscription hits its cap, the session waits and resumes; it doesn't fail. Swapping the model must never silently swap who pays or who's accountable, so accepted provider identity is enforced at execution time.
6. The workspace wasn't a big enough tenancy boundary.
The original post was written for "a team." Real adopters showed up as organizations: many workspaces, people joining and leaving, personal resources that follow a person across the workspaces they can access, and offboarding with an actual retention policy instead of a shrug. A large share of this summer's work went into that organization layer, along with usage metering, budgets, and insights dashboards, because "who spent what, on whose authority" is a question every platform team eventually asks with a deadline attached.
7. The strange loop is the proof.
The most surprising development since May is who does the development. Opengeni builds Opengeni: agents on the runtime write a large share of the commits, under the same goals, approvals, and audit trail we ship to everyone else. Nearly 2,000 commits have landed since the release, from a team you can count on one hand, nobody crunching, with hundreds of agent-built PRs merged. The guide we keep for agents is now longer than the README we keep for humans, which might be the most honest metric we have.
We didn't relax the rules to go faster. The rules are why we could go faster.
The guardrails we originally built for banks and platform teams turned out to be the very thing that let us trust the loop with our own codebase.
On Cloudgeni
The original post's line still holds: Opengeni doesn't replace Cloudgeni. Cloudgeni is the opinionated, productized AIOps system, with pre-built workflows for drift, IaC governance, and compliance. Opengeni is the runtime underneath it, extracted from two years of running those agents against live production cloud infrastructure, for teams whose problems don't fit a pre-built box. Same engine and destination, different cars. And these days the engine also builds the cars: Cloudgeni runs on Opengeni, and so does our own engineering.
Who this is for
Also unchanged: platform teams making AI a governed participant in their infrastructure, SREs who want agents held to the same standard as human operators, engineering leaders who need adoption without shadow AI, SaaS builders who want agentic features without six months of platform engineering, and anyone who wants a reference implementation of the whole 90%. If you're a solo developer who wants a coding agent on your laptop, there are excellent tools for that; this is for when the agent has colleagues.
The ask is the same as in May, with more confidence behind it. It's Apache-2.0, it's at github.com/Cloudgeni-ai/opengeni, and the fastest way to form an opinion is to run it. When you hit a gap, tell us in the issues. Much of what's described above started life as exactly that kind of report.
Built in Oslo, Norway. Increasingly, by the thing itself.