Author: Rajesh Jain

How machine-generated software changes what software is, how it ages, what it may be trusted to do, and who still needs to sell it

This series has argued four consequences of a single change. The Software Foundry named the change: AI alters the production function of software. The App-Stack Tax traced the waste that change exposes on the buyer’s bill. The Foundry Price named the number that follows. Inside the Foundry walked through the production system that makes the number sustainable. Each of those essays took the change as given and followed it somewhere.

This essay goes underneath them and asks what the change itself is — because the answer is larger than a cheaper way to make the same software.

The claim of this essay: AI will not merely help humans write software faster. It removes code from the centre of what humans make — and once that happens, software changes what it is, how it ages, what it may be trusted to do, and why a company should buy it rather than build it.

1

The Last Generation of Handwritten Software

For seventy years, software has been made in a workshop. The workshop grew spectacularly more powerful. Machine code gave way to higher-level languages. Memory management became automatic. Libraries removed the need to rebuild common functions. Version control made large collaboration possible. Open source let each generation begin higher than the last, and the cloud removed the burden of shipping. Yet the central act stayed recognisable: a person understands a need, translates it into instructions a machine will execute, and hands the result to other people who will maintain it.

The model remained artisanal even inside the largest software companies. A modern engineering organisation may employ thousands of people and automate its testing, deployment and monitoring, and its output still rests on human beings making millions of implementation decisions. Software scaled by applying more engineers, better abstractions and larger organisations to the same act. The craft became industrial in size without becoming industrial in method — which is why the economics never moved. The craftsman acquired better tools and remained the bottleneck, and everything the industry charged was built on top of the bottleneck.

This is a familiar shape, and the industry that lived through it before knows how the story ends. The first machines in the textile trade were sold to weavers as better tools: a faster shuttle, a mechanical spinner, a device that let one artisan do the work of three. For a while that description was accurate. Then it broke — because the significant change was never that a weaver became faster. Production left the workshop. The unit of output changed, the organisation of labour changed, the consistency of output changed, the economics of cloth changed, and the number of people who could afford to wear it changed. Skill moved out of the individual hand and into machines, processes, gauges and standards. The tool story was true and small. The system story was the one that mattered.

AI coding is currently being told as a tool story. Engineers finish features faster. Boilerplate disappears. A small team does the work of a larger one. A backlog shrinks. All of it is likely, and all of it stays in the artisan register.

The consequence that matters is not that programmers will type less. It is that code will stop being the primary thing humans produce.

The profession will be redrawn rather than removed — engineering did not disappear when factories arrived. But its centre of gravity moves. Fewer people will spend their days translating already-understood requirements into routine implementation. More will define architectures, resolve the ambiguous domain question nobody wrote down, design the evaluations that decide what correctness means, investigate failures, govern what the system is allowed to do, and improve the production machinery itself. The craft is not deleted. It is embodied at a higher level and multiplied through machinery — which is what happened to every craft that industrialised, and it was never the smaller job.

Three shifts follow, and this essay is organised around them. Software moves from handwritten to generated. It moves from maintained to regenerated. And — the shift most often announced and least often stated correctly — it moves from deterministic to agentic. Each changes something different: the first changes how software is made, the second how it ages, the third what it is permitted to do. Taken together, they change what a software company is for.

Figure 1. Three shifts, and what each one changes.

Key points

• For seventy years the production model stayed artisanal. The craft became industrial in size without becoming industrial in method.
• The Industrial Revolution’s tool story was true and small. The system story was the one that mattered.
• Three shifts follow: handwritten to generated, maintained to regenerated, deterministic to agentic.

2

Code Becomes an Artefact

Start with what a software product has been. A codebase is the accumulated record of every decision a company ever made about how its product behaves: business rules, edge cases, the fix from the incident three years ago, the workaround for a customer who has since left. Some of that is written down elsewhere — in requirements documents, architecture diagrams, tests. But when those disagree with the implementation, the implementation wins. For most software companies the code is not the record of the truth; it is the truth, and reading it is the only reliable way to find out what the product does. This is why software is expensive to change, why the people who wrote it are hard to replace, and why the sentence “we cannot touch that module” appears in every engineering organisation past a certain age.

Machine generation inverts the arrangement. The chain that ran from human intent to human-written code to running software now runs from human intent to a specification, from specification to a machine-generated implementation, and from implementation to continuous validation against the specification that produced it. The implementation remains necessary. It stops being the primary human-authored asset.

Figure 2. The source of truth moves — and regeneration returns to it, not to the code.

The word specification needs rescuing here, because a generation of requirements documents that nobody read and nothing enforced has degraded it. A prompt requests a result. A specification establishes what must remain true. It states the job to be done, the entities and data definitions, the rules of the domain and where they came from, the actions permitted and the actions prohibited under any circumstances, the evidence required before an action, the expected behaviour in ordinary cases, the treatment of exceptions, the conditions for escalation and the path for rollback. And it contains acceptance tests precise enough for another machine to judge whether the generated implementation satisfies the intent. It is closer to a contract than to a brief.

This changes who can participate in making software. The expert on returns, lending, logistics, payroll or clinical operations need not become a programmer to shape the system. Their valuable knowledge was never the syntax of a language. It is the operating reality: which rule applies, which exception matters, which action is irreversible, which failure is unacceptable. The specification is where that judgement becomes executable.

Code tells a machine how the system was implemented. A specification tells the organisation what must remain true.

From that follows the operating discipline of the whole era, and it fits in one sentence: humans edit the specification; machines regenerate the implementation.

The sentence sounds procedural. It is not. It carries a consequence with teeth, and any organisation adopting generated software will meet that consequence the hard way if it does not adopt the rule deliberately. An emergency patch that is not translated back into the specification is silently deleted by the next regeneration. Somebody fixes something at two in the morning, directly in the implementation, because a customer is down and the fix is obvious. The fix works. Weeks later, a regeneration runs for an unrelated reason and the fix is gone — because it was never part of what the system had been told must remain true. This is not a defect in the machinery. It is the discipline that prevents a new kind of legacy estate: vast quantities of machine-written code whose governing decisions nobody can reconstruct. But it only works as law, and it is brutal as a surprise.

Code does not become irrelevant in this arrangement. It becomes inspectable evidence of an implementation at a moment in time. Engineers will still read it when performance, security or an unusual failure demands it. What moves upstream is the enduring asset.

Nor does this imply one monolithic document governing everything. Specifications will themselves be layered — organisational policy, vertical rules, product contracts, interface definitions, component guarantees, tests — and the relationships between the layers will matter as much as their contents. The central difficulty of this era will be keeping those layers explicit enough for machines to compose and legible enough for people to govern. That is a hard problem and it is not solved. It is, however, a better problem than the one it replaces.

Key points

• The codebase used to be the source of truth. The specification becomes it.
• A prompt requests a result. A specification establishes what must remain true.
• Humans edit the specification; machines regenerate the implementation.
• An emergency patch not translated back into the specification is deleted by the next regeneration.
• Specifications will be layered, and keeping the layers both composable and governable is the era’s central difficulty.

3

Software That Does Not Have to Grow Old

Software ages in a way physical products do not. The program may still do exactly what it was written to do while the environment around it keeps moving. A framework loses support. An interface changes its authentication rules on somebody else’s schedule. A library develops a vulnerability. A regulator changes what may be stored or communicated. A browser alters a security policy. The engineer who understood the pricing module leaves, a temporary patch becomes permanent, and an undocumented exception hardens into a dependency nobody dares remove.

Some of that accumulation is poor work. Most of it is the price of time. Every implementation records assumptions about the world at the moment it was written, and as those assumptions decay the organisation layers repairs on top of them. Eventually, changing a small part of the system requires understanding a history that no document fully contains. This is why software companies spend a rising share of their engineering capacity standing still — and why they eventually price that capacity into the invoice.

Specification-driven production offers a different relationship with time. When a shared connector, policy, model or regulatory rule changes, the production system updates the relevant specification or foundation, identifies the products affected, regenerates their implementations, reruns the required evaluations and deploys the validated versions. Traditional software organisations maintain applications one at a time. A specification-driven system maintains the truths from which applications are rebuilt. For the customer, that resolves into a promise the software industry has never been able to make:

Software that does not have to grow old.

The gain is not only speed. It is consistency: a security correction to identity, a repaired connector or a new jurisdictional rule propagates across every capability that depends on it, and each one inherits the same correction, the same test and the same evidence that it was applied. In the handwritten world that same change was a separate project in every application, done to a different standard in each, with the evidence assembled afterwards by hand.

It also changes what a release is. In the handwritten era a release bundled months of implementation work into a version the customer had to accept, and version numbers carried real anxiety. In a regenerated system, change becomes smaller, more continuous and more targeted — a connector rebuilt, a policy updated, a control strengthened, only the affected capabilities revalidated. The release stops being a shipment of accumulated code and becomes a certified statement that the current implementation still satisfies the governing truths.

Now the honesty condition, which belongs in the middle of this argument rather than a footnote, because without it the promise is marketing.

The new technical debt is specification debt. AI does not abolish ambiguity; it moves fragility upstream. The failures of this era will not come from ageing implementation code. They will come from incomplete intent, missing edge cases, policies that contradict each other in a situation nobody imagined, acceptance tests that pass without proving anything, authority boundaries never written down, and domain assumptions that were true when captured and are not true now.

A poor specification can be worse than poor handwritten code, because a human team introduces inconsistency slowly and a production system can spread a flawed rule across every product in minutes. That is not a smaller problem than technical debt. In one respect it is a larger one, because the fault is now systematic rather than local — and it demands far stronger discipline about provenance, review, testing and ownership of the specification itself.

Figure 3. Fragility does not disappear. It moves upstream — and changes character.

So the recompile property is not a free gift of the technology. It is the reward for specification discipline. Software does not stay young because a machine can rewrite it. It stays current because the organisation has kept a precise, tested account of what must remain true while letting the implementation change underneath it.

Key points

• Traditional software maintains applications one at a time. Specification-driven systems maintain the truths from which applications are rebuilt.
• The gain is consistency as much as speed: one correction, one test, one piece of evidence, everywhere it applies.
• A release becomes a certified statement that the implementation still satisfies the governing truths.
• The honesty condition: implementation debt gives way to specification debt, and a poor specification propagates faster than a human team could.

4

From Deterministic Applications to Agentic Actors

The third shift is the one most discussed and most often mis-stated — and the mis-statement matters, because it leads organisations to build the wrong thing.

Traditional software is predetermined, and the word is precise. A human anticipated the situations the software would meet, encoded a response to each, and shipped the result. Given this input, produce that output. If this happens, run that. The application waits; a person operates it; a situation outside the designed path either fails or is handed back to a human. The intelligence in a conventional application is entirely the intelligence its designers had in advance — which is why every enterprise implementation contains a discovery phase whose purpose is to find out, before go-live, everything that might ever happen.

Agentic software works from the other end. It receives a goal, observes the situation as it is, chooses among available actions and adapts as conditions change. It can interpret intent rather than only accept structured input; decide which workflow applies; construct a path when no predefined path fits; use several systems to do it; ask when the request is ambiguous; monitor the result and change course; and stop when its confidence or its authority runs out. The governing instruction is no longer if this, then that. It is: given this goal, this context and these boundaries, decide what to do next. The software stops being a tool in the user’s hand and becomes a delegated actor inside the organisation.

This is a deeper change than the one usually reported. The popular version says the interface moves from clicks to chat, and the popular version is a distraction. Chat may be convenient for expressing an ambiguous goal; a dashboard may be better for inspection; a form may remain the safest way to approve a precise transaction. Those are design decisions taken moment by moment. Software is not moving from being clicked to being talked to. It is moving from being operated to being authorised.

Delegation does not arrive in a single leap. It forms a ladder — and it is worth stating as a ladder, because no product arrives at the top of it and none should be sold as though it had.

Level	What the software is trusted to do
Observe	Read the situation and explain what is happening
Recommend	Propose an action, and leave it there
Prepare	Construct the action in full, and wait
Execute	Act, after explicit approval
Operate	Act without asking, inside agreed policies
Own a goal	Choose its own actions towards an outcome, and escalate the exceptions

Table 1. The authority ladder. Interface is a design decision at every rung; authority is a commercial one.

Two products of similar intelligence may therefore have very different value: one can advise, and the other has earned permission to act.

Which is why authority is earned, not asserted. A system does not become trustworthy because the model behind it is capable, or because it sounds confident. It becomes trustworthy through evidence that its actions were right before, permissions that constrain what it can reach, an audit record that reconstructs why it did what it did, and the ability to reverse an action that should not have happened. A system trusted to prepare a refund, approve a supplier, send a communication or alter a price must be able to show what it knew, which policy applied, which boundary it respected and how the action can be undone. Capability establishes what a system could do. Only that apparatus establishes what it should be allowed to do — and the second is what the buyer is paying for.

There is a second consequence, and it is the reason specification debt is not an abstract worry. Delegation converts specification gaps into consequences. An unclear suppression rule sends the message. An incomplete permission model exposes the data. A missing escalation path approves the exception. When software displayed and waited, a missing edge case produced a wrong screen and somebody caught it before anything happened in the world. A deterministic system fails visibly and locally. An agentic system governed by a weak specification fails confidently and at scale.

So the quality question for future software is not only whether the agent is intelligent. It is whether the institution around it has defined authority precisely enough to let intelligence act safely.

Which is also why the three shifts are not independent. Generated software makes agentic behaviour practical, because workflows no longer have to be anticipated and encoded in advance. Agentic behaviour then makes specification discipline mandatory, because the stated boundaries are the only thing standing between a capable system and an action nobody authorised. And that gives the specification a second job it never had:

In the old world, code defined what an application could do. In the new world, the specification defines both what the system should become and what it is permitted to do.

Key points

• Deterministic software encodes responses a human anticipated. Agentic software pursues a goal within boundaries.
• The shift is not from clicked to talked to. It is from operated to authorised.
• Two products of similar intelligence differ in value: one advises, the other has earned permission to act.
• Delegation converts specification gaps into consequences.

5

The Two Planes

Everything above invites a conclusion that would be expensive to act on: that software is moving from deterministic to agentic, and that the destination is a system reasoning its way through every task. That architecture would be costly, unpredictable and hard to audit. Correcting the conclusion is the difference between something that can be afforded and something that cannot.

The accurate statement has two halves. Decision-making becomes agentic. Execution stays deterministic — permanently, and by design.

The agentic control plane does the work that benefits from judgement: interpreting what is wanted, configuring the workflow, setting the policy, resolving ambiguity, diagnosing an exception, deciding that something has changed and the approach should change with it. The deterministic execution plane does the work that benefits from being identical every time: processing events, enforcing permissions, checking eligibility, transforming data, calling stable interfaces, running to schedule, writing the audit record.

The agent decides what should happen. The deterministic system ensures it happens correctly, repeatably and cheaply.

Use intelligence to decide what should run. Do not pay for intelligence every time it runs.

An agent might read a new returns policy, translate it into a workflow, and identify the exceptional cases needing human review. Once that is approved, the ordinary path should run as deterministic software until new information gives the control plane a reason to reconsider it.

Two independent arguments arrive at this same architecture, which is usually a sign that it is right.

The first is economic. Inference is not free, and does not become free merely because model prices fall. It is a cost that scales with usage rather than with customers — the opposite of the shape the software industry is built on. A product that reasons afresh on every execution has a cost line that grows precisely where its revenue does not, and the gross margins reported by AI-native products so far sit well below the seventy-five to eighty-five per cent that software companies organised themselves around. Compiling repeated work into deterministic execution is therefore not an economy measure bolted on to protect margin. It is the reason an affordable agentic product can exist at all.

The second argument is about trust, and it is the more important of the two. A system that reasons its way to each individual action cannot fully explain why it acted, because the reasoning was assembled in the moment and is not reliably reproducible. A payment calculation, a consent check or an eligibility rule should not vary because a model sampled a different chain of reasoning. A system that reasons about configuration and then executes deterministically can be explained completely: this is the policy, this is when it was set, this is who approved it, this is the rule that fired, this is what it did, and this is how to undo it. An agentic system that cannot be reconstructed cannot be given authority — which returns the argument to the ladder. The two planes are not merely how agentic software becomes affordable. They are how it becomes accountable enough to be trusted with anything that matters.

The boundary between the planes is itself a design decision, and the most interesting one in the architecture. A novel exception arrives in the control plane and is handled there, with close human review, because nobody has seen it before. Once the organisation understands the pattern, it can be written as policy, tested, and compiled downwards into the execution plane. The system therefore learns in two directions: the agent gets better at handling novelty, and the deterministic machinery absorbs whatever has stopped being novel. Intelligence is spent where uncertainty remains, and withdrawn from where repetition has already removed it.

Figure 4. Agentic control over deterministic execution — and the boundary that moves as the organisation learns.

Agentic where judgement is valuable. Deterministic where reliability is essential.

Key points

• The shift is not deterministic to agentic. It is agentic control over deterministic execution.
• Use intelligence to decide what should run; do not pay for intelligence every time it runs.
• The economic argument: inference scales with usage, not with customers.
• The trust argument: a system that cannot be reconstructed cannot be given authority.
• The boundary moves: novelty enters at the top and is compiled downwards once it is understood.

6

The Objection: Why Buy Software At All

Every argument in this essay carries an obvious reply, and any reader who has followed it this far has already formed it. If AI has collapsed the cost of producing software for vendors, it has collapsed it for customers too. A business can describe a workflow to a coding agent, connect a database and have a useful internal tool in days. Some companies are already choosing that route for selected functions rather than renewing expensive general-purpose software.

The argument has to meet this, because a thesis that cannot survive its own logic is not a thesis. And it should meet it without defensiveness, because the objection is correct as far as it goes. The answer cannot be that customers are incapable of building. Many are, and some should. A company with unusual workflows, strong technical leadership and a willingness to own the system may gain speed, fit and substantial savings by generating its own. The software market will contain far more self-built capability than it does today.

But look closely at what the decision is. Self-building does not remove the software producer from the arrangement. It relocates the software producer inside the customer.

The act of generation is only the beginning. Somebody now owns the specification and must keep it current as the business changes. Somebody monitors the connectors and repairs them when a third party ships a breaking change on their schedule rather than yours. Somebody manages permissions as people join and leave, tests every release, responds at midnight when something fails, tracks the regulation that changed in one market, patches the vulnerability disclosed on a Friday, answers the colleague who cannot make it work, and holds the institutional memory when the person who built it moves on. And somebody is answerable when the software takes an action it should not have taken — which, by the previous two sections, is now a category of failure that did not exist when software waited to be operated.

The distinction is easy to miss because software is first encountered as a repository and an interface, and those can now be produced astonishingly quickly. The continuing obligation is the invisible part.

A repository can be generated in an afternoon. A dependable product is a continuing institutional promise — that the system will work not only on the day it is demonstrated, but after an interface changes, a key employee leaves, an exception appears, a regulator asks for evidence, or an automated action has to be reconstructed and reversed.

This is a spectrum, not a binary. At one end a company buys a finished capability and delegates most of the continuing obligation. At the other it generates and operates everything itself. Between them sit managed specifications, shared runtimes, certified components and co-produced systems in which the customer controls its distinctive rules while a provider maintains the production machinery. The decline of code scarcity will create more ways to source software, not one universal model — and the important question in each of them is the same: who is carrying the obligation, and do they know it?

Figure 5. Software still gets built either way. What differs is where the continuing obligation sits.

So the role of the software company changes rather than disappears. It can no longer rest on the scarcity of code. Its reason to exist becomes the production and operating system around the code: maintained specifications, tested components, migration, security, support, permission infrastructure, monitoring, updates, and a named party who remains answerable.

The competitive question in software therefore changes shape. It stops being who can build the capability, because increasingly the answer is everyone. It becomes:

Who can keep the capability correct, current, connected and accountable as the world changes?

That question has a different answer — and it is not the one with the most engineers. The next essay in this series, The Expensive Last 10%, takes up the continuing obligation in detail.

Key points

• The objection is correct as far as it goes: many companies will build what they used to buy, and some should.
• Self-building does not remove the software producer. It relocates it inside the customer.
• The decline of code scarcity creates more ways to source software, not one universal model.
• The competitive question moves from who can build it to who can keep it true.

7

What Becomes Scarce

Every technological abundance shifts value towards a new scarcity. When computation was scarce, access to machines mattered. When distribution moved to the cloud, product focus and customer acquisition mattered more. As AI makes code abundant, advantage migrates to whatever code generation does not supply — and the list is worth walking, because the list is where a reader decides what to do on Monday.

Verified operating specifications. The tempting claim is that models lack domain knowledge, and it is the wrong claim. Models increasingly know how a returns process, an approval, a replenishment cycle or a reconciliation normally works, and they will know it better every year. Generic domain knowledge is becoming abundant. Current, organisation-specific operating truth is not. Which policy did this business choose, and how does it differ across its categories and jurisdictions? Where did the rule come from, and who owns it? Which exceptions have been accepted, by whom, and on what grounds? Who may override, and what happens when two rules conflict? What evidence would demonstrate compliance if somebody asked next week? None of that lives in a model. It lives in an organisation, mostly undocumented — and converting it into executable form is the scarce act.

Migration. Important software is rarely installed into an empty company. It enters a living organisation full of partial data, undocumented workarounds, stale permissions and processes that exist because somebody once met an exception. Discovering that reality, mapping it, reconciling it and switching without a bad week is not solved by producing a fresh application. The incumbent’s deepest protection was never its feature list; it was the customer’s fear of leaving — which makes this capability worth more now, not less, precisely because everything else about switching has become easier.

Accountability. Identity, permission, consent with legal provenance, suppression that must never fail, the audit record that reconstructs a decision, escalation, rollback, and a named party answerable for an action. As intelligence becomes common, permission to act becomes the differentiator. The valuable system is not the one capable of making the decision. It is the one the organisation is prepared to authorise.

Distribution and trust. AI collapsed the cost of producing a narrow capability. It did nothing to the cost of being discovered, believed, adopted and retained. Buyers still need evidence, references, continuity and confidence that the provider will be there after the first release. Production may be abundant while attention and belief remain scarce — and every argument that begins “software is nearly free to make now” and ends “so the market goes to whoever makes it” has skipped the only step that did not become cheaper.

The recompile system. The machinery of section three: identify which capabilities depend on a changed rule, regenerate them, test them, deploy them safely. A model can produce code. An institution must preserve the dependencies, standards and evidence that make portfolio-wide change reliable. This is also the answer to the self-build objection that no price argument can supply. The buyer is not purchasing software that works today. The buyer is purchasing the machinery that keeps it true tomorrow.

Domain judgement in executable form. As the cost of implementation falls, the person who can state the right rule, the exception, the test and the escalation path becomes more valuable than the person who can implement it. Over time the industry may develop production systems through which such experts contribute verified knowledge without having to found and operate software companies — a lawyer contributing a jurisdictional rule, an accountant a reconciliation policy, a clinician a triage protocol, an operator the exception logic learned over fifteen years, each contribution versioned, tested and governed rather than buried in an advisory document or translated imperfectly by a distant implementation team. The important unit would be the trusted specification rather than another isolated application. That is where this is going as an industry. It is not where anyone is yet, and a producer who announces it before earning it will be asked, reasonably, to show the thing.

AI makes this cheaper	AI does not supply this
Writing code	Distribution
Producing variants	Trust
Modifying software	Migration
Building narrow capabilities	Accountability
Testing routine behaviour	Domain judgement
Serving long-tail cases	Permission to act

Table 2. Value moves to the right-hand column.

AI commoditises production and raises the value of everything production cannot commoditise.

This will rearrange the industry rather than merely discount it. Some categories will be absorbed into general-purpose agent environments. Some companies will build more for themselves. Some vendors will become infrastructure providers, custodians of specifications, or operators of trusted vertical systems. The margin once earned from the scarcity of code will have to be re-earned through responsibility, distribution, migration and continuous correctness.

Key points

• Generic domain knowledge is becoming abundant. Current, organisation-specific operating truth is not.
• Migration matters more, not less, as everything else about switching becomes easier.
• The valuable system is not the one capable of deciding. It is the one the organisation is prepared to authorise.
• The buyer purchases not software that works today, but the machinery that keeps it true tomorrow.
• The margin once earned from code scarcity must be re-earned through responsibility, distribution, migration and correctness.

8

The Software Foundry

If the factory was the organisational answer to machines producing physical goods, something equivalent is required for machines producing software — and it is not a faster version of a software company. It is a different institution.

This series has described it in detail elsewhere, so name it rather than rebuild it. A software foundry treats specifications as its control surfaces and generated implementations as its output. It validates behaviour through inspection built into production rather than bolted on after it. It builds shared foundations once and lets each product be only the job it exists to perform. It pairs agentic control with deterministic execution. It grants authority through permissions, evidence and reversibility rather than through confidence. And it regenerates its estate when the world underneath it changes. The economics of that arrangement, the price it makes possible and the production system that sustains it are the subjects of the earlier essays.

This essay has stayed above that floor deliberately, because the larger change is not one company or one product category. It is a change in the nature of software itself, and it will be true whether or not any particular institution is built to meet it.

What this closing movement can add is only this. A foundry is not a way to make software cheaply. It is a way to be accountable for software at a price a far larger number of businesses can pay — and those are different ambitions, which is why cheapness alone has never won a software market and will not win this one.

The first age of software taught humans to translate intent into code. The next teaches machines to turn intent into software. Code does not disappear; it recedes from the centre of human attention, in the way machine instructions receded when compilers arrived and almost nobody mourned them. What moves into the centre is harder and more interesting: the specifications that state what must remain true, the systems that can rebuild software safely when the world shifts underneath it, and the institutions trusted enough to let software act.

The advantage will not belong to whoever writes the most code. It will belong to whoever can turn human judgement into dependable capability — and keep it true.

Here. “As marketing agents move from recommendations to autonomous decisions, CMOs must define boundaries, accountability and the limits of machine-led action.”

 

What to do Monday

None of this starts with a migration, a platform decision or a reorganisation. It starts with three numbers, and none of them is on your dashboard today. All three can be pulled this week, by the team you already have, without a project.

The number	What it measures	The question it answers
Real Reach	The share of your identified base that showed meaningful attention in ninety days — a click, a tap, a reply, a visit	What share of our list is alive? Ten million records with two million attentive customers is not a ten-million-customer asset
CRR	Click retention rate — how fast attention decays, send over send	Is attention rising or falling? It moves months before revenue does
REACQ%	The share of your “new” customers who are really old customers, re-bought through paid media	What did we spend re-buying our own? AdWaste, finally made measurable

One caution on how you measure the first two. Do not lean on the raw open rate. Privacy proxies and security scanners have made it close to fiction, so an “engaged” base counted on opens alone is inflated by machines. Use the stronger signals wherever you have them — clicks, taps, replies, visits, in-message actions. It is a harsher number and a truer one.

Most brands have never put a figure on the third one. In my experience it is usually the largest number in the room.

Then five decisions. Notice that four of the five are human judgements, which is the whole point — the agents cannot pick your number for you.

• Pick the number. Which single number are you accountable for this year? Everything below hangs off it.
• Build the TAT. Place every identified customer on the grid, and start tracking attention as the lead indicator.
• Count the leak. Real Reach, CRR, REACQ%. Three numbers, one week.
• Set the guardrails. What agents may decide, what needs your approval, and what must never be sent.
• Stand up a Team 6. One lost cohort, one holdout, one quarter. Pay on the difference.

Not a transformation programme. A cycle — and each turn should be cheaper than the last.

If you do only one of those things, do the third. Find out what you spent last year re-buying customers you already owned. Nobody in your organisation knows that number today, which is precisely why it is still being spent.

The formal version of that diagnosis is the Alpha Audit: bring your own data, get back how much repeat revenue you re-buy through paid media, how many proven buyers are quietly fading, how much value sits in customers who have gone dark, and how many of your buyers you ever convert into known customers — plus a cohort map and one recommended first move. Not six moves. One. That first move is almost always mechanical enough to run without believing any of the doctrine: suppress your active customers from retargeting, redirect the saved spend to owned channels, and measure the lift against a holdout. The performance team may argue the retargeting was incremental. The holdout settles it with your own data, usually inside a quarter.

Four things had to be true for the promise at the top of this essay to be more than a slogan, and all four now are.

• The profit is already inside your base. You do not need new customers to find it. The grid shows which cells it is sitting in and which of the six plays moves it.
• The work was never too hard — only too much. Agents take the volume. You keep the number, the offer, the brand and the veto.
• Intelligence is a commodity. Context is not. Everybody gets the same models next quarter. Nobody else gets your customer’s history — and it compounds only on ground you own.
• The largest ground you own is the inbox. And the biggest play in it is winning the Rest back before you pay a platform to re-buy them.

That is the whole of NeoMarketing in one line: stop doing marketing for its own sake, and start making profit from the customers you already own.

You are almost certainly paying twice for customers you already own — once in margin, and once in memory. The map shows where, the arithmetic shows how much, the holdout proves it on your own data, and the first move is small enough to make on Monday. — Never Lose Customers. Never Pay Twice. Never Pay Fixed. 

The argument in brief

Question	Answer
The problem	You pay Google and Meta to re-buy customers already in your database — AdWaste your dashboard counts as a win.
The map	The Transaction–Attention Table: rows are transactions, columns are attention. Strong → Grow, Weakening → Protect, Lost → Recover.
The inflection	60–65% buy once and never return; the second transaction roughly triples lifetime value. The game is getting to two.
Why it never happened	Not talent, effort or budget. Arithmetic. Adtech automated its side; martech did not, so the money went where the work was easy.
What changed	Agents run the instances at the volume the grid demands. Humans keep the number, the offer, the brand and the veto.
Why agents are not the moat	Everyone gets the same models next quarter. Context is the only input that cannot be bought — and it compounds only on ground you own.
The upgrade	You pay twice: once in margin, once in memory. Adtech takes a third of the transaction and keeps what it learned.
The surface	The inbox is the largest ground you own — and at L4 the message is composed at open, which is where the agent stops drafting and starts deciding.
The sixth play	Recover the lost column — a different machine that earns attention before it asks. Build a Team 6, or buy it as Progency with MGEs.
The maths	Half the tax is double the return. ~16 points saved on the recovered share, plus ~5% of revenue from the owned plays. 10% margin → ~20%.
The proof	A concurrent, randomised holdout against your current best effort. Paid on the lift, and only the lift. No improvement, no invoice.
Monday	Real Reach, CRR, REACQ%. Then suppress active buyers from retargeting, redirect to owned, and measure against a holdout.

Recover the Rest — and how it should be bought

Which brings us to the play with the most money in it, and the one nobody owns.

Today the lost column is handed to adtech by default, and the mechanism is worth watching in slow motion. You pay a platform to retarget. The platform re-shows your own customers to themselves — people already in your CRM. Some of them re-buy, which is revenue you would have had some share of anyway. And the measured performance of that campaign raises your acquisition cost benchmark, so next quarter you pay more for the same trick. For most brands around seventy per cent of repeat transactions come back through this rented channel, at roughly a third of the transaction value, which is exactly what a return on ad spend of three means.

It hides under different names in different industries. In banking and insurance the same tax appears as aggregator commissions and comparison-site payouts. In telco it is dealer reactivation spend. Different collector, same leak.

Here is where most teams go wrong when they try to fix it in-house: they treat recovery as a harder win-back campaign. But by the time a customer is in the lost column the channel is still open and the customer has simply stopped listening. Sending a sharper offer down a channel no one reads only trains them to ignore you faster. Recovery is not a better campaign. It is a different machine.

That machine runs a different sequence: attention, then repetition, then conversion. It re-earns the open, builds the habit of opening, and only then asks for the sale. Relate carries no offer at all — it is a reason to open, not a discount, and its only job is to rebuild reachability. Digest turns a re-opened inbox into a habit. Sell comes last, when the customer is paying attention again, and it closes in the channel, with no detour to a website where the intent leaks away. The CRM team starts at conversion, because that is what it was built to do. Recovery starts at attention, and earns the right to sell.

The sequence, the capability, and the only acceptable way to buy it.

The sixth play deserves an owner that does exactly this, and nothing else. Call it a Team 6: a small pod with one number to hit, working the lost column on owned channels, before the auction. The name carries the number. Adtech recovery runs at a return on ad spend of about three, which is a tax of roughly a third. Owned recovery runs at roughly half that tax, which is roughly double the return — a six. Team 6, because its job is a ROAS of 6.

Illustrative and conservative. The ₹-per-customer reacquisition cost, the recovered share and the margin are all yours to replace with your own figures.

A brand can staff this two ways. Build it in-house — three or four people who own the outcome with agents running the volume underneath — or buy the outsourced version, which is what I have called Progency, delivered by MarTech Growth Engineers who bring vertical expertise, sit close enough to the business to understand its context, and own the number rather than the campaign calendar. Same function, same measurement, two ways to staff it. Nothing else about the model changes between them.

Both halves are load-bearing, and it is worth being precise about why. The agents supply scale: cohort discovery, analysis, content variants, channel choice, timing, and continuous learning from what happened. The engineers supply the other half: domain knowledge, business judgement, governance, exception handling, and ownership of the result. Agents without accountable humans are automation without judgement. Humans without agents simply recreate the arithmetic constraint that caused the problem in the first place.

What must not change is how it is bought. Never Pay Fixed is not a slogan about discounts; it is a statement about where the risk sits. A named group of lapsed customers is worked. A matched group is left alone alongside it, still receiving whatever you do today. Concurrent, randomised, and measured against your current best effort — never against last quarter, which measures the season as much as the work. You pay a share of the difference, and only the difference.

No improvement, no invoice. No control, no claim. That single mechanism is what separates this from a vendor’s spreadsheet: the number is measured against a control the brand audits and the vendor cannot move. And it is the cleanest test you can apply to anyone selling you outcomes, including me. Ask whether they will hold back a control group and take their fee only on the lift. The answer tells you whether they believe their own deck.

There will be cases where hybrid economics are the sensible answer, because delivery and infrastructure do cost something before any lift exists — a baseline plus a share of the alpha. That is a reasonable structure. What must survive intact is the principle underneath it: the upside paid to a partner comes from measured incremental value, never from activity dressed up as performance.

The honesty has to travel with the limits, so here they are. Recovery at a return of six is strongest for replenishment-led categories — beauty, supplements, grocery, pet — where the timing is predictable, and for high-value customers where the relationship was real before it went quiet. It is weakest for one-off, high-consideration purchases with no repeat logic. And gross margin governs a separate question from the saving: the saving from re-routing revenue more cheaply is the same at any margin, but whether a recovery is worth running at all depends on the return clearing one divided by your gross margin — comfortable at seventy per cent, demanding at fifteen. Scale is reached by stacking cohorts that each clear the bar against their own control, never by averaging good cohorts and bad ones into a blended promise.

One more constraint belongs in the open, because it shapes how fast any of this can go. Outcome-only pricing means funding the delivery upfront and collecting in arrears. That caps how many pilots can run at once, for the vendor and for the brand’s patience alike. It is a real limit, and a model that does not name it is not being straight with you.

The arithmetic of the whole essay lands here. A business on a ten per cent operating margin that recovers something like thirty per cent of its revenue through paid media today is paying roughly a third in tax on that share. Move it to owned recovery at roughly a sixth and you save about sixteen points on the recovered share — a cost you simply stop paying, so it falls straight to profit. Tighten the five owned plays and add perhaps five per cent of revenue on top. Ten per cent operating margin becomes something close to twenty. On $100m of revenue, roughly $10m of profit becomes roughly $20m — and none of it required a bigger budget.

The test of whether a partner believes its own numbers is whether it will hold back a control and take its fee only on the lift.

The largest ground you own is the email inbox

If context compounds only on owned ground, the practical question becomes which ground you own the most of. For almost every consumer brand the answer is the one nobody wants it to be.

Seventeen crore Indians open an email every month. Thirteen crore click something inside one. You own that channel outright: no platform can change the rules, raise the price, or switch off your reach overnight. It costs fractions of a paisa a message, against a per-message fee on every other channel you run. And it is already permissioned — you have the address, the consent and the relationship, with nothing to rent back from anyone.

One caveat deserves stating before anything else, because for some brands it ends the section. If your forms capture a mobile number and not an email address, none of what follows is available to you, and fixing the capture form is the whole of your first quarter’s work. Capture is play one for a reason.

Now, the reason nobody in your marketing team believes any of this. For twenty-five years, an email could do exactly one thing: click out. It was written on Monday, it was true on Monday, it was sent to everybody, and the only real action available took the customer out of the inbox and onto a page where most of them never arrived. Every email innovation for two decades made that single verb prettier. Better templates, better subject lines, better send-time optimisation — all of it in service of a click that leaked most of the intent it created.

That constraint has gone, and it has gone in stages worth naming, because most brands stop one rung too early and conclude the whole thing was overhyped.

Most brands reach L1, call it interactive, and stop. The inflection is two rungs further up.

L0 is the ordinary email you send today. L1 adds an interaction inside the message — a calculator, a poll — which is where the phrase “interactive email” usually stops. L2 writes the input back: forms and declared data land in your record. L3 is app-like and multi-step: an OTP, a checkout, a KYC step, completed without leaving the message. L4 is the one that matters. A living email is composed at the moment it is opened, not at the moment it is sent.

The inflection is L3 to L4, and it is a change of kind rather than degree. Fixed-at-send becomes composed-at-open. That is the precise moment an agent stops drafting a campaign and starts making a decision — with the real price, the real stock, the real balance and the real availability fetched at open, and again on every tap. It is also the moment the two halves of this essay join: the context layer is what the message is composed from, and the message is what deposits the next piece of context back.

Take an ordinary case. Arun is sent a replenishment email on Monday and opens it on Thursday. The old email shows him what the brand decided on Monday — a price that may have moved, stock that may have gone, an offer he may already have used. A living email asks what is true on Thursday. Is the product in stock now? Is he inside his replenishment window? Has he already bought it elsewhere in your estate? What is his reward balance at this second? Does he need a transaction at all, or would something useful serve the relationship better today? The message stops being a message and becomes a viewport onto the live relationship.

So much for capability. The business case is separate, and it has three parts, because email today sits on your P&L as a cost line — a per-message fee, a list you rent access to, and an open rate nobody can spend.

Yes-in-email. The lowest-friction action there is. Consent, an application, a lead for the next product — captured inline and validated with an OTP, with no landing page in between. Nothing leaks between the intent and the record, which means more of the intent you already paid to create survives to the record.

Pay-in-email. The transaction ends where the attention already is. Bills, renewals, repeat orders, restarts, top-ups. You created the intent and then asked the customer to travel for it; the click-through was never a step in the journey, it was the leak. Six chances to lose them become one.

Pre-adtech recovery. The lost column, worked on a channel you own, before a single rupee goes to a platform to rent back a customer already sitting in your database. This is the sixth play, and it is large enough to get its own section.

There is a fourth thing, and it is the one almost nobody does. Most brands have two or three useful things to say in a week and send twelve emails anyway. The daily digest is the opposite: something useful, on a rhythm, whether or not there is anything to sell. For a bank or a broker, the money note — where the portfolio moved, bills due this week, the SIP that went through, one thing worth understanding, with numbers current at the second the customer opens it. For retail or fashion, what came back into stock in the size they buy and the two colours they own. For travel, where their points stand and what the fare is on the route they always fly.

It looks like a soft play and it is the hardest-working one on this list, for two reasons. It earns you the right to be opened on the day there is something to sell. And it quietly feeds the context layer every single week, at almost no cost, on ground you own.

Put all four together and the cost line changes sign. Start with delivery and content. Subtract what capability earns — the yes and the pay completed in-channel. Subtract what outcomes earn. Subtract, eventually, what a channel people open is worth to a third party. Net cost lands at or below zero. The order of those terms is the order of the build, and it is not negotiable: capability earns first, outcomes earn next, and only a channel people already open is worth anything to anyone else. You cannot begin at media.

EARN is a business-model migration, not a feature list. The sequence is the substance.

And one rule keeps the whole ladder honest, because without it EARN becomes a way of billing the same brand twice for the same work: never charge for both capability and outcome on the same audience and the same intervention. Pick one, per cohort, and say which.

At which point the real objection arrives, and it is always the same sentence: nobody on my team can build forty of these a month. Correct. And it is not a talent problem or a budget problem — it is the same arithmetic problem from section four, with the same answer. Roughly sixty to seventy per cent of use cases sit at L0 to L2: calculators, quizzes, polls, capture. No integration, nothing calling your servers, nothing for compliance to review, live in twenty-four to forty-eight hours. L3 and L4 are the handful of moments that touch money, on your own rails with secure token exchange and a graceful fallback underneath. The volume comes from agents composing against context and the brand wiki, with humans approving and holding the veto. The reason most brands stop after one clever email is not that the second one is harder. It is that nobody can make the fortieth by hand.

Four unglamorous things sit underneath all of it, and they are the multiplier on every number above. Land in the primary inbox, because everything downstream is a fraction of what arrives somewhere a person might see it. Count people rather than machines, because privacy proxies and security scanners have made the raw open rate close to fiction. Assemble at open, not at send. And degrade gracefully — not every client renders an interactive message, so every one of these needs an ordinary version underneath, and nobody ever sees something broken. Deliverability is not a feature. It is the multiplier.

For twenty-five years an email could do one thing: click out. The change is not that it got prettier. It is that the message is now composed at the moment it is read.