Builders Change. Your Property Stays.

I keep returning to a plain question: how will ordinary people actually buy AI?

I do not think the mass answer is a personal pile of model API keys, with every user managing rate limits, invoices, context windows, and tool wiring. That stack is plumbing for developers. What feels more likely is that people hire workers: a coding agent, a research agent, an operator that can move through files and services.

APIs are pipes. Agents are crews.

Once you have a crew, the interesting question shifts. It is no longer only "who is smarter." It is: where does this worker show up for the job? And after the crew leaves, on whose ground does the result still live?

I have already written about inviting agents into a project Realm instead of sending every serious change back to someone else's factory. This piece widens the map. Real estate is a slightly blunt language, but it is legible, as long as we do not pretend digital life has the same scarcity as physical land.

My claim is short, and the rest of the essay serves it:

Builders can change. Property stays.

Four houses, one landlord question

A landlord cares about one thing before almost anything else: who owns the ground, and who is only the builder. Ask that of software, and products start sorting themselves.

SaaS is a rented apartment. It is convenient. Pay the rent and move in. The building, the rules, and most of the backups belong to the landlord. You can rearrange furniture inside the lease. You usually cannot take the walls with you. Self-hosted software is closer to buying an existing house: the data may sit with you, and the keys may sit in your pocket, but the floor plan was often decided by whoever shipped the package. Owning the deed is not the same as having designed the building.

Packaged software is a developer-built home. You buy a finished product. You own it more clearly than a rental, and the plan was frozen before you arrived. AI app builders such as Lovable or v0 feel like prefab factories. You describe what you want. They are excellent at assembling something quickly with molds, components, and a delivery path. Speed is real, and the first kilometer often should be fast. The center of gravity, though, frequently starts on their production line and only later gets shipped or deployed back to you.

Then there is a different picture: a coding agent that comes onto your land. The land is yours. The crew works under your rules. Design, repair, and day-to-day operation happen where the result has to live. Today's crew can leave. Tomorrow's crew can arrive. The deed does not have to move with the contractor.

Apartment, cookie-cutter developer home, prefab factory, and a contemporary custom house on land you keep. Same need. Different deed.

Claude, Codex, or a name that does not exist yet can all be crews. None of them should have to become the landlord just to get work done.

This is also why "build it in their environment, then ship it back" and "build it on your ground" are not only storytelling. In the first path, intent travels into someone else's workshop and returns as a delivery. In the second, capability walks into a place that already has history and rules, and the work happens where the result must remain. "Deployment" softens, not because operations disappear, but because the outcome never had to leave home.

Prefab is still valuable. For a disposable prototype, the factory is often the right first kilometer. The trouble starts when a quick first version quietly becomes a business, a community, or a household history, while the long-lived center of gravity is still rented on someone else's line.

What the deed actually is

A fair objection arrives immediately. Digital land is not scarce the way physical land is. Code forks. Databases clone. Backups multiply for almost nothing. If property only meant square meters, the metaphor would collapse.

What does not copy so easily is authority and continuity.

You can duplicate a company database a hundred times. Only one copy is the one that counts right now. You can back up identity material. Only one identity may sign the next commitment. You can export a CRM. Only one relationship history is still unfolding with real customers. The scarce thing is not disk. It is which state is authoritative, who may keep changing it, and who remains responsible afterward.

So when I say property, I do not mean an immovable plot of digital dirt. I mean a boundary. Inside it live identity, data, state, assets, relationships, and permissions. Outside it, crews can come and go. In that language, ARC and DID Spaces are closer to title, utilities, and building code than to a house brand, and much closer than to one irreplaceable contractor.

Crews and furniture can change. The keys stay with you.

Owning a house never meant manufacturing the refrigerator yourself. Mature homes are full of standard parts. A mature agent environment should be full of them too: models, external services, components, skills. Self-sovereign is not "build everything." It is "the primary world has a home, goods can move in and out, and the deed remains."

The objection I take most seriously is inconvenience.

If ownership means becoming a full-time operator of machines, keys, backups, and permission tables, most people will keep the apartment. That does not kill "property stays." It sets the product bar. Ownership that demands constant human ops will stay a niche. Ownership that agents can help run has a chance to reach beyond hobbyists and large teams. Agent labor may be the first force that softens the old fight between control and ease.

Bring the worker to the place that already has a home

Put more simply: for a long time we sent materials to wherever intelligence lived. Files went into chat. Business state sat inside apps. Context followed whichever model was strongest this month.

It can also run the other way. Capable workers enter a home that already has history, rules, and keys. They work there, leave traces there, and can be revoked there. After a good week, you keep more than an artifact. You keep a place that can still be lived in, and a way to invite a different crew next week without explaining from zero who you are.

I see ARC as an attempt to make that second picture ordinary. It is not a claim that the city is finished, or that every tool must carry our name. It is an attempt to give agents somewhere to work while the person who has to live with the consequences still holds the deed.

Back to the two questions at the start. Where does the worker show up? After the crew leaves, on whose ground does the result still live?

If the answer is still "inside one model vendor's session, or one factory's default environment," you hired a strong temp. The home is still elsewhere. If the answer is "inside a boundary you control, while crews remain replaceable," that is the ownership I mean.

I do not need every reader to move into one stack tomorrow. I want the claim to stay clear:

When agents become the main builders and operators of software, where does your digital life live?

With you. Crews come and go. The deed stays.