SaaS
Work Systems Are Eating SaaS
Software ate the world. Now work systems are eating SaaS. The unbundling era is ending — and the rebundling is happening around execution, not features.
In 2011 Marc Andreessen wrote that software was eating the world, and he was describing a process of substitution: industries that ran on atoms — bookstores, taxis, film studios — were being replaced by industries that ran on code. The thesis was about what the world ran on. It said nothing about the shape that software itself would take. We all assumed, without quite saying it, that the software eating the world would keep arriving the way it always had: one tool at a time, each solving one problem, each sold separately.
That assumption is the thing that's now expiring. The next sentence in the story isn't about software eating more of the world. It's about a particular shape of software eating the shape that came before it. Work systems are eating SaaS.
I want to be precise about what that claim means, because it is easy to hear it as a complaint about having too many apps, and it is not that. We are not about to tell you that your tool stack is bloated and you should consolidate. The number of tools is not the problem and never was. The thesis is narrower and stranger: the organizing principle of an entire software era — unbundle the suite, build the best single feature, win one category — has quietly run out of road. And the thing replacing it isn't a better feature or a bigger suite. It's a different layer of the stack entirely.
The pendulum that everyone forgot was a pendulum
Software has always swung between bundling and unbundling. In the 1990s the suite won: Microsoft Office bundled the word processor, the spreadsheet, and the presentation tool into one box, and the bundle beat the standalone WordPerfects and Lotuses of the world because buying one thing was easier than buying five.
Then the web arrived and the pendulum reversed. Distribution got cheap. A team of four could build one excellent thing and put it in front of a million people without a sales force. So they did, and the suite shattered into a thousand glittering pieces. The project tracker became its own company. So did the wiki, the chat client, the design canvas, the form builder, the scheduler, the analytics dashboard. Each piece was genuinely better at its one job than the corresponding module in the old suite had been. This was not a mistake. The unbundling was correct. A focused team building one tool will out-execute a giant building forty, every time, on that one tool.
The unbundling era gave us the best individual tools software has ever produced. And then it gave us the bill.
The bill is not the subscriptions. The bill is that work isn't individual, and we built every tool as if it were. A real piece of work — ship the feature, close the client, run the campaign — does not live in one tool. It lives across them. The decision happens in chat, the spec lands in a doc, the tasks sit on a board, the deadline lives on a calendar, the client conversation runs through mail. Each tool holds a perfect, polished slice of the work and is structurally blind to every other slice. The connective tissue — the part that makes a slice into a project — exists nowhere in the software. It lives in the heads of the people, in the messages between the tools, in the meetings whose entire purpose is to re-stitch the slices back together.
So we did something absurd, and we did it for fifteen years without naming it: we made human beings the integration layer.
Why the pendulum had to swing back
Every previous bundling was driven by economics. The suite won in the 1990s because buying was expensive — procurement, installation, training, support contracts — and one purchase amortized that cost across five tools. The unbundling won in the 2010s because distribution got cheap — the web meant a focused team could reach the world without a sales force, so the economics that had favored the bundle inverted, and the suite shattered. In both cases the pendulum moved because the cost of the thing being bundled changed. Bundling and unbundling have never been about taste. They're about which cost is currently dominant.
So the honest question is: what cost is dominant now? It isn't the cost of buying tools — that's near zero, you can sign up for forty things this afternoon on a credit card. It isn't the cost of building them — that's never been lower. The dominant cost, the one that has quietly grown to dwarf the others, is the cost of making the tools act as one piece of work. It's the coordination cost. It's the human hours spent being the wire between the slices: the status meeting, the copy-paste from chat into the tracker, the "did legal sign off?" ping, the Monday-morning archaeology across five dashboards to answer one question. That cost didn't exist in the suite era because the slices were few. It exploded in the unbundling era because the slices multiplied and nothing connected them but people.
And here is the structural reason it's a pendulum and not a one-way door: the unbundling, by being successful, created the exact cost that now demands a rebundling. The better and more numerous the individual tools became, the more expensive it became to make them cohere. Success at the slice level manufactured a crisis at the whole level. That's why this isn't a story about anyone doing the unbundling wrong. They did it right, and doing it right is precisely what raised the new dominant cost and cocked the pendulum to swing back.
But — and this is the entire point of the essay — the cost that's now dominant is coordination, and you cannot rebundle coordination by rebundling the tools. Putting five tools under one login does nothing to the coordination cost, because coordination doesn't live inside any tool. It lives in the space between them. To attack it you have to bundle the space between the tools, which is a different object than the tools themselves. That object has a name now. It's the work-graph, and the layer that holds it is the work system.
The integration layer is the intelligence layer
Here is the sentence the whole essay turns on, so I'll set it apart: the integration layer is the intelligence layer.
Everyone treated integration as plumbing — a boring, low-status problem to be solved with a webhook and forgotten. You connect the chat tool to the task tool so that a message can spawn a card. Fine. But that's not integration, that's a pipe. It moves a payload from A to B. It does not understand that the message and the card and the calendar event and the client thread are all the same piece of work seen from four angles. It has no model of the work. It has a model of the message.
Real integration — the kind that would actually retire the coordination tax — requires something the pipe doesn't have: a model of the work itself. It has to know that this design feeds that ticket, that this contract gates that kickoff, that this person is waiting on that approval, that "the Northbeam launch" is a single living thing with a state, even though its body is scattered across eleven applications. The moment a system holds that model, integration stops being plumbing and becomes cognition. The map of how everything connects is not a side effect of intelligence. It is the intelligence. There is nothing else for an intelligent work system to be.
This is why the work-system layer eats SaaS and not the other way around. A SaaS tool, by its nature, owns one slice and reasons about that slice. It cannot reason about the whole, because it cannot see the whole — and not for lack of trying. It's an architectural ceiling, not a feature gap. You can bolt the smartest model in the world onto a project tracker and it will still be a brilliant project tracker that goes blind at its own edges. The intelligence that matters lives in the connections, and the connections live above every individual tool, in a layer that, until recently, didn't exist as a product category at all.
Emit versus infer: the load-bearing distinction
If the intelligence is in the connections, the only question that matters is: how does a system come to know the connections? And there are exactly two answers, which produce two completely different kinds of product.
The first answer is infer. You sit a system above the existing tools and have it guess the connections from the outside — read the chat logs, scan the docs, watch the API traffic, and statistically reconstruct what's related to what. This is the architecture of every "AI layer over your stack" you've seen. It is genuinely useful and it has a hard ceiling, because inference is reconstruction, and reconstruction is lossy. The system is forever rebuilding a model of the work from its shadows on the walls of the tools. It can read the graph it infers. It usually cannot write back into the tools with authority, because it doesn't own them — it's a guest reading their logs, and a guest doesn't get the keys.
The second answer is emit. Instead of inferring the connections from outside, you have every tool declare what just happened, the instant it happens, into one shared structure. The task moves and the task app emits that. The doc is signed off and the docs app emits that. The event is booked and the calendar emits that. Nobody reconstructs anything, because nothing was ever lost: the graph of the work is assembled from first-party truth, in real time, by the tools that actually did the thing. And because the same system owns those tools, it doesn't just read the graph. It can write — draft the handoff, flag the blocker, line up the review — back into the very surfaces the work lives on.
This is the whole game, and it's why "AI over your stack" and "AI-native work system" are not two points on a spectrum but two different species. One infers a map and reads it. The other emits the territory and can act on it. The difference compounds with every event, every day, forever — because the emitted graph is correct by construction and the inferred one is a guess that decays the moment you stop staring at it.
There's a rule we hold ourselves to internally that makes this concrete: every app mutation must emit a signal, or it's invisible to the brain. A feature that ships without an emit didn't ship — not for the work system. It shipped a slice and threw away the connection, which is the only part that was ever worth anything. That sounds like an engineering constraint and it is, but it's really the architectural commitment of the entire thesis written as a single sentence. The connections are the product. So you don't let the connections be a thing you guess. You make them a thing you record.
Consider what each architecture can honestly promise on the day a project goes sideways. The infer-from-outside system, asked "is the launch at risk?", produces a confident-sounding answer assembled from whatever it managed to read — and you have no way to know what it missed, because a guess doesn't come with a list of what it couldn't see. The blind spots are silent. The emit-the-graph system answers from a record of things that actually happened, each one first-party, each one timestamped by the tool that did it, and when it doesn't know something it can tell you it doesn't know, because the absence of an emit is itself information. One system hallucinates with confidence. The other can abstain with honesty. That difference — confident reconstruction versus grounded recall — is not a tuning parameter. It's the whole reason the work-graph is a moat and the inferred index is a feature.
There's a second, slower consequence that matters even more over time. An inferred graph is rebuilt fresh each time you ask, from whatever the tools currently expose; it has no memory of its own, only the tools' current state. An emitted graph accumulates. Every signal it records is a permanent fact about how this team's work actually flowed — which handoffs always stall, which approvals always run late, what "done" has historically meant for this client. That history is the part nobody can copy, because it isn't a model anyone can train on someone else's data; it's your organization's execution, written down as it happened. The unbundled tools each kept a perfect record of their own slice and threw the connections away nightly. The work system keeps the connections, and the connections, compounded over months, become the only genuinely defensible asset in the entire stack.
What rebundling around execution actually looks like
Let me make this physical, because "rebundling around execution" can sound like an abstraction and it isn't one.
Picture the unbundled version of a Monday morning. The launch is in nine days. To know where it stands, someone — usually your most expensive someone — opens the task board, then the docs to check the spec is approved, then chat to see if legal weighed in, then the calendar to confirm the review is actually booked, then mail to see if the client replied. Five tools, five slices, and the only place they add up to "the launch is on track" or "the launch is at risk" is inside that one person's tired head, reassembled by hand, and gone again by lunch. The board says the cards are done. The board always lies, because the board can only see cards.
Now picture the rebundled version. The same launch, but every one of those tools has been emitting into one work-graph the whole time. The brain doesn't reassemble the picture on Monday; the picture was never disassembled. It already knows the spec is approved, the legal thread stalled on Thursday, the review isn't on anyone's calendar, and the client hasn't replied since the 18th. So the morning doesn't start with a person doing five-tool archaeology. It starts with the brain saying, in effect: three things need you, two I already handled. The handoff to legal — I drafted it, here it is for one click. The review slot — booked, pending your nod. The client follow-up, the stalled approval, the scope question the spec quietly raised — those need a human, and here they are, with the context already attached.
Notice what did not happen. We did not replace the task board, the docs, the calendar, the chat, or the mail. They're all still there, each still the best at its one job, each still the surface a human touches. The rebundling didn't happen at the feature layer — nobody crammed eleven tools into one mediocre tool. It happened at the execution layer, in the graph above them and the brain that reads across it. The tools stayed unbundled. The work got rebundled. That's the move, and it's the move only a system that emits the graph and owns the write-path can make.
It's worth dwelling on the act half of that, because reading the graph is the easy part and almost everyone stops there. A system that can see the whole launch but can only show you a dashboard has handed the work back to you — better-informed, but still yours to do. The leap is when the system can move inside the surfaces: draft the legal follow-up in mail, hold the review slot on the calendar, open the scope question as a card on the board. That requires the right to write, not just the right to read, and the right to write is exactly what an outside-in system doesn't have — it's reading the tools' logs through a keyhole, and a keyhole doesn't let you reach in and act. The work system can act because it owns the surfaces it reads. But ownership of the write-path is also where the trust question gets sharp, and the honest answer is a reflex, not a leap of faith: suggest, confirm, execute. The brain proposes the handoff and shows you the draft; you click; it acts. It never quietly does the irreversible thing on your behalf. That's not a limitation bolted on to calm nervous buyers — it's the correct shape for a system that acts inside your real work. You stay in command without staying in the loop, which is the only version of "the system handles it" that an operator should ever accept.
This is also why the answer is not the all-in-one suite making its comeback. The suite rebundles the features — it gives you a worse task tool and a worse doc tool under one login and calls the shared login "integration." But a shared login is not a shared brain. Forty modules behind one bill are still forty silos; you've bundled the procurement and left the work exactly as fragmented as before. The suite is the old answer to the old question. The work system is a new answer to a question the suite never asked: not how do we sell these together but how do we make them think together.
The honest shape of the claim
I want to keep this checkable, because the thesis is strong enough that it doesn't need to be dressed up, and dressing it up would be the surest way to make it false.
So: this is not a prediction that SaaS tools die. They don't. People will keep using a great spreadsheet and a great chat client and a great design canvas for the same reason they always did — focused tools are good. The claim is about where the value migrates, not where the tools go. In the unbundled era, the value lived in the tool, because the tool was the most intelligent thing in the picture. In the rebundled era, the value lives in the layer that holds the work-graph and reasons across it, and the individual tool becomes something closer to an organ: essential, irreplaceable at its job, and not, by itself, the seat of the intelligence. One organism, many faces. The hands and the senses stay specialized. The mind is new, and it's one.
And it's worth saying plainly what this layer is not yet. It is early. Owning the write-path — the right to act inside the tools, not just read them — is the hard, durable part, and it is exactly the part that takes years to earn surface by surface. A system that emits its own graph and acts on its own surfaces has a different ceiling than one that infers from the outside, but a higher ceiling is a destination, not a finished building. The honest version of this thesis is not "the work system has won." It's "the unbundling era is over, the rebundling has started, and it's happening at the execution layer — and that is the layer that has barely been built." The interesting position is not the one that's finished. It's the one that's correct and early.
What this means if it's true
If work systems are eating SaaS, a few things follow that are uncomfortable for the way most of the industry is currently organized.
It means that building the best individual tool is no longer the road to the most valuable position, the way it was for fifteen years. The best tool is now a great way to own one organ. The valuable position is the brain, and you cannot reach the brain by being the best at one slice, because the brain is defined by reading across all of them.
It means that "we added AI" is, for a single-slice tool, a category error worn as an upgrade. Bolting a model onto one slice makes a smarter slice. It does not make a work system, because the model still can't see past the edge of its tool, and the intelligence was never inside the tool. It was always in the connections the tool can't see. A copilot inside a project tracker can write you a better description of a card. It cannot tell you the card is blocked because a contract two tools away hasn't cleared, because the contract was never in its world. The smartest model in the world, given a slice, returns a smarter slice. The graph is the only thing that turns a slice into an answer, and the graph lives one layer up.
It means, too, that the unit of competition changes shape. For fifteen years tools competed on features — more views, more fields, more automations, a nicer canvas — because the tool was the product and features were how tools got better. In a world where the brain is the product, features become table stakes for being a good organ, and the competition moves up a level, to a place most of the incumbents can't easily follow: who holds the most complete, most first-party, longest-accumulated graph of how a given team actually executes. You cannot win that race by adding a view. You win it by emitting cleanly and owning the surfaces for long enough that your record of the work becomes the truest record that exists. That's a slower race and a deeper one, and it explains why "we added AI to our tool" feels like motion but isn't progress toward the prize — it's running faster in the old race while the new one started somewhere else.
And it means the boring, low-status integration problem was the whole prize the entire time, and almost everyone built around it instead of at it — webhooks and Zapier zaps and "connect your apps," all of them moving payloads between silos while leaving the silos intact. They automated the pipes and never built the map. The map was the thing. The integration layer is the intelligence layer, and the era that's beginning belongs to whoever treats it that way — not as plumbing under the product, but as the product.
Software ate the world by being faster, cheaper, and more general than what it replaced. Work systems are eating SaaS for a narrower and sharper reason: they hold the one thing every individual tool was built to be blind to — the connections — and the connections were always where the work actually lived.
So here is the question to sit with, the one that decides which side of the pendulum you're standing on. When you look at your own stack tomorrow morning, ask not how many tools you have — that was never the question — but this: where does the picture of your work actually live? If the answer is "in my best person's head, rebuilt by hand every Monday," then you don't have a work system yet. You have eleven slices and a human doing the integration. And the human, it turns out, was always the most expensive integration layer ever built.
---
Watch: how the work-graph assembles itself
WORKELATE · ON YOUTUBE Emit vs. infer — watching one brain read across eleven apps---
Keep reading
Keep reading
