Rome OS has released the source code for Rome, a self-hostable environment for running AI agents that its README labels “the agentic OS.” The repository, rome-os/rome on GitHub, ships under an MIT license and includes an agent runtime, a web dashboard, and a desktop shell, all installable through a single Docker script or a hosted preview called Rome Cloud.
The project’s central claim is architectural, not a model claim. Most labs chase capability by making models larger. Rome instead builds the layer a model operates inside: the tools, memory, and workflows an agent can draw on across sessions. The README frames this as a guardrailed space where a human (the project calls this role a guardian) and an agent work together, with proven capabilities persisting into the next interaction instead of resetting when the conversation ends.
The distinction the documentation draws between a workflow and an app is the most concrete part of the pitch. A workflow runs a task once and returns a result, close to a single agent call in most existing frameworks. An app is different. It keeps a database, a purpose-built interface, and its own agents that stay active after the browser closes and the user returns the next day. The README’s own examples make the point: an inbox that recalls what it already sorted, or a tool watching a game’s price and pinging only once it drops below a threshold set days earlier. Both treat state and scheduling as core parts of the system, not something stitched on with a cron job and a side database.
Each app is defined by an app.yaml manifest that can bundle typed actions other agents can call, app-owned agents with their own instructions, plain-language skills loaded on demand, hooks into message and event lifecycles, a web interface, and persistent app-private storage. Two public SDKs, an app-runtime package for the backend and an app-web-sdk for embedded interfaces, let outside developers build to the same model the first-party apps use. Finished apps stay as ordinary git-tracked code, publishable to a Rome App Store so others can install them.
That last point is the README’s clearest technical commitment: nothing here is described as hidden model state. Everything an agent builds is inspectable source, a contrast the documentation draws explicitly against systems that keep capability locked inside opaque weights or private prompt chains. What the README does not supply is evidence that this holds up past the demo cases: no benchmark, no adoption figure, no named user beyond the generic guardian role.
Persistent-memory agent frameworks with app-like packaging are not new. LangGraph, AutoGen-derived orchestration layers, and various MCP-based tool stacks have made structurally similar arguments over the past two years without any one of them becoming a default choice. Rome’s specific bet, that a workflow-versus-app split enforced at the manifest level is worth its own runtime rather than a library layered onto an existing agent stack, is the part a team would need to test directly rather than take from the README.
For a team weighing this against a framework it already runs, the real question is not whether Rome can execute a task, most agent stacks can, but whether bundling persistent state, a dashboard, and scheduled follow-through into one installable unit is worth adopting a new monorepo and its own SDKs to get. The README does not address migration cost, hosting price past the free Docker path, or how the paid Rome Cloud preview will eventually be priced once it leaves preview. Teams running agents in production on an established framework have no stated reason here to switch before those specifics arrive.
Based on the rome-os/rome repository README, published on GitHub by Rome OS.
