There's a version of this thought that gets written every few years, and it's usually wrong because someone takes it too far. Let me try to keep it useful.
Look at what a company actually runs on (not in slides, in operations), and two things matter and survive:
- the data: what you know, recorded in a form you can query and reuse
- the process: how that data turns into outcomes, repeatedly and reliably
Everything else is a wrapper. Dashboards, web apps, mobile apps, now AI chats. Wrappers come and go; the asset is what's inside. That's not an argument against interfaces (people need them); it's an argument about where the attention and the budget should go.
The swap test
Watch an operations team for a week: they pull data from a system, check it, apply a rule, post somewhere, notify someone. That sequence is the process: the actual work of the company. The screen it happens on is incidental.
You can check this with a simple swap test. Swap the UI (dashboard for a chat bot, chat bot for voice), and nothing important moves: same process, same data, same output. Now swap the process instead, keeping the same UI (different rules, different systems, different data flow), and the team's whole world changes: output, compliance posture, deadlines. That asymmetry is the whole point.
Where the budgets point instead
Most companies still budget as if the UI were the product. Big investments in dashboards, design systems, portal redesigns; small ones in the process layer underneath. The surface keeps getting prettier while the engine runs on cron jobs and Slack reminders (every company has at least one process held together by a person going on vacation at the wrong moment).
The stance that holds up in practice: interfaces should be cheap and many; processes should be few, central, and well-built. A good process can power five interfaces at once (dashboard, chat, email digest, API, AI tool-call) without changing.
What "process as the asset" implies
If the process is the asset, a few requirements follow naturally:
- defined once, not implemented three different ways in three different tools
- invokable from anywhere: schedule, webhook, button, AI agent, another process
- its own audit log, independent of any UI being open
- versionable: what ran in April is reconstructable in December
- portable: replacing the SaaS underneath it shouldn't mean redoing it
That list reads like a product spec, and it's roughly what the Process Execution Layer category (flow8 among them) exists to deliver. Once the process lives in a layer like that, the interface question relaxes: build a chat front-end this year, a voice one next year, whatever wraps the same process the year after. The asset underneath compounds.
For a finance conversation, the same argument in their terms: interface investments depreciate fast: two-year-old dashboards already look dated, three-year-old apps get rebuilt anyway. A well-built process doesn't depreciate; by year four it has run 100,000 times and has the audit log to prove it. Most budgets invert this: they capitalize the wrapper and expense the engine.
The "but users need an interface" objection
They do. Two answers:
- Most users want results, not interfaces. A sentence to type or a button to push makes people happier than a 14-tab dashboard ever did.
- Multiple interfaces beat one perfect interface. Properly defined and addressable, the same process gives the warehouse team a scanner UI, the finance team a chat, the executive a weekly email. Trying to serve all three with one interface is how the un-loved enterprise portal gets built.
Where we'd start
The order we usually propose:
- inventory the processes, not the apps: what triggers each one, what data it touches, what outcome it produces (the list is shorter than people expect)
- pick one execution layer to own them, instead of leaving them scattered across automation accounts, scripts, and "someone does it manually every Tuesday"
- then decide which interfaces matter: deliberately, as wrappers over the asset, not as the asset itself
Companies that get the order right end up looking strangely calm: new interfaces launch in days because the engine already runs, audits become a walk through the log, and AI assistants don't need to "integrate": they call processes that already exist. Companies that get it wrong end up with a beautiful storefront and a kitchen on fire.
Curious whether this matches what others see, especially if you've had to argue the budget side of it with a CFO. Which argument landed for you?