3. To Each Their Own System

If frozen software stops being the answer, something takes its place, and it does not yet have a name everyone uses. It does not resemble custom development, which dies too. The difference is not the size of the team or the length of the project. It is what triggers the change. In custom development someone specifies the business, someone programs it and the system sits still until the next project, however cheap that project may be and even if the one programming is an agent. In one’s own system nobody specifies in advance: the work arrives, the agent attends to it, and what repeats, the agent crystallizes. I describe it with what I see.

What does an organization that builds its own system look like?

Like a template that comes to life. My friend, the one with the wealth-management system, does not sell each family a product. He installs a starting point: a system that already records the assets, the lease contracts, the receivables and the financial statements of the family’s companies, and that already generates the reports and the alerts that whoever manages a family’s wealth needs. From the day of installation, that system begins to drift away from the template. Its owner asks artificial intelligence for things and artificial intelligence changes it: a new view, a cross between the contract and the account statement, an alert nobody had thought of. After a year, two families that started from the same template have two different systems, each with its own name. That is only the first step: the agent changes the system when asked to. What comes after, and which I tell below, is that the agent learns the work and changes it itself.

With bought software, the vendor decided what could be done and the customer adapted. With custom development the customer decided, but once, in the specification, and every change was a project. With one’s own system the customer decides while the work happens: what used to be a change request, with its quote and its wait, is now a conversation.

It happens at scales that look nothing like a family, too. I know a mid-sized company that runs on a commercial ERP and is thinking of replacing it. The usual question would have been which of the competing ERPs suits it best. The one I am putting to it is whether it would not be better off building its own, on its own data, and evolving it with agents. A telecommunications operator, like the one in chapter 7, can ask the same question about the system that bills millions of customers.

The wealth-management system and the ERP company, which are two different cases, are still at that first step, where the agent changes the system when asked to. The next step, where nobody has to ask, is the one chapter 7 cannot yet show measured.

What do the agents do in that system?

Two jobs that should not be confused.

The first is building and changing the system. A development team used to do it; now, more and more, an agent does it, guided by someone who knows what the business needs.

That an agent does it admits two readings, and only one changes things. I give them the names AgencyDomains gives to the two sides of the Nadella Line, because it is the same distinction, carried from the interface to the system underneath.¹

The first is the agentic reading. The agent is a faster programmer: it writes the code a person used to write, and the organization still needs a development team to direct it, review it and maintain it. What comes out of the agent is an application, and the application persists, as the tools of old persist in the agentic world with an agent inside.

The second is the agentive reading, and it is this book’s. Nobody programs the system in advance: the organization decides what work has to exist, and the agent shapes it. The agent attends to the work by reasoning, and what repeats it crystallizes into pieces of its own that resolve it without thinking it through again, like the expert who stops deliberating over what they already know how to do.² AgencyDomains describes those mechanics: today the agent starts from an existing piece and configures it for its case. The canon anticipates that it may co-write it and, at the limit, generate it whole, but it clarifies that generating more is not progress: the mature agent reuses what it has already crystallized and spends its capacity to generate on what is new.³ What the organization contributes in the agentive reading is not code. It is its knowledge: the business expert teaches the agent how the work is done, with a delivery practice accompanying them, and validates that it learned, first in testing and then in real operation.⁴

That building and changing the system has become cheap, or unnecessary, is the underlying reason for everything this book tells.

The second job is operating the system: handling a query, tracking down an order that fell out, preparing a reconciliation, proposing a correction. The agent does it by working on top of the business rules, without replacing them. What is deterministic, like calculating a tax or applying a rate, stays in defined flows that always do the same thing, and the agent takes care of what nobody foresaw. Put in one sentence, which chapter 7 backs with what telecommunications operators publish: the agent orchestrates the flows, it does not replace them.

This distinction matters more than it seems. Whoever imagines an agentive system as a language model that decides everything, freely, is right to be afraid of it. A well-built system does not work that way.

What does it cost for the agent to attend to the work?

If the agent attends to the work by reasoning, and reasoning with a frontier model is expensive, one’s own system could turn out more expensive than the software it replaces. The answer is that not all work asks for the same reasoning, and AgencyDomains orders it in three rungs.⁵

At the bottom is what repeats identically. The agent crystallizes it into Botlets, code that executes without consulting any model and costs what any program costs. At the top is full reasoning, which AgencyDomains calls full Cognition, reserved for what is genuinely new.

In the middle is what repeats in its form but asks for judgment in every case: classifying a complaint, deciding whether an alert deserves to wake someone up, reading an invoice that had never been seen before. No rule written in advance resolves it well, and it does not deserve the most expensive model either. For that the canon has a second species of piece, the Agentlet: the Botlet’s sibling, with a declared charter and a model sized to the task, not the largest one, with a budget per execution. Its image is the triage nurse in an emergency room: she does not resolve from memory, because every patient is different, but neither does she call the chief of medicine for each one. When she is not sure, she escalates.

Agentlets are, like Botlets, the agent’s: it shapes them and maintains them, with the same caveat I made for Botlets. And the mature system pushes work down the ladder: what started out asking for judgment and turns out to have a core that always resolves the same way, the agent crystallizes into a Botlet. What is genuinely interpretive does not go down: it stays on the middle rung, because by nature it does not mature into code. That the Agentlet knows when it is not sure is, according to the canon itself, an open problem; in the meantime it is compensated with prudent thresholds, which escalate too much rather than too little. And since all its inference passes through the agent’s platform, every decision is measured, with its budget and its trace, under the same control layers of chapter 6. It decides with a probability, not with an explanation: for what must be justifiable, escalating is a design decision, not a failure.

The middle rung could get much cheaper. There is already a model, from a single vendor, of a class that does not generate text: it receives the case and a set of questions with closed-option answers, such as yes or no, or one of several categories, and returns decisions with a probability attached to each, in fractions of a second and for a fraction of the cost of a frontier model, according to its vendor.⁶ The probability is what would make it useful here, if it is honest, that is, if when it says “90%” it is right nine times out of ten: above a threshold, the Agentlet decides; below it, it escalates. If those promises withstand measurement, the cost of having the agent attend to the work stops being the objection and becomes the argument. I have not measured it yet.

Time changes with the rung too. A Botlet answers in the time a program takes. A decision model, according to its vendor, in fractions of a second, but only when it is sure: when it doubts, it escalates, and the answer arrives at the pace of full reasoning, which is much slower. For the work that happens while the customer waits, like approving an order, classifying a complaint or replying on a channel, that difference decides what the agent can resolve on the spot and what it has to leave for later. Rating a call is not on that list: it is deterministic, and a defined flow resolves it.

Who the business depends on changes as well. Frontier models live in enormous infrastructures, belonging to a few vendors in the world. A mature Botlet depends on none: it is code, and it runs wherever everything else runs. If a young one fails, the work returns to the agent, which does it with the frontier model, and that is why, according to AgencyDomains, only the mature Botlet operates offline.⁷ An Agentlet never reaches that point: its judgment is statistical and, when it doubts, it escalates to full reasoning. It could run in the company’s data center or on site, like a branch or a cell tower, if there is a sized model that reaches the quality the charter demands; the canon requires declaring it, but presents it as an open frontier, not as something settled. The more work goes down the ladder, the less the business depends on a distant third party being available, still charging the same or still existing. It does not stop depending altogether: what is new, and everything that fails, still goes up to the frontier model. And the decision model I spoke of is offered today only as a service of whoever makes it, so that, as long as that lasts, the middle rung trades one dependency for another. Independence comes from a well-built ladder, not from it.

Why now and not before?

Because the three things that prevented it fell at once. Writing software was expensive and changing it was slow; both stopped being so. And the work nobody specified could not be automated, because software only does what someone wrote in advance.

There is a fourth condition, which makes all this possible at scale: standards. A company that builds its own system does not have to invent its data model or its interfaces, because mature industries have already written them. In telecommunications, TM Forum has for years published a reference architecture, a common information model and a set of open interfaces anyone can use. It is not only a telecommunications thing. In banking, BIAN publishes a map of a bank’s services, a model of its business objects and open interfaces, and financial messages converge on ISO 20022. In insurance, ACORD maintains an industry information model: the policy, the product, the parties, the claim. In health, HL7 FHIR defines the clinical resources and how they are exchanged. In electricity, the IEC’s common information model describes the grid and the utility, and in airlines, IATA’s ONE Order gathers in a single order what used to be several booking records.⁸ Built on standards, a component can be swapped without redoing the rest, and that is what separates one’s own system from a dead end. Today that promise is held up by two standards, the information model and the open interfaces, which the industry adopted years ago. The interchangeable components TM Forum also promises are the least mature part of its architecture: in March 2025, 58% of operators and half of vendors did not expect to be able to switch vendors component by component within five years, and another 21% of operators and 35% of vendors said it could not be known.⁹

So nobody buys software again?

Software will still be bought. What changes is what is bought and why: less the application that fixes the processes and more what is better not built at home nor left for the agent to learn on its own. The rest of this book is about what that is, the core of truth, and it begins with what is lost when one stops buying.