Vertesia Blog

Building your Process Engine for AI Agents

Written by Mary Kaplan | May 12, 2026

Enterprise automation has a gap - and most organizations have been living with it for so long they have stopped noticing.

For decades, business process engines were built around two actors: deterministic code that executed known steps without deviation, and humans who handled the judgment calls - the document review, the exceptions, the approvals that required someone to actually think. The engine was excellent at routing, auditing, and enforcing sequence. It was not designed to reason.

AI agents change that equation. They can read a document, assess a situation, and make a judgment call that previously required a person. They are, in many ways, exactly what enterprise process automation has been waiting for.

But here is the problem: you cannot simply drop an agent into a twenty-year-old process engine and expect it to hold. The engine was designed for predictable actors. Agents are not predictable in the same way. They can drift. They can over-reach. They can produce outputs in unexpected shapes and decide, autonomously, that a compliance step does not seem necessary today.

So, we should limit what agents can do, right? Well, let’s actually redesign the engine around what agents are.

That is what our CEO Eric Barroca set out to do, and his full technical account of the design is well worth reading. Here is what it means in practice for enterprise teams.

Two failure modes enterprises can’t afford

When organizations try to bring AI into their operational workflows today, they typically land in one of two traps.

  • The first is treating AI as just another service call. The agent gets inputs, returns outputs, and has no meaningful standing in the process. It is wired in like an API. This is safe, and deeply limiting. The moment a use case requires genuine judgment that does not reduce to an input/output mapping, the AI is in the wrong seat and the human bottleneck returns.
  • The second is giving agents too much latitude. Hand the agent a goal and a toolset and let it figure out the rest. This is powerful in a demo environment and genuinely risky in production. Nothing prevents the model from routing a use case differently than it should. Nothing forces the same decision process to apply consistently. Nothing produces a clean audit trail. For any regulated industry or any process that touches sensitive decisions, this is not an acceptable operating model.

True enterprise workflows live between these failure modes: things like contract review, invoice approval, vendor onboarding, case management, loan origination. These processes have typed state, defined routing logic, human approval requirements, and specific steps where AI reasoning can accelerate the work. They need both deterministic and autonomous operations simultaneously.

The end of unsanctioned agent actions

The Vertesia Process Engine is built around a single governing principle: the engine owns the contract, not the agent.

What does that mean? Every node in a process explicitly declares which data fields it is permitted to modify. An agent working inside a contract-review node might be allowed to write a risk score, a risk explanation, and a flag for whether legal review is required. It is not permitted to write the approval decision, the payment status, or the final case outcome. The engine enforces this strictly. If the model attempts to produce a result outside its declared scope, the engine rejects it.

This changes the risk calculus for enterprise AI deployments in a fundamental way. The agent can reason freely within its declared scope. Outside that scope, the process guarantees hold regardless of what the model produces. Audit trails are clean because every context change is bound to the node that declared the right to make it. Routing logic is trustworthy because the data guards operate on exactly what the upstream node wrote.

The new way to author the Process Engine

One of the persistent frustrations of enterprise process design is the gap between intent and implementation. A business stakeholder can describe a workflow clearly — route contracts above a certain value to legal review, notify the submitter on approval, send rejections back for renegotiation — but translating that into a functioning process definition typically requires specialist expertise, extended timelines, and a BPMN diagram.

Vertesia takes a different approach. Processes are authored conversationally: the user describes what they want, and an AI assistant produces a validated process definition. Edits happen within the same interface. The assistant can build a process from a text description, a whiteboard sketch, a screenshot of an existing workflow tool, or an imported BPMN library.

The result is process design that is accessible to the teams who understand the business logic, without requiring those teams to become process automation specialists.

Built for the complexity and duration of real work

Enterprise workflows do not complete in seconds. A contract review process might span days. A vendor onboarding workflow might span weeks. A case management process might span months, with human approval gates that sit idle for periods that have nothing to do with the technology and everything to do with organizational tempo.

Vertesia Process Engine is built on Temporal, a durable execution substrate that treats waiting three seconds for an API response and waiting three days for a human reviewer as the same primitive. A system redeploy does not interrupt in-flight runs. Human tasks park cleanly and resume exactly where they left off when the signal arrives.

For enterprise teams, this means no special-casing for long-running processes. No engineering effort to handle the gap between what the automation can do and the pace at which humans actually move. No second system to produce the audit trail — it is built into the run history of every execution.

Giving AI the right amount of autonomy

Not every step in a business process benefits from AI reasoning. If the next action is known and deterministic — call an API, fetch a record, update a document — adding a model to that step adds latency and cost without adding value. The right tool for a known step is a tool call, not an agent.

Vertesia makes this distinction explicit. The same tools available to an agent inside a reasoning node can also run directly as deterministic process steps, with no model in the path. Process design becomes a considered choice at each step: is this step known, or does it require judgment? If known, execute it deterministically. If it requires judgment, give the agent the tools it needs — bounded by the declared contract.

This matters operationally. Deterministic steps are faster, cheaper, and easier to audit. Agents should be spending their reasoning capacity on the problems that actually require reasoning.

What could this mean for your team?

It’s time to rebuild our processes from the ground up around what agents actually are - probabilistic reasoners that need the structure and contract enforcement that process engines have always provided, now extended to cover what agents can read, what they can write, where they can route, and when humans stay in control.

Vertesia’s Process Engine is that rebuild: deterministic where the business needs guarantees, agentic where reasoning earns its keep, and governed throughout by a contract the engine, and not the model, holds.

For enterprise teams navigating the gap between what their current process tools can do and what AI agents could contribute to their operations, the question is no longer whether agents belong in enterprise workflows. They do. The question is what kind of engine is capable of governing them.

For a full technical account of the architecture behind Vertesia Process Engine, read Eric’s original post: The Engine Is the Contract: Rethinking Process Engines for the Agent Era.