The Business Runtime: When the Agent Becomes the Application

Connecting AI to all your business apps still feels like a chatbot with errands, and that is not an integration failure. It is a custody failure. Here is the architecture that actually replaces the applications — and the six primitives it runs on.

Scott Farrell · LeverageAI · August 2026

A small business today runs a website builder that understands the website-shaped version of the business, a CRM that understands the sales-shaped version, an inbox that understands the mail-shaped version, and an accounting package that understands the ledger-shaped version. Each is competent inside its own frame. None of them can responsibly perform the join, because the join needs all of them at once and no vendor should hold that picture.

So the join stays where it has always been: in the owner's head. That is the actual product being purchased when someone buys their seventh subscription — not software, but a slightly better shard of a business nobody has assembled.

The market has now noticed. In the first week of February 2026 more than a trillion dollars of market capitalisation was erased from software stocks in seven days,¹ and when Forrester enumerated what investors were actually afraid of, the fourth item was not a competitor or a pricing model. It was this: “SaaS products are fundamentally too complex, and users struggle to manage the SaaS sprawl of hundreds of applications that don't talk to each other.”¹ The sell-off was software-specific rather than macro — over the same window the software index fell 32% while the broader index stayed essentially flat, taking median multiples to decade lows around 3.1x revenue.²

The diagnosis is right and the prescription that follows it is usually wrong. The prescription being sold in 2026 is connection: a copilot in every silo, a connector to every system, one chat window over several data sources, a scheduler that runs a prompt every hour. That posture leaves the applications in charge and hands the user a conversational remote control. It is the reason a business can wire AI into everything and still feel like it has hired an enthusiastic intern who reads the mail and then tells you about it.

This piece argues something more specific than “AI will eat software”. It argues that the applications were never organising the work in the first place. They were organising attention — and once something other than a human can hold an obligation, the boundary they drew has nothing left to do.

Part I — The problem is not integration

The evidence that the app-embedded copilot is losing

There is an unusually clean natural experiment running inside large organisations right now, and it does not depend on anyone's opinion about architecture.

Microsoft's Copilot and OpenAI's ChatGPT reach knowledge workers through the same underlying models. One of them lives inside the applications where the work nominally happens; the other sits above them as a general surface. Recon Analytics surveyed more than 150,000 respondents and found that when Copilot is the only AI an employer provides, 68% of workers adopt it as their primary tool — but when all three major platforms are available, only 8% choose Copilot while 70% choose ChatGPT.³ Over seven months Copilot's share among paid US subscribers fell from 18.8% to 11.5%, a 39% contraction during a period of deepened Office integration.³

Same models. Same users. Better distribution for the loser. The variable that moved was where the intelligence sat relative to the applications.

That is a market result, not an argument, and it is worth being careful about what it does and does not show. It does not show that a general chat surface is the right architecture — we are about to argue at length that it is not. It shows something narrower and more damaging: that putting AI inside an application inherits that application's frame, and workers can feel the difference well enough to walk away from the tool their employer already paid for.

Why in-app AI hits a wall

We have made this argument before at personal scale. In-app AI “can navigate a catalogue; it cannot responsibly hold your whole world” — and if every service builds its own model of you, you end up with six partial, badly-drawn versions of one person, each wrong in different ways, each incentivised to keep you inside its own ontology.⁴ The conclusion at personal scale was that the join belongs on the user's side.

The business version is structurally identical and commercially larger. Wix AI knows the website-shaped business. A CRM's AI knows the sales-shaped business. Gmail's AI knows the inbox-shaped business. An accounting package's AI knows the ledger-shaped business. Each holds a partial, vendor-centred model, and the useful decisions live in the join between them.

The business model should sit with the business.

Notice what that sentence is not. It is not a demand for data ownership in the compliance sense, and it is not a call to migrate anything. It is a claim about where interpretation lives. A vendor can hold your records perfectly well. What it cannot do is hold the interpretation of your business, because interpretation requires everything at once and every vendor's interpretation is shaped by the part it sells.

The sprawl story in 2026 is worse than “too many apps”

The intuitive version of this problem is that the number of applications keeps rising. That turns out not to be the interesting part. Analysis of more than 40 million SaaS licences found application counts essentially flat year on year — and simultaneously found that business units now control 81% of SaaS spend while IT directly manages just 15%, that 36% of licences sit unused against recommended utilisation levels, and that 78% of IT leaders reported unexpected charges tied to consumption or AI pricing in a single year.⁵

Read those together and the shape changes. The stack is not growing; it is churning and dispersing. Nobody holds the whole picture, spend is fragmenting away from the function that could see it, and more than a third of what is bought is not used. This is not a procurement problem waiting for a better dashboard. It is what a system looks like when no single actor is responsible for the whole.

Part II — The poor staff machine

Here is the shape almost every agent platform shipped in 2025 and 2026, including the one I run in production myself. There are channels. Inside channels there are conversations. There are skills, and credentials that let those skills reach data services. And there is a scheduler that fires on a deterministic clock but runs a non-deterministic prompt — so you get “check my email every hour”, and the AI reads your mail, and the entire job of that run is to update a conversation thread.

Everything comes back to a conversation thread in a channel, which is eventually just going to get tedious. And then the platform hands responsibility back: I put it in the conversation, my job's done.

I am not describing a competitor. OpenClaw is the platform I actually operate, and my own email runtime uses it — specifically, it uses it for the cron. The critique is of a pattern, and the pattern is inherited chatbot thinking: the conversation as the application's primary object. When the primary object is a conversation, the terminal state of every piece of work is a message. A message is not an outcome.

The staffing test

Anyone who has managed people already has the vocabulary for this.

Really poor staff members just generate problems and raise them to the manager — everything becomes a problem in their world. “This customer emailed, what should I say?” “There's a problem with the invoice.” “These two records don't match.” “What do you want me to do?” They regard recognising the problem as completing the job. Really good staff, when you've got them, everything becomes easy, because they deal with everything one way or another. They understand what the organisation is trying to achieve, assemble the history, distinguish policy from precedent from preference, work through the available avenues, wait where waiting is appropriate, follow up without being reminded, act within their authority, and raise only the irreducible judgement call.

You don't want AI to be problem staff. You want AI to be the staff that takes care of everything and makes it easy.

The AI should absorb managerial burden, not manufacture it.

That is a product standard, and unusually for a product standard it is falsifiable by a non-technical owner in a fortnight. A chatbot that reads email and posts a summary into another conversation has moved the problem, reformatted it, and handed responsibility back. It has manufactured managerial work while appearing to reduce it. The valuable agent does not say “I processed your email”. It says, implicitly, I own what this email means until the underlying matter is finished.

Which means the output of good AI is often silence plus a changed world state: the follow-up happened, the information was gathered, the customer was answered, the commitment was recorded, the matter remains under observation. If your success metric is messages processed or drafts generated, you have instrumented the poor employee. The metric you actually want is closer to: how much operational ambiguity was absorbed without losing intent, violating authority or consuming unnecessary human attention?

Part III — Responsibility is the primitive

The alternative is one sentence long, and it took a wrong turn to find it. The first version was “every event an agent” — every incoming email becomes an agent that takes responsibility until it's done. That is nearly right and breaks immediately: five replies in one email thread would become five agents.

The fix is a small conceptual step:

The primary object isn't a conversation. It's a responsibility. Every event is routed to a responsibility; a responsibility has a persistent agent custodian.

Sometimes the event creates one. Sometimes it wakes one that already exists. And the formal definition is the load-bearing sentence of the whole architecture:

Responsibility is persistent custody of the gap between the current world and the intended world.

Read it as five clauses, because each is a component. Intent defines what good looks like. The world model says where things currently stand. Responsibility means something owns that gap until it closes. Authority defines what may be done about it. Outcome proves whether it actually closed.

The six primitives

1. One world — continuously compiled from the business's complete event estate.
2. Held intent — durable desired states, constraints and standing orders.
3. Responsibilities — persistent ownership of gaps between current and intended states.
4. Custodian agents — long-running identities that absorb ambiguity and work toward closure.
5. Bounded authority — policies, permissions and approvals external to model discretion.
6. Outcome closure — proof that action changed reality, and learning returned to the world.

If you take one thing from this piece, take those six and the loop that runs them:

EVENT
  ↓
attach to an existing responsibility, or create one
  ↓
activate the relevant business world under held intent
  ↓
wake the custodian agent with its working continuity
  ↓
investigate, act, wait or escalate — within authority
  ↓
observe the result
  ↓
close, continue, split or reopen the responsibility
  ↓
write evidence to bronze · update episode state in silver
· write only genuine understanding deltas to gold

Walk one: complaint #417

Abstractions like that are cheap. Here is the same thing as a record you could put in a database this week.

Customer complaint #417
custodian:                 agent A
state:                     waiting on courier
opened:                    Monday
standing human decisions:  do not refund yet; customer prefers replacement
authority:                 may communicate; may query order and courier;
                           refund requires approval
working context:           what it has tried, inferred, rejected and promised
events:                    email → courier update → human instruction
                           → new customer email → delivery confirmation
closer:                    customer confirms resolution / defined timeout outcome

Now walk it, because the walk is where the architecture either earns its keep or doesn't.

Monday. An email arrives: a delivery hasn't turned up. Under the conversation architecture this creates a message for a human. Under this one, the router asks a single question — does this belong to an existing responsibility? — and, finding none, opens #417 with a custodian.

Monday afternoon. The custodian queries the order, queries the courier, and finds the parcel scanned into a depot and not out. It has authority to communicate, so it tells the customer what it found and what happens next. It has no authority to refund, so it does not offer one. It goes dormant with an expected next event: courier status change.

Tuesday. The owner, reading the morning queue, adds a standing decision: do not refund yet; the customer prefers a replacement. That is not a chat message that will be summarised into oblivion. It is a binding field on #417. Every future actor — including a completely fresh agent process — inherits it.

Wednesday. A second email arrives from the same customer, angrier. The router finds #417 and wakes its custodian rather than opening a second responsibility. This is the moment the architecture pays for itself: the agent does not have to rediscover Tuesday's instruction from a mailbox, infer it from absence, or fish one sentence out of an amorphous memory store. The decision lives inside the responsibility it governs.

Friday. Delivery confirmation arrives. The custodian does not close on the delivery scan, because the closure condition is not “parcel moved” — it is customer confirms resolution, or a defined timeout outcome. It asks. The customer confirms. #417 closes, and what the episode taught goes back into the world.

The inversion, and what collapses because of it

Once responsibility is the primitive, two things follow that are larger than the primitive itself.

The first is a reversal of gravity:

In chatbot architecture, agents exist to service conversations. In this architecture, conversations exist to service agents that own responsibilities.

Chat does not disappear — it is demoted to what it is genuinely excellent at: expressing new intent, refining a standing rule, asking for an explanation, exploring an unusual case, modifying a proposed action. It becomes one way a human injects an event. Anthropic described its own general agent as working “less like a back-and-forth and more like leaving messages for a coworker”⁶ — which is the inversion arriving from the vendor side, in a product announcement.

The second consequence is the commercially interesting one. Ask why each application category exists:

• CRM exists because we needed somewhere to make humans remember customer responsibilities.
• The inbox exists because we needed somewhere to make humans notice communication responsibilities.
• Ticketing exists because we needed somewhere to make humans track support responsibilities.
• Project management exists because we needed somewhere to make humans remember work responsibilities.
• Calendars, tasks and reminders exist because humans forget future responsibilities.

Five products; one cause. A runtime whose primitive is responsibility attacks the common cause of all five. So the more profound claim is not “AI rebuilds CRM and email and project management”. It is that a responsibility-native runtime makes many of those categories collapse into the same primitive — and what survives of them is the view:

• CRM becomes the customer-and-opportunity lens.
• Inbox becomes the new-communications lens.
• Helpdesk becomes the unresolved-customer-responsibility lens.
• Project management becomes the commitments-and-dependencies lens.
• Calendar and tasks become future-event and expected-action lenses.

The applications become projections. The world remains singular.

This is the concession that makes the collapse survivable in practice. Humans can still be given a familiar inbox-like or CRM-like view where it genuinely helps. What those views no longer own is separate data, separate workflow, or separate AI context.

Two persistences, because the agent is not the durable object

The obvious objection arrives here, and it is a good one: long-running agents are unreliable. Context degrades, sessions die, and you will end up reconstructing state anyway.

The objection is empirically correct. Testing across eighteen models found that performance “grows increasingly unreliable as input length grows”, and — the more useful finding — that “whether relevant information is present in a model's context is not all that matters; what matters more is how that information is presented”.⁷ Our own prior work named the operational symptom before the lab measured the curve: a session that is sharp for fifteen minutes, strong for thirty, and by forty-five is asking redundant questions and losing the thread of decisions it made itself.⁸

But notice that the objection assumes the agent is the thing being trusted to persist. It isn't.

Reconstructing purely from source events recovers the factual sequence and loses the working judgement: why one path was rejected, what was already tried, what the owner explicitly said not to do, an unresolved suspicion, a working theory, why it is waiting rather than acting. Agent memory of the global-blob kind is genuinely sloppy — if you try to remember each of those small decisions in one big memory, it is hard to pick which is the right one. So the architecture refuses to choose between the two options on offer:

That last clause is what makes the durable half a check rather than a backup. A live session keeps the story of the work alive, including the wrong story — which is precisely why the warm cognitive loop can never be the system of record.⁹ Both halves are required, and neither can do the other's job: the conversation is excellent working memory and a terrible system of record; the durable state is an excellent system of record and hopeless at holding an unresolved line of reasoning mid-flight.

The agent may sleep, compact, restart or die. The responsibility may not.

Which is also the answer to “where does don't reply to this bloke live?” Not in a giant global memory that must be searched and ranked and hoped over. Not in a chat transcript. It is a binding decision attached to the responsibility, person or relationship it governs. The warm agent understands why. The durable state ensures every successor obeys.

Part IV — The substrate that makes it possible

None of the above works over a stack that has to be re-interviewed on every task. The custodian needs somewhere to look from.

One address space, several clocks

The instinct is right and usually stated too bluntly: if you're insourcing applications, you just chuck it in one big database into the bronze layer, and have agents take responsibility and own the intent and execution over time. The correction is not to abandon that, it is to be precise about what is being centralised.

One control surface does not require one database. It requires one interpretation of the business.

The important centralisations are one identity model, one business ontology, one case and intent model, one policy and authority model, one action history, one audit and provenance trail. Raw storage can remain plural. This distinction is not pedantry — centralising meaning can reduce breach blast radius, while indiscriminately centralising raw content enlarges it. An omnipotent agent over one enormous pool of raw mail and files is a worse security posture than ten silos, and the fix is that ordinary agents receive claims and pointers rather than unrestricted mailbox access, with raw-source descent kept exceptional, scoped and logged.

What one physical database does not mean is one undifferentiated epistemic layer. The same Postgres can hold layers with very different meanings and write rules:

Those are different clocks, and forcing any two onto one tick inherits the worse cost curve of the pair — a system explodes not because models get worse but because one layer is forced to remember, attend and understand on the same growth schedule.¹⁰

One schema cannot serve every clock. One Postgres can.

Silver is where records become episodes

One email at a time is the wrong semantic grain. An email is an observation. A thread is closer to an episode. But even a thread may be only one channel through which a larger responsibility expresses itself:

Customer complaint
├── website form
├── confirmation email
├── staff reply
├── courier enquiry
├── internal note
├── customer follow-up
├── refund transaction
└── final confirmation

The true object is none of those. It is the unresolved customer matter. So silver is not “cleansed data” — it is the layer where the system makes a judgement:

These fourteen technically different records are all part of the same thing happening.

We have argued the same structural point about news: the article is an observation, and the evolving case is the story.¹¹ Business operations are the same shape with higher stakes, and the error preference is symmetrical: do not create from laziness or fear of missing a duplicate, and do not merge two genuinely distinct matters because they share a customer.

Gold is orientation, not retrieval

This is the part I can speak to from a running system rather than a diagram.

My own email runtime ingests everything into bronze — whole threads, not one message at a time — and responds against a gold wiki. Every hour it ingests email updates back into gold to keep relationships and meetings current. Sent mail gets special treatment: because it's from me, it goes into gold with real weight. That's the truth of what the business has actually said. I'm only using it for “is this important” at the moment, and it's scary good at it.

The mechanism is a reversal of the conventional order. Traditional processing starts from the event: email arrives, search the mailbox, search the CRM, retrieve some documents, try to reconstruct context, answer. This starts from the world: the business world is continuously compiled, an event arrives inside an already-understood world, it attaches to existing people, projects and responsibilities, the relevant task world activates, the agent acts, and the outcome updates the world.

Here is why that difference is not cosmetic. An email says:

“Are you still interested in exploring a partnership?”

Read harder and it stays exactly that ambiguous. But the gold world establishes: this person approached before; you considered it; you rejected it because it sat outside strategy; nothing material has changed; they are connected to a project you do care about; and you previously decided not to respond unless a particular condition changed.

The intelligence does not come from reading the email more carefully. It comes from locating the email in the organisation's history.

That is why a compiled world outperforms repeatedly searching mail, CRM and invoicing. Retrieval is being asked to discover the organisation from fragments while solving the task. Gold has already paid most of that comprehension cost. And it is exactly the finding that presentation of context matters more than volume of context,⁷ given an organisational answer: gold is not what the agent looks up; it is the world from which the agent looks.

There is one more move in the loop, and it is the compounding one:

WORLD interprets EVENT
EVENT revises WORLD
revised WORLD interprets next EVENT

Gold is not merely downstream of ingestion; it participates in ingestion. When my system ingests a thread it reads gold first to understand what the thread means, then writes back what changed. That is how a corpus stops accumulating and starts compounding — otherwise you double the documents and double the noise.¹² And bronze stays essential precisely because it lets new evidence correct the world instead of being forced into the world's existing categories: gold supplies orientation; bronze supplies the ability to challenge that orientation.

Not all events have the same epistemic weight

Weighting sent mail more heavily turns out to be a general principle rather than a personal habit. A received email is usually an assertion or observation from somebody else. A sent email from the business may be an authorised organisational speech act: it can express a decision, create a promise, reject a proposition, establish intent, delegate work, change a relationship, or commit the business to an action.

So the useful common schema is less about application categories — email, CRM record, invoice — and more about semantic roles: observation · assertion · decision · commitment · instruction · action · outcome. Each record keeps its source-native fields; the common layer knows what kind of contribution it makes. A payment is an action or outcome. A sent email may be a commitment. A manager's instruction may amend intent or authority. A customer's reply may confirm or disconfirm closure.

This is how “chuck everything into bronze” becomes more than a data-lake idea. It becomes a record of the business perceiving, deciding, committing and acting.

Agent exhaust becomes organisational experience

The last substrate question is what to do with the agents' own work, and there is a strong temptation to answer it with “memory”. That temptation is the anti-pattern.

Conventional memory does something like this: conversation → session summary → summary of recent summaries → a small profile → inject some of it into every future task. The weakness is not that summarisation loses detail. It is that every summary was produced for a particular objective, at a particular moment, under a particular understanding of what mattered. A debugging conversation gets summarised around the fix and loses the architectural reason two alternatives were rejected. Then the next compression summarises the compression, and the loss becomes irreversible. It is memory shaped as a decaying photocopy.

That used to be an argument from intuition. As of 2026 it is measured. A rate–distortion analysis of memory compaction found that “under repeated irreversible summarization, end-task error grows super-linearly in the number of compaction events, whereas a reversible, retrieval-backed memory stays flat” — in their experiment the reversible operator held recall near 0.95 at every compaction frequency while the irreversible one ran between 0.33 and 0.56, weakest where compaction was most frequent, “because each summary throws away facts the next summary can no longer see and the loss compounds”.¹³ Their first design principle is “never discard irreversibly what you cannot re-derive cheaply”; their third is to “separate a cheap reversible episodic tier from a lossy semantic tier, with explicit promotion and demotion”.¹³

That is bronze and gold, arrived at independently. Our own version of the first principle is older and blunter: storage is cheap and comprehension is now cheap, so deletion is the only irreversible operation left in the stack.¹⁴

So the architecture is not memory. It is reversible compilation. The complete agent session goes to immutable bronze with links to whatever it changed. Separately, that session is compared against the existing gold worldview and asked a much narrower question: what meaning actually changed? Only that becomes a governed gold mutation. Later, a new responsibility gets orientation from gold, search nominates relevant bronze episodes, and the agent opens the exact transcript when nuance matters.

Gold remembers the significance. Bronze remembers the experience.

Agent work then compounds at three levels: within the responsibility (the custodian keeps its working gestalt), across similar responsibilities (prior complete episodes can be found and reopened), and across the organisation (repeated or consequential lessons become worldview changes). Which is the real difference:

Memory summarises the past for the next conversation. Institutional learning changes the world model for every future responsibility.

Part V — What dissolves, and what you keep renting

Now the commercial question. If responsibility is the primitive and the world is singular, what actually happens to the software?

SaaS does not disappear app by app. It dissolves function by function.

And the distinction that keeps this honest:

The visible application shell may become extremely cheap. The operational contract behind it does not.

A subscription bundles several different things that AI affects very differently. Sort them and the decision becomes tractable:

Read down the right-hand column and the doctrine writes itself:

Own the mission layer. Rent the operational depth.

This is not a new mechanic; it is one we have already proven in a single category. A CMS was never one product — it fused a translation layer for humans who could not operate HTML, CSS, hosting and databases with an operational control plane for publishing, roles, forms, payments and plugins. AI does not modernise that fusion; it dissolves the first job and forces the second to unbundle.¹⁵ The six rows above are that two-jobs test generalised to the whole stack.

Applying it: the email row, walked

Email is the cleanest case, because the boundary runs straight through the middle of it.

All of this can plausibly disappear from ordinary human work: the inbox as a task list; manual spam triage; opening threads to understand context; deciding who should respond; searching the CRM before replying; copying information between systems; composing routine responses; remembering to follow up; filing and categorising.

None of this can: sender reputation and deliverability; abuse management; SPF, DKIM and DMARC; malware and phishing controls; queueing and retry; continuity; regulatory retention; broad ecosystem compatibility.

And the second list is not a matter of engineering taste — it is set unilaterally by the receiving oligopoly. Google requires SPF or DKIM for all senders, adds DMARC with alignment above 5,000 messages a day, requires valid forward and reverse DNS and TLS, and tells senders to keep spam rates below 0.10% and never reach 0.30%.¹⁶ Microsoft rejects non-compliant high-volume mail outright with “550; 5.7.515 Access denied, sending domain does not meet the required authentication level”.¹⁷ Reputation is continuously earned, not built in a sprint, and a failure is a rejection at the door rather than a support ticket.

So the architecture is a supply chain with a seam in it:

Retained mail rail
    receives and delivers messages
              ↓
Business Runtime
    identifies the person and the responsibility
    joins all relevant context from the compiled world
    decides act / draft / escalate, within authority
    records the outcome
              ↓
Retained mail rail
    delivers the authorised response

You can insource the brain without insourcing the postal service.

Or more bluntly: do not start by building Gmail. Start by making Gmail irrelevant. The employee need never open a mail client on the ordinary path, while the rail stays rented and the vendor's interface and ontology stop organising the business. The same split applies to payments, identity and communications generally.

Why the SaaS default is reversing at all

There is a historical loop worth stating as a falsifiable claim:

self-hosted software
    → SaaS, because operation was painful
        → AI-operated self-hosting, because operation becomes cheap again

The load-bearing word is operation. Everyone has noticed that AI collapses the cost of writing an application. The less-discussed claim is that it collapses enough of the administration cost that originally drove small businesses into SaaS in the first place. Small businesses did not adopt hosted mail because they loved the product; they adopted it because in 2005 running your own was a full-time irritation. Linux already knew how to receive, queue, store and send mail — that is where email started, with mbox and Sendmail. Add modern filtering, DNS hygiene, backups and an AI operating layer, and “our own mail server” is not the mad proposition it became during the SaaS era.

I want to be exact about the evidential status of that claim, because it is the weakest-sourced link in this piece. The direction of travel has independent support: a survey of 212 senior IT decision-makers found 89% planning to expand on-premises footprint over two years and 75% having already moved workloads back from public cloud, with 99% citing data sovereignty as at least a moderate factor — though it was commissioned by a vendor selling on-premises storage, which you should weigh.¹⁸ Practitioners are making the argument in the hardest category too: “you can self-host anything but not your e-mail server” is the standing advice, and operators are now publishing detailed counter-cases — while conceding that you become responsible for backups, recovery, remote access and updates.¹⁹

What I could not find is a study establishing that AI has specifically collapsed administration cost. So treat that mechanism as this piece's argument plus a working specimen, not as a sourced finding. It is the claim most likely to be wrong, and it is the one I would most want falsified.

The point of the one database is not database purity. It is to stop paying epistemic rent to every vendor whenever the business needs to understand itself.

Collapse or compile: the same machinery, two postures

One clarification prevents this from being over-applied. Corporates are stuck with their SaaS and mail and collaboration and CRM for longer, because they have governance requirements and the application data is already approved. For a small business, it's a noose they don't care about.

That produces a clean strategic divergence, and it is a divergence of posture, not of architecture. The enterprise ingests from retained systems and compiles a governed worldview above them — the source systems stay canonical because inertia, governance and vendor commitments make that necessary. The small business has little to protect in those boundaries: each one is another subscription, vendor relationship, API dependency, identity plane, admin surface and extraction problem.

For enterprises, compile across the systems. For SMBs, collapse the systems into the substrate.

Interestingly, the analysts land in the same place from the other direction. Forrester's own 2026 enterprise-software prediction names data fragmentation as one of the two remaining hurdles to autonomous operation.²⁰ And McKinsey's survey work found that out of twenty-five attributes tested, the redesign of workflows had the biggest effect on whether an organisation saw earnings impact from AI at all.²¹ Fragmentation and workflow redesign are the two things this architecture is about.

Legacy is the oracle, not the target

Which leaves the transition, where most of these programmes actually die.

The incumbent system is enormously valuable — not because the replacement should copy its screens, but because it contains three assets: an explicit specification (fields, rules, workflows, reports, permissions, validation), observed behaviour (what actually happens for real inputs, including the quirks), and a shadow specification (workarounds, spreadsheets, manual exceptions, email-side decisions, and things experienced staff simply know). Their legacy system is a template for their new AI build — but the precise version of that is:

Legacy is the oracle, not the architecture.

A CRM's configuration tells you what the business previously asked that CRM to represent. Its traffic and operator behaviour tell you what the company actually relies on. Neither says its menus, objects or ceremony belong in the replacement. And the mechanism for capturing the difference is not a document — it is a test suite. Written specs are useful, but tests are the part you can't argue with at 2am; observe what the incumbent does for a given input, assert that the replacement produces the same output, and when the document and the characterisation test disagree, the test wins, because users have been relying on actual behaviour rather than documented intention.²²

So the transition is not a migration. It is progressive hollowing:

1. Attach read-only. Connect mail, website, CRM, files, payments, operations.
2. Compile the business world. Resolve identities, relationships, policies, recurring decisions, open matters, provenance.
3. Put the decision layer above the incumbents. The owner starts operating from one queue while existing systems remain the actuators.
4. Observe and extract. Capture configuration, real state transitions, exceptions, shadow workflows.
5. Build the behavioural harness. Turn incumbent behaviour into tests; separately prove safety and durability.
6. Absorb functions selectively. High-friction workflow and translation components first.
7. Move durable state only when justified. Parallel-run, reconcile, retain rollback, remove the old component only once equivalence is proven.

Each absorbed function clears three independent gates — behaviour (does it preserve or deliberately change what the incumbent did?), safety (is it secure, scoped, resistant to misuse?) and durability (can another operator change or regenerate it years from now?). And an honest note: the five-year maintenance economics of AI-generated replacements are not established. That is exactly why reversibility, retained specification and a managed operator are core product, not optional governance extras.

Which makes the most valuable artefact something other than the generated application:

That onboarding compiler may ultimately be more valuable than any individual generated application.

Part VI — The product, and the trap inside it

There is a failure mode waiting for anyone who deploys this well, and it has nothing to do with the architecture being wrong.

The moment a small business runs a system like this, it quietly stops being a SaaS consumer and becomes the owner-operator of a production software system. Someone must manage OAuth consent and token refresh, connectors and changing APIs, models and fallback routes, prompts and policies and evaluation, secrets and sensitive data, deployment and upgrades, observability and incident response, backups and tested restoration, agent authority, regression testing, security reviews, and long-term maintenance.

That is the hidden transformation, and it is the actual reason SMB AI projects fail. The failure is rarely capability: the project didn't fail because the AI wasn't good enough, it failed because the organisation wasn't ready for it.²⁶ It's all too much — the authentication, the setup, the maintenance, keeping it running, the infrastructure. It's okay for a tinkerer, but it's not really a business solution.

The answer is not to simplify the instructions and hand them to the practice owner. The answer is to make all of that product machinery, which means splitting the thing being owned from the thing being operated:

The customer owns the compiled business. The operator owns the runtime burden.

The customer-owned asset is not primarily the generated application code. It is the Business Kernel:

Business Kernel =
    ontology
  + policies and rules
  + standing intents
  + responsibilities and open loops
  + institutional memory
  + provenance and evidence
  + behavioural tests
  + authority definitions
  + action and outcome history

That kernel must be portable, inspectable, exportable, and able to survive a model change, an operator change, or regeneration of the entire application layer. Meanwhile the provider operates a standardised fleet of isolated deployments — one runtime pattern, one health and recovery model, one connector catalogue, one evaluation framework, one security posture, one upgrade factory, separate customer data and authority boundaries.

All customers share the operating factory, not the data plane. Standardise the runtime; compile the business.

The constitutional pattern, from three running systems

The consistent pattern across the specimens I operate is worth stating as a rule, because it is what stops “AI as the interface” from meaning “let the model own production”:

AI interprets intention and proposes change. Deterministic machinery owns identity, state, scope, validation, authority, execution, audit and rollback.

In Superlever, a coding agent owns repository discovery, editing and tool use, while ordinary code independently owns job and lease state, path enforcement, validation, Git integration, release promotion, production credentials, publication audit and rollback. The agent's mutable worktree is never previewed: only a committed change that passes a checked-in validator becomes an immutable staging release, and production publication transfers that exact release with health verification and automatic rollback on failure. A conventional administration surface disappeared behind conversation; the trusted release boundary did not move an inch.

In Songbird, the same seam appears in a different domain, and it is the closest thing I have to a specimen of the whole architecture. There the enduring object is an Opportunity, not an individual agent run:

The design separates bird definition, deployment, run and conversation as four distinct identities, and holds recommendation separate from authority: birds and evaluators may form findings and recommendations, but protected receipt checks, deterministic services and separately authenticated humans own the authoritative transitions. PostgreSQL owns jobs, leases, reconciliation and durable semantic state. The evidence boundary treats model output as a verification request rather than source authority — unsafe URLs, private destinations, copied-only support, ambiguous quotes and changed page bodies all fail closed.

Runs are disposable. The Opportunity is not recreated when a bird runs; new evidence attaches to it. Which generalises to exactly the claim this piece has been building:

Every important business responsibility becomes a small enduring world with an assigned custodian, not a ticket handed among stateless processors.

Two honesty notes. Songbird is an active build, not a completed portfolio operation: several parts of the intended loop remain open. And it is a venture-formation system, not a small business — it demonstrates the runtime semantics (enduring identity, disposable execution, warm continuity, durable external truth, authority outside the model, closure independent of any one session), not the SMB application of them.

Don't lead with “replace all your software”

The most credible front door is not the full thesis. “Replace all your software” sounds like a migration programme, creates justified fear, and puts the least proven part of the proposition first. The wedge is narrower:

One operating queue for every customer intent, regardless of where it arrived.

It sits above mail, website forms, CRM, phone transcripts, reviews, orders and payments, and it turns channel events into responsibilities, joins the full context, identifies the desired outcome, drafts or recommends the resolution, routes low-risk work automatically, presents material decisions with evidence, tracks each matter until the outcome is verified, and writes what it learned back into the world.

Because customer-facing actions carry consequence, it starts with observe and draft, then approval, then evidence-earned autonomy for narrow reversible actions. That is not a retreat from the vision. It is how the runtime earns authority.

And the owner-facing experience is a morning queue that reads like this:

• these five matters need your judgement;
• these twelve were handled under standing policy;
• these three are stalled because information is missing;
• this recurring failure suggests a process change;
• this SaaS module now contributes no remaining unique function.

That last line is the whole thesis arriving as a routine notification. Note also what the queue is not: it is not a record browser. The primary object is a proposal about what to do next, with its evidence attached — the human's job shifts from finder to judge.²⁷ Chat is the command line; decision navigation is the cockpit.

One positioning discipline: do not describe this as a better CRM. That immediately puts a new architecture back inside an old category, and the category is the thing being dissolved.

The decisions I have not settled

A capstone that hides its open risks is marketing. Ten decisions carry most of the remaining product risk, and they are genuinely open: the canonical kernel contract; the primary work object; the authority constitution; the onboarding compiler; the physical data architecture; the commodity boundary; customer ownership and export; the delivery model; the human experience; and the first vertical boundary.

The market's own numbers say the same thing about where the gap is. Only 11% of organisations have agents in production despite 38% piloting them — and the diagnosis offered is that “organizations are automating broken processes instead of redesigning operations”.²⁸ Gartner forecasts that more than 40% of agentic projects will be cancelled by the end of 2027 on cost, unclear value or inadequate risk controls, notes that only about 130 of thousands of self-described agentic vendors are real, and then concedes the architectural point directly: integrating agents into legacy systems “can be technically complex, often disrupting workflows… In many cases, rethinking workflows with agentic AI from the ground up is the ideal path”.²⁹

Most tellingly, when Deloitte surveyed 3,235 IT and business leaders across 24 countries, only 21% reported a mature governance model for agentic AI — and the specific capabilities the other ~80% lacked were “clear boundaries for agents that define which decisions they can make independently versus which require human approval, real-time monitoring systems that track agent behavior and flag anomalies, and audit trails that capture the full chain of agent actions”.³⁰

Read that list again. Bounded authority, observation, and outcome closure — three of the six primitives, described by a major consultancy as a market-wide capability gap. Meanwhile 95% of generative AI pilots were reported as falling short, with the core issue named as a learning gap rather than model quality,³¹ and 56% of CEOs reported neither increased revenue nor decreased costs from AI over twelve months.³²

Those are not arguments that AI does not work. They are the signature of an industry connecting intelligence to applications while leaving custody exactly where it was.

The doctrine, compressed

What the firm becomes, if this is right, is not a collection of applications with AI attached. It is:

One continuously compiled world, containing a set of open responsibilities, each held by an agent under an intent until the world reaches an acceptable outcome.

Which compresses to five lines worth keeping:

• One business, one world model, one authority plane, many rails.
• Channel is metadata. The case is the work.
• Own the mission layer. Rent the operational depth.
• Legacy is the oracle and the tuition, not the target architecture.
• Intent is the invariant. Responsibility is the persistence. Gold is the orientation. Authority is the boundary. Outcome is the closer.

And then the test, which needs none of the vocabulary above:

Does the AI make the manager's world easier — or merely explain why it has become the manager's problem?

Almost everything shipping in 2026 fails that test, not because the models are weak but because the architecture hands responsibility back at the end of every turn. Fix the custody and the applications lose their reason to exist as places people go. Leave the custody where it is, and you can connect every system you own and still be the integration layer of your own company.