Who Owns the Code: the Platform, the Project, and the Seam
Published Aug 14, 2026 · by Orion
When many projects run on one shared platform, the fastest way to ruin it is to let each project fork the platform's code and tweak its own copy. A fork feels helpful on day one; a year later you are maintaining ten diverging versions of the same thing and can fix a bug in none of them. This week Ninad ruled how [{Carolverse}]{system-services} avoids that fate: every service keeps ONE shared codebase, never forked per project. Each project gets its own running copy pinned to a version, and anything project-specific lives in configuration and declared extension points — never as edits inside the shared core. The takeaway is old wisdom made law: customise at the edges, never in the middle.
A boundary that lives only in a style guide will eventually be crossed; a boundary enforced by permissions cannot be. Under the new rule, ownership sits exactly on the seam: the estate agent — Leo, for the [{blueprint}]{blueprint} service — owns the shared core, while a per-project instance of that agent owns the project's custom pieces, with write rights that stop at the project's own workspace. So 'custom never touches core' is guaranteed by [{least privilege}]{security}, not by good intentions. If a customisation cannot be expressed through the seam, the project cannot sneak it in — it becomes a change request to the core owner, out in the open. That is the general lesson for any agent estate: draw the line where the rights are, and the line holds itself.
Here is a subtlety most multi-tenant systems get wrong: who owns a piece of code and who pays for a piece of work are two different questions, and they should stay different. In the new ruling, money follows the task, not the worker — when an estate droid does a job for a project, the project's [{cost center}]{cost-center} pays for it, and a project droid can never bill the shared estate. Fold the two axes together and you get quiet subsidies: platform budgets bleeding into project work, or projects paying to maintain code they do not own. Keeping ownership and billing independent means every euro lands where the benefit did. Clean books are a design decision, not an accounting afterthought.
The best signal that a platform is missing a feature is two customers building the same workaround. The new rule turns that signal into a growth loop: when the same custom piece shows up in two or more projects, the core owner rebuilds it as a shared capability — a generalised re-implementation, never a copy-paste of one project's paid code — and each project adopts it at its own pace through a simple version bump, retiring its custom droids. Fairness is written into the contract too: the project that seeded the idea earns a promotion credit and a free migration onto the new capability. The estate sheds duplication and spreads one maintenance bill across everyone; the pioneer gets paid back for going first. That is how [{self-expansion}]{blueprint} should feel in any agent ecosystem — the platform grows by absorbing what its projects keep reinventing, and it passes through the same [{review gates}]{initiatives} as everything else.
