The File Stores No Customers

Twenty-Eight Lines

The file is twenty-eight lines of Markdown in six short sections. It says what a small CRM has to do today: add a customer, make a call, record the outcome, schedule the next action. It says what to do tomorrow, when a colleague joins. It says what must never happen, which is losing an original value in a disputed merge. And it says how anyone will know the thing works.

# Capability: working with customers

## Purpose
Let the user add a customer today, make a call, record the outcome,
and schedule the next action.

## Data
Customer, contact, call note, next action.
Keep the provenance of every change and the history of decisions.

## Growth
Start with one user working locally.
When a colleague joins, provide shared work and exchange of changes.
Add further capabilities only when a real need appears.

## Reconciliation
Keep each participant's notes independently.
Never discard original values in a disputed merge.
Route ambiguous changes to commitments to an authorized person.

## Autonomy
Allowed: create views, write and test functions within granted authority.
Extending access or making irreversible changes requires a separate decision.

## Acceptance
Records survive restarts and application updates.
Re-delivering a change never duplicates an operation.
After exchange, participants share one state, or see an explicit open conflict.

There is no schema in it, no screen, no API, no choice of database. More to the point, there is no CRM in it. The file stores no customers and executes no operations. It is a declaration of what must be possible, and an agentic environment reads it, builds the implementation, and keeps that implementation working as the need changes.

That is the claim of a new paper, Capability-as-Infrastructure: Software on Demand. The application stops being the thing that is kept. It becomes something that is produced.

Two Hundred Applications

Picture an organisation that runs two hundred applications. Each one has its own interface, holds its own slice of the organisation's information, and implements its own fixed operations. The work happens in between: a person moves a customer from one program to another and reconciles what each of them believes to be true.

Every new need takes the same road. It is framed as a product, then specified, built or bought, released, adopted, and eventually extended or replaced. The application is the unit of design, the unit of delivery and, most importantly, the unit of continuity. The data lives inside it. When the application is replaced, the data has to be migrated out, and much of what it meant, who changed what and why, does not survive the move.

Agents have made the build step fast. An agent can produce a working application in an afternoon. But a faster build is still a build of a product, with its own boundary and its own release cycle. Agents around an application make the old unit cheaper. They do not ask whether it was the right unit.

A Layer That Carries Nothing

A tree has a better answer to the same problem. Its growth does not happen in the wood. It happens in a thin ring of tissue just under the bark, the vascular cambium, a cylinder of unspecialised cells that produces new wood inwards and new bark outwards, year after year. The detail that matters is the one botany states almost in passing: unlike the wood and the bark it makes, the cambium itself does not transport water, minerals or food. The layer that keeps the tree growing carries nothing. It produces the tissue that does.

The twenty-eight lines are that layer. They carry no customers. They produce the tables, screens and sync functions that do, and they stay in place while those are replaced. A CRM is the first year's growth. Procurement, planning or reporting can come next, each starting as another declaration and drawing on the same history, while the layer that produced them persists.

What Has to Survive

If applications can be thrown away, something else has to be kept with real care. The paper calls it the continuity record: the data, where it came from, its history, the decisions taken about it, and the authority under which anything acts. Keeping the bytes is not enough. The record has to keep the meaning.

It does that by keeping apart three states that most systems collapse into one. There is the observation, the email or note exactly as it arrived. There is the interpretation, what an agent concluded it means. And there is the accepted working state. An agent that misreads an email can be corrected without the original being lost, because the original was never overwritten by the reading.

The same discipline applies between agents. When two of them agree on a merge, that agreement means nothing until it becomes something checkable: a recorded version, an accepted change, an acknowledged delivery, or a conflict left visibly open. Agreement in a conversation is not reconciled data.

Who Does the Specialist's Work

The boldest sentence in the paper is about people. If the environment supplies the competence a piece of work needs, the user does not need a separate specialist for it. Designing the sync protocol, choosing the schema, writing the migration: the need for that skill remains, but there is no rule that it must come from a person.

Stated like that, the sentence is close to a tautology. If something supplies the skill, nobody else has to. The paper says so, and moves the weight onto what can be tested. Its second hypothesis is that, given a changed declaration, an environment can build a new capability, verify it, and put it into service with the existing data intact, with no specialist designing the change. Working synchronisation does not prove that. Only the separate experiment does.

The human does not disappear in this picture. The human moves. The user stays the owner of the data and the source of intent and authority. Widening access, accepting an obligation or making an irreversible change still waits for a person. Everything inside the authority already granted proceeds without asking again.

A Fourth Thing to Compile

The paper is the fourth in a line. Methodology-as-Infrastructure compiled how to think. Intent-as-Infrastructure compiled what to reach into, with the model as the compiler. Governance-as-Infrastructure compiled what must be true, before anything runs, and called itself the end of that road, since nothing comes earlier than deciding what correct means.

Capability-as-Infrastructure does not try to go further upstream. It turns in another direction. The first three papers each describe a run. This one describes a lifetime: what has to survive while the software is rebuilt around it. Each capability declaration carries its own constraints and limits on autonomy, which is Governance-as-Infrastructure applied one capability at a time.

It also stands on work from outside this series. The shape of its architecture comes from local-first software, the 2019 argument by Martin Kleppmann and colleagues that people should own their data and work offline, with the cloud as a participant rather than the custodian. The difference is who builds the synchronisation: here, the sync protocol is itself something the agents design, version and migrate. The goal is shared with Ink & Switch's essay on malleable software, which asks for tools people can reshape. CaI gets there by having the environment produce the tool from what the person intends.

It is a concept paper, and it says so. It reports no results. It states two hypotheses, continuity under replacement and autonomous capability growth, and a test for each, built on the same small CRM growing one real need at a time.

The First Ring

Twenty-eight lines describe a CRM that does not exist yet. On the first day it becomes a customer record, a call note and a next action, stored on one machine. On the second it becomes two machines that agree. Later it may become something no one wrote down at the start, because a need appeared and the layer that produces software was still there to meet it.

The general shape is older than software. What lasts in a living system is often not the visible structure but the thin layer that keeps producing it. A tree is not any one year's wood. It is the ring of cells that will make next year's. The file stores no customers, and that is exactly why it can keep making the place where they are stored.

Related