Automation Thesis

The last app you install is the one that installs the rest

Stop installing forty tools and wiring them together. Describe the job out loud and let the operating system assemble the capability, app-as-noun gives way to capability-as-verb.

ASR

Apollo Space Research

Apollo Space

· 11 min read

Open the settings page of almost any small company and count the logos. The CRM. The two it half-migrated off. The email tool, the other email tool sales prefers, the scheduler, the e-signature app, the form builder, the data warehouse nobody remembers signing up for. Forty tabs of subscriptions, and not one of them knows the other thirty-nine exist.

You didn’t choose forty apps. You chose forty jobs, and the only way to get each job done was to go find the app shaped like it, install it, learn it, and then wire it by hand to the ones next to it. The app was never the thing you wanted. It was the toll you paid to reach the thing you wanted.

So here is the shift this whole post is about. The last app you install is the one that installs the rest, because once the operating system can assemble a capability from a description, you stop shopping for nouns and start asking for verbs.

The naive way: an app is a noun you go shopping for

The way we’ve bought software for forty years has a grammar, and the grammar is the problem.

You feel a need, I need to stop losing track of who I’ve emailed. Then you translate that need into a noun: a CRM. You go shopping for the noun. You compare five of them, pick one, pay, onboard, import, configure, and finally, weeks later, you’re allowed to do the original verb: track who I’ve emailed. The need was a verb. The market only sold you nouns.

That detour is invisible because we’ve all internalized it. But look at what it costs. Every noun you buy arrives as an island. The CRM doesn’t know what’s in the inbox. The inbox doesn’t know what’s in the calendar. The calendar doesn’t know the contract renews Friday. So you, the human, become the integration layer, the only component in your whole stack that can see all forty islands at once. You copy a name from the email into the CRM. You paste a date from the contract into the calendar. You are the cable nobody shipped.

And the cost compounds in three directions at once:

  • Discovery. Every new need means re-entering the store: search, compare, trial, decide. The job waits while you shop.
  • Assembly. Each app you add has to be hand-wired to the ones it touches, by you, in a configuration screen, forever.
  • Decay. The wiring you built last quarter rots quietly the moment one app changes a field, and nobody notices until the report comes out wrong.

The bottleneck was never that we lacked apps. We have too many. The bottleneck is that the unit of software is the app, a noun you install, and a noun can’t compose itself into the verb you actually needed. You compose it. By hand. On your weakest morning.

The reframe: ask for the verb, let the OS assemble the noun

Here’s the key idea, and it’s simpler than it sounds. The last app you install is the one that installs the rest, because the right unit of software was never the app. It was the job.

Watch the grammar flip. In the old world you say “I need a CRM” and then spend three weeks earning the right to track a customer. In the new world you say “track everyone I’ve spoken to this month and tell me who’s gone quiet,” and the system goes and assembles whatever it takes to do that, reading the inbox, the calendar, the call notes, and hands you the answer. You didn’t install a CRM. You described a verb, and the capability appeared.

The difference is who does the assembly. When the unit is an app, you assemble. When the unit is a capability, the operating system assembles. You stopped being the cable.

This is what an operating system has always done, by the way. Nobody “installs” the ability to save a file. You don’t shop for a copy-paste app. The OS exposes those as capabilities, and every program on the machine composes them without asking you to wire anything. We just never had that layer for company work, for sending the follow-up, scoring the pipeline, watching the renewal. Each of those got sold to us as a separate noun, because there was no operating system underneath to assemble them from a description. Now there can be.

Two grammars for getting work done. On the left, the human is the integration layer: a need becomes a noun, you shop for an app, install it, then hand-wire it to the inbox, the calendar, and the CRM, and you copy data between them yourself. On the right, you state the verb to the operating system, and it reaches into the same sources and assembles the capability, with the human out of the cabling.

The honest version of this isn’t magic, and it shouldn’t pretend to be. The OS isn’t conjuring features from nothing. It’s reaching into the same data your forty apps were each holding a slice of, plus the tools it can already call, and composing them on demand into the shape of your request. The capability was always latent in your data and your connections. What was missing was something that could read a sentence and assemble the latent thing into a finished one. That’s the job the operating system takes over.

Why the app store can’t survive its own success

The reflex objection is fair: an app store is good. It’s discovery, it’s choice, it’s a million developers. Why would you want less of that?

You don’t want less software. You want to stop being the software. And the store, by its very shape, forces you to be.

Think about what the store optimizes for. It optimizes for the app being a standalone, sellable unit, something you can find, pay for, and install on its own. That’s a great property for a marketplace and a terrible property for getting a job done, because real jobs cross app boundaries. “Onboard a new customer” isn’t a CRM job or an email job or a calendar job. It’s all three plus a contract plus a reminder. The store has no shelf for “onboard a new customer.” It can only sell you the four nouns and leave the verb, the actual work, as homework for you.

So the store’s success is its own ceiling. The more apps it lists, the more islands you own, the more cabling you do, the more the real job, the cross-app verb, lives nowhere except in your tired head. A store that sells ten thousand apps has, by definition, sold you ten thousand things that don’t talk to each other. Scale makes the integration problem worse, not better. The bottleneck never disappears. It just moves to you.

The operating system inverts the optimization. It doesn’t optimize for the sellable unit. It optimizes for the job done, and to do that it treats every app, every tool, every data source not as a destination you visit but as a capability it can call. The store sold you places to go. The OS gives you outcomes that come to you. Same underlying tools, opposite grammar.

This is why “the OS swallows the app store” isn’t a land grab. It’s a change in what the atom of software is. The app store’s atom is the installable noun. The operating system’s atom is the describable verb. And once the atom is a verb, a thousand of the nouns you used to install collapse into capabilities the system assembles when you ask, the way a real operating system already collapses “save,” “print,” and “search” into things no program ships separately.

A funnel that inverts. Forty installed apps, each its own island, each hand-wired, funnel down into one operating system. From that single point, the OS fans back out into capabilities assembled on demand: follow up, score the pipeline, watch the renewal, brief the meeting. The apps became ingredients; the verbs became the product.

What “assemble the capability” actually means

It’s worth being concrete, because “the OS assembles it” can sound like hand-waving if you’ve heard enough demos.

The naive picture of assembly is a chatbot that calls one tool and returns one answer. That’s not assembly; that’s a fancier app, a single noun with a conversational front door. It breaks the moment the job needs two tools that have to agree, or a step that has to happen tomorrow, or a result that has to be checked before it’s trusted.

Real assembly is closer to what a good operator does in their head when you hand them a vague request. They decompose “watch the renewal” into: find the contract, read the date out of the clause, set a watch on it, and surface it three days early with the reason attached. They pick the tools. They sequence the steps. They notice when one step’s output is another step’s input. And they know when to come back and ask, because something in the request was ambiguous and guessing would be worse than checking.

That decomposition, sentence to plan, plan to tool calls, tool calls to a checked result, is the work the operating system has to own for the grammar flip to be real. It’s not a smarter search box. It’s the thing that turns “score my pipeline” into a sequence it can actually run, draws on the company’s own knowledge to do it, and stops to confirm before it does anything that would be expensive to undo. Apollo is built so the unit you hand it is the verb, and the assembly underneath, which tools, in which order, checked how, is the OS’s problem, not yours.

And notice what that does to the forty logos. They don’t all vanish; some of them are still where your data lives, and the OS reaches into them. But they stop being destinations you maintain. They become ingredients the system reaches for. You stop opening them. You stop wiring them. You stop being the one who remembers that the name in the email has to be typed into the CRM by Friday. The apps recede into infrastructure, and the verbs come forward as the thing you actually touch.

The turn: you were never supposed to be the integration layer

Strip away the OS talk and here’s what this is really about.

Somewhere in your company, right now, a person is doing a job no human should have to do: holding forty disconnected tools together with attention. They’re the one who copies the deal value from the email into the spreadsheet, who remembers the contract renews before the calendar does, who notices the form submission never made it into the CRM. That person is usually your most capable one, because integration-by-attention requires someone who can see the whole picture, and the whole picture is exactly what your most capable person should be spending their judgment on, not their afternoon.

We told ourselves that wiring was diligence. It was never diligence. It was a tax we paid because the unit of software was the app, and apps don’t compose themselves. The hours your team spends being the cable between forty islands are hours stolen from the only work that’s actually theirs: deciding what the company should chase, what “good” means for the people you serve, which job is even worth doing. You can’t outsource that to a tool. You shouldn’t be losing it to forty.

The promise of an operating system that assembles capability from description isn’t “fewer subscriptions,” though you’ll have those. It’s that the most capable person in the building stops being the integration layer and goes back to being the person who decides what’s worth integrating in the first place. The verbs get done. The human gets to choose which verbs matter.


That’s what we’re building at Apollo, not the forty-first app, but the layer underneath that turns a described job into an assembled capability, so the apps become ingredients and the verbs become the product. The last app you install is the one that installs the rest. After that, you stop shopping for software and start asking for outcomes, which is the only thing you ever actually wanted.

Apollo runs your company's repetitive ops so your team doesn't.

Join the waitlist for early access, founding-user pricing, and a front-row seat as we ship.

Join the waitlist