I keep drawing the same picture in client meetings, so it's probably time to write it down.
Pick any modern company stack and you'll see roughly four layers: presentation (web, mobile, chat, the AI front door), applications (the ERPs, CRMs, SaaS tools), data (warehouses, lakes, analytics), and infrastructure underneath. And somewhere off to the side there's a corner labelled "automation": a few integration tools, some scripts, maybe an RPA bot. That corner is what I want to talk about, because it's not actually a layer. It's a shed.
Two things worth writing down:
- what makes something a layer, and why the shed doesn't qualify
- what the missing layer would need to do, concretely
What a layer actually is
A layer, the way architects use the word, has three properties:
- a clear contract with what's above and below it
- consistently addressable: anything in the system can call it the same way
- operable: observable, auditable, replaceable
The automation shed has none of these. Each tool has its own auth, its own account, its own logging (if any). Ask "where does our company run a process?" and the answer is usually "depends which one", meaning the real answer lives in a few people's heads.
The missing layer has a name
Call it the Process Execution Layer (PEL). The job is simple to state and hard to ship: given a defined process and a trigger, run it reliably across every system in the company, leave a complete record, and make the execution callable by anything, including AI.
Not "build me a workflow", not "send this webhook". Run this process. Same way every time, always logged, always invokable.
The picture from those meetings:
[Presentation / AI front door]
▲
│ "do the thing"
▼
┌────────────────────────────┐
│ Process Execution Layer │ ← the missing piece
└────────────────────────────┘
▲
│ reads + writes
▼
[Application & Data layers]
Everything above asks for execution. Everything below gets touched in a coordinated, audited way.
Why the existing tools didn't become this
Not for lack of quality. Each generation was built around a different center of gravity:
- integration tools are built around point connections ("when X happens in one app, do Y in another"): great at that, less good at long-running, audited processes that live inside your own network
- RPA is built around driving legacy screens where no API exists: useful there, heavy everywhere else
- BPM suites are strong on modelling and slow on shipping (beautiful diagrams, quarters to production)
- scripts and engineering schedulers work, but business teams can't touch them, and the audit story is whatever the author remembered to log
Each has its place. None gives you a single addressable, audited execution surface that business teams can own and AI can invoke.
What the PEL needs, concretely
Working backwards from what teams actually need:
- one execution model, many triggers: the same process whether kicked off by a schedule, an email, a person, or an AI agent
- native steps for real systems (accounting, documents, OCR, mail, storage, etc), not webhooks-for-everything
- private by default: sensitive processes run on your infrastructure, and the data doesn't leave your network just because you automated something
- a real audit log: per-step inputs and outputs, who triggered what, kept as long as the auditor needs
- callable from anywhere: REST, schedule, chat, AI tool-use, all reaching the same process
- no per-run pricing tax (pricing shouldn't be a reason not to automate)
This is roughly what flow8 is building, and it's the first time I've seen "Process Execution Layer" used as a product category rather than a slide-deck flourish.
One practical note, because nobody rips out their stack on a Tuesday: adopting a PEL doesn't mean killing the existing automations overnight. The path we usually propose is to stand up the layer, move the two or three highest-value processes first (finance and document handling are typical candidates), and let the rest of the shed retire naturally as its processes get rebuilt.
Why now and not two years ago
Two reasons. First, AI agents started invoking processes instead of just writing text, and a folder of disconnected scenarios can't be exposed to an agent cleanly, while a PEL can: every process is already a tool. Second, regulators woke up. EU AI Act, FINMA expectations on outsourcing, sector rules on audit trails for automated decisions. A pile of disconnected automation tools is a compliance liability; one execution layer with a proper log is the evidence you wish you had.
Whether the category ends up being called PEL or something else, the gap it fills is real: we hit it in almost every project. If your company has a one-sentence answer to "where do our processes run?", curious to hear it. Always open to compare notes!