The Long Way Home
The story of OpZero, from a Lovable prototype to Oz OS—and the question that held it all together.
When you are close to a project moving this quickly, it does not look like a story. It looks like debris: repositories multiplying, names changing, branches that almost became products, products that became packages, packages that disappeared into a monorepo, experiments deployed for a day and then replaced by the lesson they taught.
From a few steps back, the curve is much easier to see.
If the work feels overwhelming from the inside, that is not evidence that it lacked direction. It is what changing abstraction levels this many times in a few months feels like.
OpZero has been many things in less than a year: a deployment service, an MCP server, an organization, an authentication kit, a remote coding surface, a machine hub, an infrastructure control plane, a platform, a source-control system for agents, and now the beginnings of an operating environment. But underneath all of those forms, it has kept asking the same question:
What would have to be true for a person to describe software to an agent and receive something real—durable, owned, operable, and safe?
Every version of OpZero has been an attempt to remove one more hidden “and then a human has to…” from the answer.
describe → deploy → operate → connect → react → decide → evolve → inhabit
That is the story.
Before OpZero had a name
The history begins before the first OpZero repository.
In late January 2026, a prototype repository eventually called open0p was still visibly a Lovable project. Its README was the untouched Lovable starter, its HTML still called itself “Lovable App,” and its stack was the familiar generated Vite, React, shadcn, Tailwind, and Supabase shape. January 27 is the first credible date in the working history—not necessarily the day the idea began.
But the first day’s product was already pointed beyond Lovable. Within its first hour, the hero did not promise another prompt-to-page generator. It said:
Deploy from AI agents without human CLI.
That sentence contains almost the entire future project in miniature.
Lovable had demonstrated the intoxicating part: a person could describe a thing and watch software appear. It also made the remaining gap impossible to ignore. Generating an application was not the same as owning its runtime. Publishing was still a button inside somebody else’s product. Identity, infrastructure, provider accounts, deployment state, logs, and recovery all lived outside the conversation.
So the earliest OpZero work began inside the kind of system it wanted to outgrow. Within hours, the Lovable shell gained a backend, file upload, API-key management, a real deployment flow, live deployment logs, and an MCP edge function. By the next day it had WebContainer previews, a hosted remote MCP server, OAuth consent, server-sent events, rate limiting, Cloudflare deployment, dynamic client registration, and the beginnings of an in-app agent.
The product was first called Deploy.dev, then renamed Open0p. The copy positioned it as an open alternative to Lovable, Bolt, and Replit: bring whichever AI you already use, and deploy to whichever provider you choose. The zero was not yet an operating system. It meant zero setup, zero lock-in, zero need to cross the last mile by hand.
Then the project began removing its own inherited scaffolding. A Next.js application grew alongside the Lovable/Vite app. Application data began moving from Supabase to Neon; Supabase still handled user sessions, while the application began owning the OAuth server presented to agents. The Open0p URLs and branding began becoming OpZero.
On February 2, the first commit in the repository we now recognize as OpZero arrived with an unusually honest message: “Next.js migration from Lovable/Supabase to Neon.” It was a huge first commit because it was not really a beginning. Git-object comparison proves that all 177 files were exact same-path, same-blob copies from the nested open0p/next-app, leaving out only local settings and an environment example. This was not a resemblance or a rewrite; it was an extraction.
The new repository marked a crossing. The idea had already survived enough contact with reality to know that deployment could not be a decorative feature attached to an AI builder. It had to become a service agents could call directly.
The GitHub organization followed on February 3. OpZero’s history was not born cleanly inside a company-shaped container. The container formed around work that was already moving.
The first promise: let the agent finish the job
The first OpZero was easy to explain. Give an agent files, and let it put them on the internet.
It supported Netlify, Vercel, and Cloudflare. The surface was an MCP endpoint rather than another proprietary editor. The user could bring Claude, ChatGPT, Cursor, Windsurf, or whatever came next. OpZero’s job began where generation stopped: accept an artifact, choose a target, deploy it, return a URL, and preserve enough state to operate it later.
This was already more radical than “AI deployment” sounds. It moved the control point away from a dashboard and into the agent’s working context. A deployment was no longer the thing a human did after the agent finished. Deployment became part of what finishing meant.
But a real deployment immediately creates obligations. Someone must own it. Credentials must be granted without being pasted into prompts. An MCP client must discover how to authenticate. Tokens must refresh and revoke. Providers disagree. OAuth clients behave differently. A generated app needs logs, state, limits, and a path back when something fails.
The first repository started discovering the shape of a platform simply by trying to keep its first promise.
Every hard boundary became a project
AuthKit was the clearest example.
OAuth was not extracted because the ecosystem needed another abstract authentication library. It was extracted because real MCP clients repeatedly broke the illusion that “add OAuth” was a single feature. Protected-resource metadata, authorization-server discovery, dynamic registration, PKCE, refresh and revocation, browser consent, first-party trust, provider quirks, and session headers all had to agree. If identity remained tangled inside the deployment application, every new service would repeat the same mistakes.
So MCPAuthKit appeared on February 7, followed by a Vercel-and-Turso variant two days later. What began as reusable OAuth plumbing gradually became the trust spine of the ecosystem: the place where a browser user, an MCP client, an assistant, a hosted agent, a machine, and an owner grant could be related without pretending they were the same principal.
The same pattern repeated. Infra appeared in mid-February as a Railway, OpenTofu, and SOPS control plane. Backend and UAT repositories separated operational concerns. token-5-0 explored another identity boundary. A CLI followed in March. Organization-wide profile and context repositories appeared in April. skillz treated reusable agent knowledge as its own public artifact.
Seen as a repo list, this period looks like sprawl. Seen as inquiry, it is more coherent: every time the original deployment flow hit a boundary that could not be solved honestly inside one application, that boundary became visible enough to earn a name.
This is when an important OpZero instinct emerged: solve each problem once, well, and then level up. The repositories were a way of learning the nouns of the system before the system knew its own grammar.
CodeZero, CodeZ, and the Hub: giving the agents somewhere to work
Deployment was only the last step. If agents were going to carry work all the way to production, they also needed a durable place to do that work.
CodeZero began in April as a mobile-capable interface to Claude Code. It made remote coding sessions reachable from a phone, then added terminal channels, permissions, PWA behavior, voice and search, remote MCP access, AuthKit integration, and a first kind of self-healing. The public CodeZ repository explored a distributable version of the idea.
The key insight was not “put a terminal on a phone.” It was that an agent session should be a persistent platform object rather than a fragile process attached to one laptop. Sessions needed machines. Machines needed identity. Messages needed channels. A user needed to leave, return, and continue without reconstructing the world.
CodeZero made one agent session tangible. The Hub, started a few days later, made many sessions and machines coherent. It became the switchboard: machines could eventually dial outward, sessions could be created and observed, state changes could be awaited instead of constantly polled, and the intelligence could remain in the client rather than being buried in a central monolith.
This was the second expansion of the original promise. OpZero no longer meant only “an agent can deploy.” It meant “an agent can keep working across time, machines, and interfaces until the deployment is real.”
The shape that became Oz OS was already trying to appear. In July, a monorepo commit explicitly turned the CodeZero UI into “the platform home,” bringing projects, deployments, assistants, servers, machines, and sessions into one surface. That was not yet the right final surface, but it revealed the need: a collection of capabilities eventually asks for a place where they can be seen and used together.
The constellation, and why it had to collapse
By April, OpZero had become an ecosystem in the literal sense. There was the original deployer, AuthKit, CodeZero, CodeZ, the Hub, a container, Infra, the CLI, skills, backend services, and experiments around them. An umbrella repository first gathered several of them as submodules. In other words, the work assembled a monorepo-shaped view before it assembled a monorepo.
That distinction matters. Consolidation did not happen because the earlier projects had been mistakes. It happened because their boundaries had taught enough.
By June, the cost of separation was becoming a user problem. A person did not want to understand which repository owned identity, which one knew about machines, which one had the UI, and which one deployed the result. They wanted one login, one place to work, and one path from code to a running thing. Shared types and protocol behavior were being copied across repositories. Fixes landed in one place and had to be ported to another. The ecosystem had successfully decomposed the problem; now it was making the user perform the composition.
An umbrella repository began describing a migration in mid-June and then said the quiet part out loud: rename this repository to platform.
On June 19, the platform monorepo was initialized. CodeZero, the Hub, AuthKit, the website, backend work, and shared UI and runtime packages moved under one Bun/Turborepo roof. Identity, protocol, storage, channels, and transport became shared substrate rather than copied solutions. The old repositories began becoming frozen migration sources and extraction candidates rather than competing centers of gravity; some still served production while their cutovers caught up.
The repo multiplication and the reconsolidation are not opposite movements. They are the two halves of architectural compression. First the project pulled the problems apart far enough to understand them. Then it put the understood pieces back together so users would not have to.
What did not come into the house
Consolidation also clarified what did not belong.
The Vercel AuthKit repository remained a legitimate alternative implementation. skillz remained useful as a discrete public content project. UAT was eventually removed from the monorepo when it no longer justified its footprint; the knowledge reappeared in conformance work that could state exactly what a client or server had proven. The public oz-mcp-labs organization gave unsettled MCP questions names and clean extraction boundaries—auth, conformance, triggers and events, agents, apps, runtimes—without pretending every named avenue was already a product. Some of those repositories remained deliberate seeds. The event harness, for example, was a statement of intent rather than a secretly finished system.
Infra is the most interesting case because it was both left behind and far ahead.
Its concrete implementation coordinated the other repositories from outside: clone them, provision them, move secrets, orchestrate Railway and OpenTofu. Folding that machinery into the monorepo would have been circular and runtime-incompatible. The implementation belonged elsewhere.
But Infra’s February architecture had already named ideas the platform would spend the rest of the year rediscovering in better forms: identity and policy, contract graphs, deterministic replay, orchestration, evidence, rollback, deployment control, immutable artifacts, and an append-only causal event ledger. Infra was not a wrong turn so much as a correct systems intuition living in a premature container.
That is true of many “abandoned” avenues in this history. They were sketches of needs whose eventual homes did not exist yet.
Providers changed meaning
In the first OpZero, a provider meant somewhere to deploy: Netlify, Vercel, or Cloudflare.
In the platform, providers also came to mean somewhere an agent could act: Notion, Linear, Sentry, GitHub, Atlassian, Stripe, and eventually OpZero itself.
That shift captures the project’s changing scale. At first, OpZero transported files to infrastructure. Later, it assembled capabilities around a user. Connecting an external system was not merely saving an API token; the platform had to distinguish the platform user from an end user, issue explicit grants, restrict tools, preserve auditability, and keep credentials out of workload code.
AuthKit became more than login. It became authority. The Hub became more than session routing. It became continuity. The deployer became more than a build endpoint. It became a host for user-authored MCP servers and agents. The website became less a control panel and more the provisioning plane behind a growing runtime.
This was the point where “platform” stopped being an aspirational repo name. The parts had begun to depend on shared identity, shared storage, shared grants, shared events, and shared proof.
From requests to events
The original system waited to be asked. By late August, it had started learning how to react.
Assistant triggers added authenticated webhooks, schedules, queues, retries, dead letters, idempotency, and limits on unattended model spend. Signals explored a more deliberate pipeline: receive something from the world, normalize it, run deterministic gates, optionally ask a model to judge, dispatch only an allowlisted action, and record what happened.
The closed-loop runtime pushed that idea further. An event should not jump straight to a tool call because a model found it persuasive. It should become state, evaluation, proposal, policy, authority, capability, action, expectation, verification, and a decision record. The model could interpret ambiguity, but it could not silently grant itself authority.
This distinction is one of the project’s deepest pieces of maturity. The goal stopped being “make agents autonomous” and became “make agency accountable.”
The work on self-healing shows that maturity especially well because several different ideas carried the same label.
CodeZero shipped a practical deterministic healer: a reconciliation loop that cleaned stale discovery files, orphan processes, bridges, and configuration drift. Event-driven assistants shipped. Signals and the closed-loop kernel landed in the repository, but their design records at the time still marked them not yet deployed. A substantial telemetry-healing branch connected platform failures to bounded CodeZero repair sessions, but it remained an unmerged experiment and still lacked the isolated low-privilege repair identity it needed.
Calling all of these “self-healing” would make a bigger claim and tell a smaller story. The actual progress was learning to separate hygiene, detection, judgment, authority, repair, and verification. Real healing is not an agent improvising with production credentials. It is a bounded control loop whose recovery path cannot be destroyed by the thing it is repairing.
That same principle would become essential when the software began changing itself.
_src: source control after agents become the primary authors
Conventional Git workflows are organized around human-operated worktrees and forges: clone a repository, materialize a worktree, edit files, stage a selection, construct a commit, push it over a wire protocol, and negotiate a merge.
Agents can perform those rituals, but the rituals are not what makes Git valuable. The valuable parts are content addressing, immutable history, branches, comparison, review, conflict detection, and controlled movement of a canonical head.
_src asked what source management should look like if agents—not humans—were the primary readers and writers, and if deployment—not a developer laptop—were the environment it served.
The answer retained Git’s valuable primitives—content addressing, immutable history, refs, comparison, and controlled head movement—without requiring all of Git’s ceremony. A hosted MCP service could expose snapshots, branches, proposals, comparison, rebasing, and a merge queue directly. Mutations carried an expected head and an idempotency key. Compare-and-set prevented two agents from winning the same race. Protected main moved only through finalization. The merge queue evaluated a proposal against the projected base rather than an imaginary frozen repository. Large objects could live outside the serialized control plane while retaining checksums and identity.
Most importantly, deployments could stop being mutable bags of uploaded files. They could become (repository, commit) pointers.
That connection made _src more than a Git experiment. It joined authorship to the operating system. A deployment could know exactly which source state produced it. An agent could propose a change without gaining the right to ship it. A bad user-code merge could leave the survivable platform-owned host and repair path alive. Evolution could become a governed operation rather than a euphemism for overwriting production.
The September self-evolving-codebase experiment made the lesson concrete. An Evolver assistant improved a tiny live repository across generations. In one generation, however, the model finalized its own proposal without deploying and measuring it. The change happened to be good. The process was still wrong.
The response was not a better prompt. The authority moved into code.
In that experiment, a deterministic conductor classified the proposal, ran tests and policy gates, deployed it, measured fitness, finalized only an improvement, and rolled back a regression. Scout, Builder, and Critic assistants could inspect, propose, and challenge. None of them could declare victory. In the first run of that stronger loop, a regression was rejected and rolled back in seconds.
The breakthrough was not that a model could rewrite code. Models could already do that. The breakthrough was separating imagination from authority:
Let the model write the change. Let code decide whether the change is allowed to live.
That is the credible foundation for self-evolving software.
The weekend everything found its surface
By the beginning of September, nearly every necessary primitive existed somewhere, but the whole still had to be held in your head.
There were projects and deployments, hosted MCP servers, assistants and agents, machines and sessions, connections and grants, triggers and signals, source repositories and proposals, files and storage, event loops and decision ledgers. There were also live experiments—Oz Markdown, Oz Threads, src, Loop Hub, Loop Conductor, Sentinels, Orbit, Heal, Layers—each proving some behavior the central platform would eventually need.
The September roadmap still imagined a shell later in the month. Then, over the weekend of September 12–14, the pieces snapped into a different relationship.
The critical realization was that OpZero did not need one more dashboard that knew about all the products. It needed a surface in which the things users built could exist together.
Oz OS became that surface.
It is not a cloud desktop costume and it is not a new monolith. It is a persistent, user-composed operating environment made from OpZero capabilities. A person can install or build an app, attach an MCP service, delegate an agent, mount a file, run work, inspect permissions, and return later to the same environment. The browser shell and the AI/MCP interface are two doors into the same home, not two products with drifting state. OpZero remains the provisioning, deployment, identity, and operations substrate. Oz OS is where a person uses what OpZero makes possible.
This finally gives the earlier work a common grammar:
- A workspace is the home.
- Apps are installed capabilities, not isolated URLs.
- Files are stable resources with revisions and grants, not blobs trapped inside one app.
- Tasks and runs outlive a panel or iframe.
- Models are capabilities with budgets and authority, not ambient magic.
- MCP tools and browser interactions act on the same objects under the same grants.
_srcgives installed software identity, provenance, and an upgrade path.- Per-app signals and loops, together with durable tasks and runs, let work continue when no one is staring at it.
The weekend roadmap deliberately looked at the deployed experiments as evidence rather than code to copy. Each one demonstrated a contract: Markdown showed durable editable content, Layers showed binary assets and revision conflicts, Threads showed persistent shared work, the loop projects showed event-driven coordination, and _src showed governed change. Oz OS could extract the stable behavior without dragging every experimental implementation into the core.
That is why this weekend feels like a breakthrough even though the operating system is not finished. It changed the topology of the project. The previous products no longer compete to be the OpZero interface. They become services, apps, and subsystems inside a coherent environment.
The execution was startlingly fast. The contract, home and authority, shell and assistant, files and composition, and tasks, runs, and models were divided into waves and worked in parallel. In roughly seventeen and a half hours, the platform acquired the contracts and components of an environment: shell, home, installs, authority, files, tasks, runs, models, assistant, machine sessions, source identity, continuity links, and a shared activity record. The browser shell reached os.opzero.sh, and the home and authority gate passed.
The honest present is slightly messier, and more encouraging, than a victory lap. We have frozen the core contracts, the deterministic gates pass, and we have declared v1 at that level. Production acceptance is not complete. Real-shell continuity, cross-app file sharing, live task and model behavior, recovery, and bounded self-repair still need to be proven as lived behavior rather than architecture.
The breakthrough is not “Oz OS is done.” The breakthrough is that the work now knows what done means.
The present: from deploying software to owning a world
The public website now says, “Stop subscribing. Start describing.” It promises an application with one browser door and one MCP door, backed by the same data, logic, and grant.
That language is new, but it is not a departure from January.
The January prototype said: deploy from AI agents without human CLI.
The September platform says: describe the software you need, let an agent build and deploy it, and keep it in an environment you own.
The distance between those statements is everything OpZero built in between. “Without human CLI” was never only about removing a terminal command. It meant removing the chain of manual transfers that kept intent from becoming a durable system. The project had to learn deployment, identity, sessions, machines, providers, grants, storage, events, policy, verification, source history, composition, and recovery before “just describe it” could become an honest promise rather than a demo.
Today, OpZero no longer looks like a list of deployed websites; it looks like a working ecology of services, agents, source, and durable operations. Oz, the new home assistant, sits above a landscape that the January version could not yet name.
The platform has crossed from deploying artifacts to hosting an ecosystem of behavior.
Where it is going
The immediate future is not another expansion of nouns. It is continuity.
Oz OS needs to prove that the same user, app, file, task, grant, and event survive movement between the browser and an AI client. The remaining live gates matter because they are exactly where an operating environment becomes real: two independently installed apps sharing a granted file without sharing everything; an agent working on that file under narrower authority; a task continuing after the UI closes; a run failing, recovering, and remaining intelligible; a model call respecting a real budget; a revoked grant actually stopping access.
Once those behaviors are boring, packages and blueprints can make the environment composable. _src can give those packages history, identity, proposals, and safe upgrades. The scattered reference deployments can become a library of patterns rather than a gallery of experiments. The platform can help users evolve what they own without turning every upgrade into a leap of faith.
The longer future is bounded agency.
An event arrives. Deterministic code decides whether it is relevant. A model may interpret it or propose a change. Policy checks identity, scope, budget, and allowed capabilities. The system dispatches an action at most once, measures what happened, records the decision, and repairs or rolls back within explicit bounds. The user can see this through Oz OS, intervene when needed, and trust that closing a browser did not erase the work.
That is where the self-healing, self-evolving, and event-driven architectures converge. Not in an all-powerful agent, but in an environment that lets many limited agents participate in durable loops without confusing intelligence with authority.
Infra’s best future may be outside the central runtime—as a standalone control-plane pattern, an extraction, or simply the ancestor whose ideas have been absorbed. The public labs can continue to hold protocol-level work that deserves a neutral home. Conformance has already become a reusable public project; AuthKit can follow once its identity and security boundaries are cleanly extracted. The monorepo can remain the place where shared product behavior converges without insisting that every useful experiment live there forever.
And Oz OS can be the membrane between them: the place where infrastructure becomes experience.
The thing that did not change
It is reasonable to feel overwhelmed by this history. The project changed abstraction levels several times in a few months. Work that felt central became a package. Work that felt abandoned returned as architecture. Every solved problem exposed the next invisible dependency. The reward for making deployment agent-native was discovering that identity had to be agent-native; then sessions, providers, events, source, policy, and the user environment itself.
But this was not random motion.
OpZero began by asking how an agent could finish the job. It is becoming a place where the job can keep living after the agent finishes.
The repositories tell a story of progressive responsibility. First, make the page exist. Then know who owns it. Keep its credentials safe. Let the agent return. Connect it to the world. Wake it when something happens. Prevent it from acting outside its authority. Preserve the source of what it changed. Measure whether the change helped. Give all of it a home a person can understand.
The January prototype removed the deploy button from the human workflow. Oz OS is trying to remove the boundary between software that was generated for you and software that truly belongs to you.
That is a much larger destination than the first repository could describe. It is also the same direction.
OpZero is the machinery that makes described software real. Oz OS is the place that makes it yours.
The distance between the apps we have and the apps we need used to be a download. Now it is becoming a sentence. Explore OpZero.