When we start working with a new company, we usually ask for two lists. The tool inventory arrives within the hour, because somebody is already tracking the licence renewals. The process inventory usually doesn't exist. The thing the business actually runs on is the thing nobody wrote down.
That asymmetry was always there. The current pace makes it expensive. AI tool directories add entries daily, every department can now buy (or prompt into existence) its own software, and the tool list grows weekly. The process list, if anyone kept one, would barely change year to year. Quote-to-cash, hire-to-onboard, incident-to-resolution: the shapes are decades old.
Which of the two lists is the asset? Probably the one that doesn't change.
Tools are rentals
A tool holds a piece of your work for as long as the subscription runs and the vendor survives. When the CRM gets replaced, the company doesn't collapse. The process survives the migration, because it was never really in the CRM. It was in the sequence: lead comes in, gets qualified, gets an offer, gets followed up. The tool was the current tenant of one step.
The reverse doesn't hold. When a process breaks (hand-offs missed, steps skipped, nobody sure who owns the follow-up), no purchase repairs it. Teams try anyway, which is how a slow company ends up with forty tools and the same slow process, now with forty places to fall through. A good share of the "help us pick a tool" requests we get turn out to be process-definition work wearing the wrong name.
The tax nobody budgets
Each tool arrives with recurring costs that never appear in the business case: a login, a permission model, an API that will change versions, a sync that will silently stop, an internal owner who will eventually change jobs. One tool, fine. Forty tools, and the connections between them become the real system, undocumented and unowned.
Maintenance collects in the seams. Not inside any single tool (the vendor maintains those), but between them, where nobody owns it. The scripts, the one-off integrations, the CSV exports on someone's calendar: each was a quick win once. Together they surface only when something downstream looks wrong and three people spend a day tracing why.
What consolidation actually means
The instinctive answer (use fewer tools) mostly fails, and teams resist it for good reasons: they picked their tools because those tools fit the work. The version that holds up is different. Not fewer tools, but one place where the process runs across them.
That place is what we build. is the execution layer: processes run there, across the tools a company already has, on the company's own infrastructure. The tools stay where they are and keep doing what they are good at. What moves is the sequence between them.
Two chronic problems stop being projects and become properties of the layer:
- Maintenance. An API changes and one module gets updated, so every process using it inherits the fix. Credentials rotate in one place. Upgrades happen to one runtime, not to forty scripts of varying authorship. The seams still exist, but they're owned.
- Observability. Every process passes through one layer, so seeing them costs nothing extra. Which ran, which failed, where the slow step is, what touched the customer record, all answered from one log instead of reconstructed by interviewing tool owners.
The process is the documentation
Ask a company for its process documentation and you usually get a wiki page written once, by someone who has since left, describing what was supposed to happen two years ago. Nobody trusts it, so nobody updates it, which makes it less trustworthy. Process documentation decays by default.
A process that runs in one layer escapes that, because the definition and the execution are the same artefact. If the document were wrong, the process would fail. In each process is a versioned definition, so the current version is the one that ran this morning, and the history shows who changed what and when. This is what Process as Code means in practice: a process you can diff, review and roll back, the way code has been for decades. Documentation stops being a separate chore somebody is behind on.
The same shape covers two things that usually arrive late and expensive:
- Governance. Rights to view, run, edit and approve are set per process and enforced on every execution, at the API rather than in the interface. Consequential steps can stop and wait for a named human to approve them, so payments and outbound messages never run unattended. The person who builds a process doesn't have to be the person who signs off its sensitive actions.
- Security and residency. Credentials are encrypted and live in one place instead of in forty scripts. Processes execute on your own servers or private cloud, so client records, financial data and patient files never leave your walls to get work done. For AI steps this matters more, not less: a model that reads your contracts can run inside your network, on your hardware.
Audit falls out of the same property. Because every run passes through one place, the record is a by-product rather than a project: who triggered it, what went in, what came out, how long it took, step by step, kept immutably. Most automation stacks answer an auditor with assurances. This answers with evidence, which is a much shorter conversation.
Sequencing that works
The move fails as rip-and-replace and works as coexistence. What we usually propose:
- inventory the processes, not the tools, the ten to twenty that matter (this document outlives every vendor decision made after it)
- pick the execution layer before adding anything else new (adding tools first just deepens the future migration)
- migrate opportunistically: move a process into the layer when it breaks, changes, or needs an AI step, never all at once (broken-anyway processes carry no political cost)
- let the old automation die of natural causes. The integration somebody built in 2022 keeps running until its process gets touched, then it retires, no decommissioning program required
A year or eighteen months of this and the picture inverts. The tools have become swappable tenants, and the process (named, versioned, observable, governed) has become the durable thing. Which it always was. The company just couldn't see it before.
The tool list will keep growing, and nothing about the current market suggests otherwise. The more useful question is where the processes live, and whether your company could produce that second inventory on request. If yours can, I'd like to hear how you got there. It's rarer than it should be!