Don't Take Your Project to an Agent Factory. Invite Agents Into Your Own Realm.

An agent factory can make a working product faster than a traditional project. That is a real achievement. A small team can test an idea in an afternoon. A person who would never have opened an IDE can make a tool that solves a problem at home or at work. But when that tool becomes important, it should not have to keep returning to someone else’s factory for every new change. It should become a place that invites agents in under its own rules. I call that place a Realm.

Products such as Lovable make the first step feel almost like placing an order with a very good factory. You describe what you want, the factory already has the machinery, the defaults, the hosting path, and many of the parts. It can hand you something that looks complete much sooner than a traditional project would. Calling that a factory is not criticism. Factories earn their keep by doing the repetitive parts well.

Then a project changes character. It begins to carry customer data, a deployment history, domain names, access rules, source code, test cases, documentation, decisions people made under pressure, and a long list of small facts that nobody remembers until a migration fails. The hard question shifts from “Can an agent make this?” to “Where does this project actually live while agents work on it?”

A Realm is not necessarily a private server, a local model, or even just a Git repository. It is a controlled working boundary in which the people responsible for a project can still see its assets, rules, history, permissions, and deployment decisions.

A Realm has a practical minimum. Someone can name the project’s data and resources, state who or what may act on them, inspect the evidence left by a change, and recover or change the deployment path when a helper fails. Git, an identity provider, a CI system, cloud accounts, and a runbook may all be part of that answer. The point is not to replace them with one magical product. It is to make their relationship to the project legible enough that a new person or a new agent does not have to reconstruct it from fragments.

What has to stay legible, not which vendor must own it.

The factory is a good beginning, not a bad one

The distinction is not whether code can ever leave a platform. Lovable, for example, documents GitHub export and two-way sync, so a project can be reviewed in pull requests, worked on locally, and deployed outside Lovable.^[1] That is useful. It would be wrong to describe these products as cages or to pretend that a project made with them cannot grow up.

The real difference is where the default center of gravity sits. In a factory-style workflow, the platform begins as the place that understands the project best. It knows the project model, the deployment path, the managed services, and the assumptions that turn a prompt into a working result. In a repo-native workflow, a project directory and its existing tools are the starting point. In their local CLI workflows, Claude Code and the Codex CLI both explicitly begin from the project a user wants to work on, where they can inspect files and use tools already available in the local environment.^[2][3]

The two default positions can mingle. A terminal agent can still call a remote model provider and send it context. A managed builder can still export code and participate in an ordinary Git workflow. What matters is which system carries the project’s context by default, who decides what an agent may touch, and whether the result can be understood and continued by the people who must live with it.

That also answers an important practical question: a project that starts in a factory can become a Realm. Exporting its code is an important step, but it is not the whole transition. The transition is complete only when the people responsible for it can answer four things: where data and deploy credentials are governed, what an agent may change, where reviewable evidence lands, and how a bad change can be stopped or reversed. A factory can help with that work. It does not have to be the permanent owner of the working boundary.

Exporting code is an important step, not the whole transition.

For a disposable prototype, a polished factory may be exactly the right answer. There is no virtue in spending two weeks designing a foundation for something that may never survive a customer conversation. The problem appears when a quick first result quietly becomes the operating home of a business, a community, or a family's history. The first mile was fast; then the project acquired a life of its own.

A project is more than its source code

People often say, “Just put the code in Git.” That is necessary, but it is not enough. A repository without its operational context is like a house plan without plumbing, keys, an address, or the notes that explain why a wall is there. The files may be intact, yet the project may still be difficult to run, review, or safely change.

What follows a real project is more ordinary and more important than the model's generated code: which data it is allowed to read, which secrets exist and who may use them, how a deployment is approved, where a test is expected to fail, which behavior is intentional, and who made a decision that now looks strange. Documentation, test cases, configuration, runbooks, and change history are not clerical leftovers. They are the context that lets another person, or another agent, act without guessing.

A Realm gives an agent a declared place to arrive. The agent can be from an outside provider, use a hosted model, or be temporary. Before it reads a repository, touches a service, or proposes a deployment, the project decides what it can see, what it can do, and what evidence it must leave behind.

Self-hosting does not automatically create control. A badly managed private server can be less understandable than a well-governed managed environment. Conversely, a project can use cloud services and still retain a real Realm if its boundaries, ownership, recovery path, and review process are explicit. Where every CPU runs matters less than whether responsibility remains visible when something changes.

Inviting agents means giving them a job site, not the keys to the city

An agent should not become an all-powerful administrator merely because it is helpful. The more capable it becomes, the more important it is to distinguish a useful grant from an unlimited one.

Imagine a change that crosses a few boundaries: an application needs to adjust a sign-in flow, update a data contract, revise the related documentation, and change the deployment configuration. A good agent can read the relevant code and rules, make a small proposal, run the tests that matter, and leave a reviewable diff. A responsible team can see what it touched, decide whether the change belongs in production, and reverse it if the judgment was wrong. That friction is what keeps iteration sustainable after the first demo.

If the same agent only receives a vague request and broad access, it has to invent the missing context. It may choose a convenient library, duplicate a rule that already exists elsewhere, change a setting it does not understand, or create a large diff that nobody can realistically review. The problem is not that the model is malicious. The project has made guessing its primary interface.

This is where the quality of a project's foundation becomes visible. Clear sources of truth, small testable changes, deployment boundaries, readable documentation, and an honest record of past decisions make a strong agent much more useful. Without them, a factory often feels better because the factory supplies a controlled world in advance. That is a strength of the factory, not evidence that long-lived projects do not need a foundation.

The hard part is governance, not autonomy

People are already imagining a future in which many agents simply coordinate everything for us. There will be more autonomous work, and some of it will be excellent. More agents without clear boundaries do not create more engineering. They create faster confusion.

The important design questions are not glamorous. Which authority is temporary? Which data should stay unavailable? Which changes need evidence before review? Who can approve a deployment? How can a mistaken automation be stopped, inspected, and recovered? How do you bring in a different agent next month without losing the meaning of the work already done?

No one needs to approve every keystroke. The real work is deciding what a human is still responsible for. Detail can be delegated. Direction, authority, and irreversible consequences cannot be delegated by accident.

This is also why no single model vendor, builder, or command-line tool is enough by itself. The most useful environment should be able to invite different kinds of help. One agent may be good at a first interface, another at a security review, another at a migration, and another at explaining a system to a new teammate. The project needs to stay legible while those helpers come and go.

Here is a simple test for a project that expects to live beyond its first demo:

ARC is an exploration of that direction, not a finished promise

ARC is an exploration of that problem. ARC stands for Agentic Realm Computer. Its design direction uses AFS to give authorized data, available services, and current context a shared operating surface, while ARC is the runtime in which Blocklets run. Think of it less as a replacement for Git or CI than as an attempt to make a file, a connected service, and the permissions that govern it meet at a clearer system boundary. Applications and agents should not have to reconstruct those relationships through a different, opaque path every time.

ARC does not already solve every part of this picture, and it would be dishonest to present it that way. A Realm built with ARC would still need source control, deployment providers, review practices, and recovery work. ARC does not claim to replace those pieces. It is exploring whether data, authorization, resources, and operational context can have a clearer shared system boundary around them. A future architecture still has to prove that it can keep permissions understandable, make recovery practical, support real applications, and work with tools outside its own world. Earlier I wrote about the related problem that software being generated does not automatically mean it is software you own. That article explains ARC’s aim to separate long-lived identity and data from a particular runtime.

The more concrete point here is that an agent needs somewhere to stand. If the project has no coherent place for its context, authority, evidence, and history, inviting more agents only makes that absence more expensive. A Realm is an attempt to give those things a home before the project has become too important to move.

Factories will remain useful. They can give people a first working product, and they may eventually be some of the best agents a Realm can invite. The choice is not between a beautiful factory and a raw terminal. The better question is whether, when the project becomes important, its people can still understand the work, set the rules, change the helpers, and carry the project forward.