Henk Verloop is not, strictly speaking, a real person. He is a composite — assembled from documented BPEL-era practitioner experience, real specification documents, and the kind of career arc that a decade of enterprise process orchestration produces. If you worked in SOA between 2003 and 2012, you probably sat next to someone like him. He would like you to know that the travel-booking example was his first.

Between 2001 and 2007, a consortium of the largest enterprise software companies on Earth developed and ratified a formal specification for orchestrating long-running business processes across distributed services. IBM, Microsoft, Oracle, SAP, BEA, Adobe. The specification was called BPEL: Business Process Execution Language.¹ It had typed service interfaces, explicit compensation handlers for undoing completed work, scoped fault containment, and by June 2007, a published multi-vendor standard for integrating human tasks into automated workflows.²

Then the industry moved on. Microservices arrived. REST replaced SOAP. The specification gathered dust.

Twenty years later, durable execution platforms like Temporal describe themselves as "addressing gaps left by traditional BPM tools."³ Agent frameworks are building human-in-the-loop patterns from scratch. And the same travel-booking compensation scenario — book a car, book a hotel, fail on the flight, cancel everything in reverse — appears in both Oracle's 2003 BPEL documentation and Temporal's 2023 saga pattern explainer.⁴

We spoke with Henk about what it's like to watch an industry rediscover your work without knowing it existed.

You've described finding the Temporal documentation as a "very specific feeling." What was that like?

Henk: My team is doing a vendor assessment for workflow orchestration — we're a fintech, long-running processes, the usual. Someone puts Temporal's saga pattern documentation on my screen. And there's the travel booking example. Car, hotel, flight. Compensate in reverse order. I wrote that exact flow in BPEL in 2004 for a logistics client. Not similar. The same scenario, the same sequence, the same undo logic. I sat there for probably thirty seconds just... recalibrating.

You know when you visit a city you lived in twenty years ago and someone's opened a trendy coffee shop in your old apartment? The building is the same. The plumbing is the same. But nobody knows about the plumbing. They think the exposed brick is a design choice.

Walk me through the vocabulary translation. What maps to what?

Henk: It's almost mechanical, which is the unsettling part. BPEL's compensation handler is Temporal's saga pattern. BPEL's scope — your isolation boundary, your error containment unit — maps to a Temporal activity boundary or a LangGraph node. BPEL's fault handler becomes try/catch with retry policy.

And then the big one. BPEL's partner link, where you formally declared every external service your process could call using WSDL interface definitions — that's an MCP tool schema. Same structural problem: how does an orchestrator know what it's allowed to call, and what the contract looks like?

We wrote it in XML with WSDL port types. They write it in JSON with parameter schemas. The ceremony changed. The problem didn't.

You seem more interested in the why than the what.

Henk: Because the what is obvious once you see the mapping. What I can't stop thinking about is the transfer failure. These weren't obscure ideas published in someone's dissertation. The WS-BPEL 2.0 specification was ratified by OASIS in April 2007.⁵ Formal, published, internationally recognized. IBM, Oracle, SAP had production implementations. Thousands of enterprises ran business-critical processes on this stack. And when the next generation needed the same patterns, they started from scratch.

How does that happen? How does an entire discipline's output just... evaporate?

The BPEL4People specification seems like the most striking case.

Henk: [leans forward] This is the one that keeps me up. June 2007. Six major vendors — IBM, SAP, Oracle, Adobe, BEA, Active Endpoints — publish two companion specifications.² BPEL4People defines how you embed a human task in an automated process. WS-HumanTask defines the task lifecycle, the management interface, everything.

And it was thorough. Human tasks had two interfaces: one exposing the service the human provides, like an approval or a translation, and one letting people interact with their task queue.⁶ Formal roles — task initiator, potential owners, stakeholders, administrators. Escalation logic for timeouts. Work queues for group-based assignment. People links, like partner links but for humans, so you could bind roles at design time, deployment time, or runtime.

So the agent community is just rebuilding what you built?

Henk: No. And I want to be precise about this, because the lazy version of my complaint is "kids these days," and that's not what I mean.

There's something genuinely new that makes the problem harder. Our compensation handlers assumed deterministic service calls. You call a booking service, you get a confirmation or a fault. The fault types are defined in WSDL. You know in advance what "undo" means for every possible outcome.

When an LLM decides the next step? You can't formally specify compensation in advance because you can't predict what the system will do. The output is unstructured text that gets parsed into action. The failure modes aren't typed. The whole model of "define your undo logic at design time" — the foundation of BPEL compensation — that assumption breaks with a probabilistic actor in the loop.

The patterns are the same. The substrate is different in a way that actually matters. Which makes it more frustrating that nobody's reading the prior art, not less. You'd want to understand the deterministic version before tackling the harder one.

Why do you think the knowledge didn't transfer?

Henk: [long pause] Nobody decided BPEL's ideas were wrong. Nobody wrote a paper saying "compensation handlers are a bad concept." The microservices movement just walked around us. They were solving a different problem — deployment independence, team autonomy, API simplicity. The orchestration patterns weren't rejected. They were irrelevant to what people were excited about.

Then five years later, everyone doing microservices choreography discovers that choreography at scale is chaos, and you need orchestration again, and you need compensation logic, and here we are.⁷

The people who built BPEL implementations are now CIOs, or retired, or consulting on something unrelated. They're not in the rooms where agent frameworks get designed. The knowledge didn't get discredited. It got stranded in a community that dispersed.

Does that bother you?

Henk: Less than you'd think. What bothers me is the waste. Somewhere right now there's a team spending six months building human task routing with escalation timeouts, and they could read a nineteen-year-old spec and save four of those months. Not because the spec is perfect — God knows the XML was painful, I wouldn't wish WSDL on my worst enemy — but because the problems are catalogued. The edge cases are documented. Which escalation patterns work, which role assignment models break at scale, which compensation strategies fall apart when services are slow versus when they're down.

If you could say one thing to someone building agent orchestration today?

Henk: Read the specs. You'll hate the syntax. The XML alone will make you want to close the tab. But the problems you're going to hit in eighteen months are problems we hit in 2006, and we wrote them down. The vocabulary is different. The plumbing is the same.

And maybe check who lived in the apartment before you moved in.

Footnotes

1. BPEL was originally developed in 2001 by IBM and Microsoft, later standardized as WS-BPEL 2.0 by OASIS. https://cio-wiki.org/wiki/Business_Process_Execution_Language_(BPEL) ↩

2. BPEL4People and WS-HumanTask specifications were published June 26, 2007, co-authored by IBM, SAP, Oracle, Active Endpoints, Adobe, and BEA. https://blogs.sap.com/2007/06/26/yo-bpel4people-specifications-released-and-ws-humantask-too/ ↩ ↩²

3. Kai Waehner, "The Rise of the Durable Execution Engine" (2025). https://www.kai-waehner.de/blog/2025/06/05/the-rise-of-the-durable-execution-engine-temporal-restate-in-an-event-driven-architecture-apache-kafka/ ↩

4. The travel-booking compensation scenario appears in Oracle's BPEL Process Manager documentation (https://docs.oracle.com/cd/E23943_01/dev.1111/e10224/bp_faults.htm) and Temporal's saga pattern documentation (https://temporal.io/blog/compensating-actions-part-of-a-complete-breakfast-with-sagas). ↩

5. OASIS WS-BPEL 2.0 specification. https://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html ↩

6. WS-HumanTask v1.0 specification. https://download.boulder.ibm.com/ibmdl/pub/software/dw/specs/ws-bpel4people/WS-HumanTask_v1.pdf ↩

7. The Microservices Patterns literature recommends orchestration over choreography for non-trivial saga implementations, effectively rediscovering the central coordinator pattern that BPM engines provided. https://www.soa4u.co.uk/2018/02/is-bpm-dead-long-live-microservices.html ↩