IN BRIEF
The debate about whether AI will reshape software is usually framed as a contest of model quality: better models make better features. That framing hides the real change. The decisive difference between an Al-first platform and a legacy platform with Al bolted on is not how good the model is. It is a question about who, or what, sits at the center of the system and decides what happens next.
Classical SaaS was built around a human orchestrator. The software is a deterministic instrument that waits to be operated. Al-first systems move the orchestration function out of the human’s head and into a model-driven core. That one relocation looks small on a slide but is structural in practice. It changes which component is load-bearing, what the other layers are for, and ultimately where the defensibility of the business lives. You cannot reach the new architecture by adding a panel to the old one — which is exactly what “bolt-on Al” tries to do. Bolt-on Al asks a model to assist the operator. Al-first asks the model to be the orchestrator — and rebuilds the stack around that fact.
This paper walks the architectures on the ladder — classical SaaS, the bolt-on copilot, the orchestration bolt-on, and Al-first — shows precisely where they diverge, and then makes the harder argument: where this is true, where it is overstated, and what an incumbent who owns a legacy platform should actually do about it. Two ideas carry the whole argument: a probabilistic planner mounted on a deterministic actuator, and a trust layer that keeps the human in the loop by design.
01 — THE ARCHITECTURE WE INHERITED
The human was always the orchestrator
Almost every SaaS product of the last twenty years is a variation on the same three-tier shape. A data layer holds the system of record. An application layer encodes the domain — its rules, validations, permissions, and workflows — as deterministic operations. A presentation layer exposes those operations to a person through a point-and-click interface. The person decides what to do; the software does exactly, and only, what it is told.
This is not a flaw. It is a deliberate division of labor in which the intelligence and the agency live in the user, and the software supplies reliability, memory, and scale. The roadmap of a classical SaaS product is therefore a roadmap of verbs the user can invoke and screens that make those verbs easier to reach. The application is dumb on purpose, because a dumb instrument is a predictable one.
One distinction will matter for the rest of this paper. The human at the top of this stack is playing two roles at once: orchestrator — the holder of the goal, the one who decides what happens next — and operator — the one who works the instrument, click by click, to make it happen. Legacy SaaS fuses the two roles into one person. The inversion that follows is precisely their separation.
02 — THE BOLT-ON PATTERN
A copilot is still a passenger
When Al arrives at a legacy platform, it almost always arrives as an addition to the side of this stack. Two shapes dominate. The first is the copilot: a chat or suggestion panel beside the existing UI that drafts, summarizes, and recommends. The second is the embedded feature: a discrete model wired into one screen — a send-time predictor, a subject-line generator, a lead score — rendering its output where a person can see it.
Both are genuinely useful, and both share a ceiling that is architectural rather than temporary. The model advises; the human still orchestrates. The person remains the component that holds the goal, sequences the steps, and presses the buttons. You have made the operator faster. You have not changed who the orchestrator is.
FOR EXAMPLE — THE COPILOT YOU ALREADY USE
The "summarize this thread" and "draft a reply" panels now bolted into email clients and CRMs are real time-savers — but you still choose which thread to open, when to summarize, and whether to send. Github Copilot in its first form did the same thing inside your keystrokes: It suggested the next line while you typed, and you stayed in the driver's seat. The assistant rides along; the human still drives.
There is a second, quieter limit. An agent bolted to a legacy platform can only reach the system through whatever surface that platform already exposes — and those surfaces were drawn for humans. The interface reveals a subset of what is possible against the data; the public API typically reveals a subset of that. So the Al acts through a doubly-restricted aperture, able to touch only the innermost ring.
FOR EXAMPLE — THE KEYHOLE
Many CRMs let a person run a multi-step approval, merge, or deduplication wizard from the UI that the public API simply never exposes. An agent wired to that API can read and edit records but cannot trigger the very workflow that does the valuable work — it is looking at the system through a keyhole the vendor cut for integrations, not for autonomy.
This is why bolt-on improvements tend to plateau. Each added feature shaves time off a step a human still has to initiate and supervise. The compounding gains — a system that pursues a goal across dozens of steps without a person in the loop for each one — are unreachable from this shape, because the shape assumes a human operator in the loop for every step by construction.
03 — HALFWAY THERE
The orchestration bolt-on: many agents, many walled gardens
There is a more ambitious bolt-on emerging between the copilot and the full inversion, and it deserves its own rung on the ladder. Instead of one assistant inside one product, an orchestration layer sits above several platforms at once, dispatching agents into each through whatever APIs and integration protocols the vendors offer. A goal arrives — “run the year-end campaign” — and the orchestrator decomposes it across the CRM, the email platform, the payment system, the analytics tool.
The deeper limit is ownership. The orchestrator is renting its execution layer. It cannot redesign the tool it calls, cannot widen a keyhole, cannot add the preview, the dry-run, or the audit trail a machine actor needs. It’s ceiling is set by the narrowest aperture it must pass through. The difference between this architecture and the true inversion is not the shape of the diagram — it is who owns the tool contracts.
In shape, this is close to Al-first: a core holds a goal and composes work across tools. It is often genuinely the best available architecture when the work spans vendors nobody controls. But it inherits the keyhole problem of Figure 2 — multiplied. Every action must pass through some vendor’s API aperture, so the orchestrator can only compose what each platform deigns to expose. There is no shared state across the gardens, no transaction that spans them cleanly, and as many different permission models as there are vendors — each designed for integrations, not autonomy. When a job fails halfway across three systems, no single component owns the recovery.
04 — AI-FIRST ARCHITECTURE
Put the intelligence at the center, demote everything else to tools
The Al-first move is to relocate the orchestration function from the human into the system. A model-driven core now holds the goal, the context, and the working memory. It perceives the current state, plans, chooses an action, executes it, observes the result, and loops, — the same orchestrator role the human played in Figure 1. And it is not simply stuffed inside the old stack: the core sits at the center and wraps around the execution layer, directing it from above rather than living within any one screen of it. That is the novelty — and, unlike the orchestration bolt-on, this core owns the tools it directs.
Once the core is the orchestrator, the old application layer changes meaning. It stops being “the product the user operates” and becomes a library of well-defined, composable tools the core actuates — each an explicit action with stated inputs and outputs, permissions designed for a machine actor, operations that are safe to run twice, and an audit trail. The interface does not disappear; it is demoted to one surface among several: a place where a human supervises, sets intent, approves consequential actions, and reviews what happened. The person moves from operator to principal.
FOR EXAMPLE — A CODING AGENT
This is exactly how a coding agent such as Claude Code works. The model holds the goal ("add OAuth login and the tests") and drives a handful of commodity tools — read file, edit file, run shell, run tests — in a loop, reading each result and correcting course. The editor stops being where the work happens and becomes where a human watches, steers, and approves. File edits and terminal commands that have existed for decades are now end-effectors the intelligence actuates.
FOR EXAMPLE — IN FUNDRAISING
The bolt-on version suggests a sharper subject line inside the campaign you already built by hand. The AI-first version takes the goal — "re-engages the donors who lapsed this year" — and composes the work itself: pull the lapsed segment, draft messages matched to each supporter's history, schedule the sends, watch what comes back, and adjust. The fundraiser sets the intent and approves; the system does the sequencing a person used to click through.
This is not "less reliable software"
A fair objection: classical SaaS is dumb but deterministic, and determinism is a feature in domains like donor data, payments, and compliance. Replacing it with a probabilistic core sounds like trading reliability for cleverness. The well-built AI-first system does not make that trade. It keeps determinism exactly where it always lived — in the execution layer — and wraps the probabilistic core in deterministic guardrails: explicit contracts, permission checks, dry-runs and previews, approval gates for consequential actions, and verification of outcomes. Reliability becomes an architecture, not an accident of dumbness.
A probabilistic planner mounted on a deterministic actuator, with checking in between: that is the whole trick.
FOR EXAMPLE — THE APPROVAL GATE HOLDS
An agent can plan a $40,000 vendor payment, gather the supporting evidence, and present it for sign-off — but the transfer itself still runs through the same deterministic permission check and human approval gate it always did. The planner is probabilistic; the actuator is not, and nothing consequential executes without passing the gate.
The trust layer: the human stays in the loop
Say it plainly, because everything above depends on it: the human stays in the loop. The inversion relocates the orchestration function to the machine; it deliberately does not relocate the trust function. Judgment about what the organization is willing to do — which actions are consequential, what gets previewed, what requires a signature, what gets rolled back — remains human, and the architecture must treat that as a first-class layer, not a settings page.
This reframes what the interface is for. In legacy SaaS, the UI is where the work happens. In an Al-first system, the UI’s primary job is to be the trust layer: the surface where a principal states intent, watches plan before they run, approves the consequential ones, and audits what happened and why. It is the first thing a person should meet when they open an Al-first platform — not a dashboard of verbs, but evidence that the system deserves the delegation it is asking for. Orchestration and trust are two halves of one design: every increment of autonomy the core takes on must be matched by an increment of legibility the trust layer gives back.
05 — CONSEQUENCES
When the tools commoditize, defensibility moves
Here is the strategic edge of the inversion, In the classical model, much of a product’s defensibility lived in the presentation and application layers: the elegance of the UI, the depth of encoded workflows, the accumulated thousand small conveniences a competitor would have to re-implement. Those were the moat.
When an orchestrating core can compose goals out of generic tools, those layers commoditize toward the price of building them — which, with Al assistance, is falling fast, The moat does not vanish. It migrates: to proprietary data and the feedback loops that improve the core’s judgment over time; to the quality of the orchestration itself for a specific domain — its evaluations, guardrails, and domain models; and to trust, reliability, and accountability for outcomes.
FOR EXAMPLE — COPILOT'S OWN ARC
The boilerplate a developer once hand-wrote — and a UI-builder once charged for — is now generated on demand. Github Copilot's own history is the lesson in miniature: it began as autocomplete bolted onto the editor, and the whole category moved toward agents that drive the entire repository. The keystroke-saving turned out to be the commodity; the orchestration became the product.
06 — THE HONEST COUNTER-CASE
Where the bolt-on crowd is right
Three counter-arguments deserve real weight, and each narrows the claim usefully.
The application layer does not commoditize to zero. An agent calling sloppy tools produces sloppy outcomes at speed. Correctness, permissions, transactional integrity, and compliance still live in that layer — and as it becomes a machine-callable contract rather than a forgiving human UI, those properties get harder, and more important, not less. “Commoditized” means “no longer your differentiator,” not “trivial.” Someone still has to build it extremely well.
Data gravity favors the incumbent. If the moat migrates to proprietary data and feedback loops, the company that already owns the system of record starts with the asset a challenger has to spend years acquiring. An incumbent who re-platforms toward an agentic core can, in principle, out-execute a greenfield startup — provided it treats the rebuild as a first-class product, not a side project. The threat to incumbents is rarely the technology; it is the temptation to ship a copilot and call it a strategy.
Not every workflow should be agentic. Plenty of tasks are genuinely better as a fast, deterministic click: high-frequency, low-judgment, latency-sensitive operations where an agent loop is slower, costlier, and riskier than a button. Al-first is an operating model to apply where judgment, composition across many steps, and autonomy create value — not a mandate to route everything through a model.
THE SYNTHESIS
The sharpest version of the thesis is narrow and therefore durable: relocating the orchestration function from human to machine — while keeping the trust function with the human — forces a different architecture, because the substrate's foundational assumption, that the actor and the accountable party are the same person, no longer holds. You cannot reach that architecture by appending a panel, and where it applies, it moves the moat off the layers a legacy vendor was counting on.
It does not follow that determinism is obsolete, that incumbents are doomed, or that everything becomes an agent. It follows that the center of the system changes, and a great deal else has to be rebuilt around the new center.
07 — IMPLICATIONS
What to do about it
The framework cuts differently depending on where you stand. For a builder starting fresh, the discipline is to design the actor as a machine from day one — well-defined tools, machine permissions, audit and verification, and a UI conceived as a trust layer rather than the product. For an incumbent sitting on a real system of record, the move is more interesting, and it is neither “bolt on a copilot” nor “rebuild from scratch”:
- Treat your application layer as a tool library, not a finished product.
Re-express your core operations as well-defined, permissioned, machine-callable actions with contracts and logs. This is the unglamorous foundation everything else stands on. - Build the agentic core as a first-class surface.
Give it its own roadmap, evals, and guardrails — not a panel grafted onto an existing screen. The core is the new product; the UI is one window onto it. - Turn your data gravity into a flywheel before a challenger does.
Instrument outcomes so every action the core takes makes the next one better. This is the moat the inversion hands to whoever moves first — and incumbents start with the data. - Keep determinism where it pays.
Leave fast, low-judgment workflows as deterministic clicks. Reserve the agentic core for goals that span many steps and require judgment, where autonomy compounds. - Design the trust layer as deliberately as the core.
Previews, approval gates, and a legible audit trail are what let a principal delegate more over time. Autonomy is earned through legibility — the trust layer is where adoption is won or lost.
IN CLOSING
A different machine
Bolt-on Al and Al-first are not two points on a quality spectrum. They are two machines with different load-bearing components. One keeps the human at the center of every step and makes the human faster. The other moves the orchestration into the system, keeps trust with the human, and rebuilds the stack so the person can step up from operator to principal. The first is a worthwhile improvement to the world we have. The second is the world a lot of software is about to be rebuilt for — and the rebuild starts not with a better model, but with a decision about who sits at the center, and who signs off.
Why moving the orchestration layer into the software — and keeping trust with the human — changes everything
The debate about whether AI will reshape software is usually framed as a contest of model quality: better models make better features. That framing hides the real change. The decisive difference between an AI-first platform and a legacy platform with AI bolted on is not how good the model is. It is a question about who, or what, sits at the center of the system and decides what happens next.
Classical SaaS was built around a human orchestrator. The software is a deterministic instrument that waits to be operated. AI-first systems move the orchestration function out of the human’s head and into a model-driven core.
Bolt-on AI asks a model to assist the operator. AI-first asks the model to be the orchestrator — and rebuilds the stack around that fact.
The Human Was Always the Orchestrator
The person decides what to do; the software does exactly, and only, what it is told.
This is not a flaw. It is a deliberate division of labor in which the intelligence and the agency live in the user, and the software supplies reliability, memory, and scale.
The human at the top of this stack is playing two roles at once: orchestrator — the holder of the goal, the one who decides what happens next — and operator — the one who works the instrument, click by click, to make it happen.
The inversion that follows is precisely their separation.
The Next Architecture
The AI-first move is to relocate the orchestration function from the human into the system. A model-driven core now holds the goal, the context, and the working memory. It perceives the current state, plans, chooses an action, executes it, observes the result, and loops.
The interface does not disappear; it is demoted to one surface among several: a place where a human supervises, sets intent, approves consequential actions, and reviews what happened.
The person moves from operator to principal.
This Is Not “Less Reliable Software”
The well-built AI-first system does not make that trade. It keeps determinism exactly where it always lived — in the execution layer — and wraps the probabilistic core in deterministic guardrails: explicit contracts, permission checks, dry-runs and previews, approval gates for consequential actions, and verification of outcomes.
Reliability becomes an architecture, not an accident of dumbness.
A probabilistic planner mounted on a deterministic actuator, with checking in between: that is the whole trick.
The Trust Layer: The Human Stays in the Loop
Say it plainly, because everything above depends on it: the human stays in the loop.
The inversion relocates the orchestration function to the machine; it deliberately does not relocate the trust function. Judgment about what the organization is willing to do — which actions are consequential, what gets previewed, what requires a signature, what gets rolled back — remains human.
Orchestration and trust are two halves of one design: every increment of autonomy the core takes on must be matched by an increment of legibility the trust layer gives back.
A Different Machine
Bolt-on AI and AI-first are not two points on a quality spectrum. They are two machines with different load-bearing components.
One keeps the human at the center of every step and makes the human faster. The other moves the orchestration into the system, keeps trust with the human, and rebuilds the stack so the person can step up from operator to principal.
The rebuild starts not with a better model, but with a decision about who sits at the center, and who signs off.
Dowload and read the full report
Download the full paper
12 pages
Want to read more like this?
Be the first to know about new features, fundraising tips, and what’s next for Escalator.
