Headless BPM is business process management in which the process engine runs independently of any user interface. The process definitions, the runs, the task state, the approvals and the audit trail all live in the engine, and every one of them is reachable over an API. Whatever calls the engine gets the same behaviour and the same enforcement, whether that caller is a custom front end, a mobile app, a nightly script or an AI agent.

The word headless comes from content management, where a headless CMS separates the content repository from the presentation layer. Business process management had the same separation available for years and mostly ignored it, because the interface was the product. Agents changed that arithmetic. A process that exists only as a sequence of screens is a process no agent can read.

Headless BPM, defined

A BPM platform is headless when four things are true at once:

• Process definitions are structured data, not rendered pages. A caller can read the steps, the fields, the conditions and the owners without scraping a screen.
• The run lifecycle is programmable. A caller can start a run, complete a task, submit a field value, trigger a branch and close the run, all over the API.
• Live state and history are queryable. A caller can ask which runs are open, which tasks are overdue, who completed what, and when.
• Rules are enforced in the engine. Permissions, approvals, required fields and conditional logic hold no matter which client is calling. The interface is a convenience, never the control point.

Drop any one of those and the platform is not headless. It is a UI with a few endpoints bolted on. That distinction matters most on the fourth point. A system where the approval gate lives in the front end will happily let an API caller skip it, which turns every integration into a compliance hole.

Where the term came from

Headless BPM is not a new coinage. BP3 was talking about it as a deployment pattern for enterprise process engines, and ProcessMaker described it as a way to free front-end teams from a fixed vendor interface. Both framed the benefit the same way: decouple the engine from the presentation layer, and the people who build the experience stop being blocked by the people who own the workflow.

That framing was correct and, for its moment, mostly academic. The audience was a small population of enterprise architects running engines like Camunda behind bespoke portals. Most operations teams never needed it. They wanted the vendor interface, because a human was always going to be the thing clicking the button.

The argument holds up better now than it did when it was made. What has changed is the caller.

What changed: the caller is not a person

An AI agent asked to run a customer onboarding has to answer three questions before it does anything useful. What are the steps. What state is this particular case in. What is it allowed to do next.

None of those questions can be answered by a screen. An agent can be pointed at a browser and told to click through a workflow, and it will do a passable job for a while, and it will break the first time a modal moves. More to the point, that agent has no idea what the process actually is. It is imitating a human operating an interface rather than executing a defined procedure.

Give the same agent a process definition it can read and a run it can advance, and the shape of the work changes. The agent stops guessing at the sequence and starts executing it. The steps it must not skip stay unskippable, because the engine enforces them regardless of who is calling. Every action it takes lands in the same audit trail as a human action, in the same format, reviewable by the same auditor.

That is the practical case for headless business process management today, and it is a much larger case than the one the original headless argument was making. Back then, headless bought you interface flexibility. Now it decides whether AI agents can participate in your operations at all.

Headless BPM and agentic process automation

Headless BPM is the architecture. Agentic process automation is what the architecture makes possible.

Agentic process automation means AI agents executing real business processes end to end, with the process itself acting as the contract: these are the steps, this is the order, these are the checks, this is the evidence. The agent supplies judgment and speed. The process supplies the boundaries.

An agent cannot hold up its side of that contract unless it can read the contract. Headless is how it reads the contract. The two terms describe the same shift from different angles, one from the platform side and one from the outcome side, which is why teams evaluating agentic automation keep arriving at questions about API coverage and process schemas without quite knowing why.

What headless looks like in Process Street

Process Street ships a public API for the workflow engine, covering workflows, revisions, tasks, widgets, runs, form fields, data sets, users and permissions. The interface at process.st is one client of that API. It has never been the only way in.

What made the engine reachable by agents specifically is the Process Street MCP server, which exposes the public API as tools an AI assistant can call directly. An agent connected to it can list workflows, read a workflow’s task and widget structure, start a run, update form field values, reassign a task, query which runs are stalled and pull the completion history for an audit. The ten use cases we published for the MCP server are all variations on the same primitive: the process is data, so the agent can act on it.

Two properties matter more than the endpoint count. The server respects workspace permissions, so an agent operating as a user can only touch what that user could touch. And approvals, conditional logic and required fields are evaluated by the engine, so an agent cannot advance a run past a gate that a human could not advance past either. Control does not leak when the caller changes.

The everyday version of this is unglamorous and worth stating plainly. A developer onboarding workflow that an IT team built in the interface is, without any extra work, a process an agent can run. Nobody had to rebuild it as code. The definition was already structured data.

How to tell whether your BPM is actually headless

Six questions, answerable in an afternoon against any vendor’s documentation:

• Can you retrieve a full process definition, including tasks, fields and conditional rules, as structured data from a single documented endpoint?
• Can you start a run and complete a task without a browser session?
• Can you read the current state of every open run, including who owns each task and what is overdue?
• Do approvals and required fields block an API caller exactly as they block a person in the interface?
• Do actions taken through the API produce the same audit record as actions taken through the interface?
• Does the API respect the same permission model as the interface, per user, without a shared superuser key?

Two or three yes answers describes a platform with an integration API. Six yes answers describes a headless engine. The gap between those two is exactly the gap between a workflow tool an agent can poke at and a process layer an agent can be trusted inside.

Common questions

Is headless BPM the same as an API-first workflow engine?

Close, and the terms get used interchangeably. API-first describes how the product was built, with the API designed before or alongside the interface. Headless describes what the product permits, which is full operation with the interface switched off. An API-first product is usually headless. A product that added an API later often is not, because the enforcement logic stayed in the front end.

Does headless mean no user interface?

No. It means the interface is optional and replaceable. Most teams running a headless engine still use the vendor interface for building and reviewing processes, then let agents, scripts and embedded front ends do the running. The point is that the engine does not depend on the interface being present.

Is headless BPM the same thing as agentic process automation?

No. Headless BPM is an architectural property of the platform. Agentic process automation is a way of operating, where agents execute processes under the constraints the platform enforces. Headless is the prerequisite. Agentic is the use.

Do you need engineers to use a headless BPM platform?

To build the processes, no. Process definitions are still authored in the interface by the operations people who own the work. Engineers or agent builders come in at the point where something outside the platform starts calling the engine, and increasingly that caller is a configured AI assistant rather than custom code.

The short version

Headless BPM stopped being an architecture preference the moment software started doing the clicking. A process trapped inside its own interface is invisible to every agent you deploy, and rebuilding it as code throws away the governance that made it worth having. The processes worth automating with agents are the ones already written down, already owned, already enforced. Headless is simply whether anything other than a person can reach them.

The post What Is Headless BPM? The Process Layer Agents Can Call first appeared on Process Street | Compliance Operations Platform.