The Specification Nobody Read Twice

There's a specific moment when an agent system stops being a demo and starts being infrastructure. The agent that researched and summarized beautifully in a notebook crashes mid-run in production, and twenty minutes of token spend vanishes. Or it needs a human to approve something, and there's no clean way to pause, persist state, and resume three days later when someone finally responds. Builders hit this wall and reach for what the ecosystem now calls "durable execution." They build checkpointers backed by Postgres. They implement interrupt patterns for human approval. They design compensation logic, so that when step seven fails, steps one through six can be unwound in reverse order. A specific group of architects in 2007 would have recognized the term immediately.

In June 2007, IBM, SAP, Oracle, and three other companies published a pair of specifications that formalized all of this. BPEL4People defined compensation handlers that reversed completed steps in sequence. WS-HumanTask specified a task lifecycle with explicit states: Created, Ready, Reserved, In Progress, Completed. The underlying workflow language, WS-BPEL, was built for "programming in the large": processes spanning days or months, state persisted to a database between transactions.

Today's "saga pattern" is BPEL's compensation handler under a different name. Today's checkpoint-and-resume is BPEL's process state persistence. Today's human-in-the-loop interrupt is WS-HumanTask's lifecycle, minus the XML. The parallels are, in several cases, structurally exact.

So why didn't the knowledge transfer? The problems it addressed never went away.

The technical story is straightforward enough. BPEL engines couldn't expose REST APIs and supported only about 40% of the specification's features in practice. When the ecosystem shifted to REST, the engines became architecturally invisible to the next generation of developers.

The sociological story runs deeper. BPEL lived inside WS-* vocabulary: WSDL, UDDI, SOAP, compensationHandler, peopleLinks. By 2010, that entire namespace had become shorthand for enterprise bloat. The REST community formed partly in opposition to it. New technical communities build shared vocabulary that signals membership. Referencing WS-HumanTask in a 2025 agent framework README would be like citing a fax machine manual in a Slack integration guide. Even if the content were useful, the citation itself marks you as someone who hasn't moved on.

And that coupling between knowledge and aesthetic identity is probably what makes the rediscovery structural. Specifications, vocabulary, and tooling aesthetics fuse with their era's identity. When the identity gets rejected, the knowledge encoded in it becomes unreachable.

Look at how the concepts actually survived. At least one current durable execution platform traces its lineage through AWS Simple Workflow Service and an Uber-internal project. Not through the BPEL specification. The ideas moved through a small chain of practitioners who rebuilt them in successive systems, each time in the idiom of the new era. The spec died. The people carried the concepts forward.

A December 2024 paper represents what appears to be the first scholarly attempt to reconnect BPEL-era workflow concepts with agent orchestration. Nearly eighteen years after publication. The authors propose combining BPEL engines with agentic platforms. It reads like archaeology. That it took almost two decades for anyone to formally notice the connection is itself a data point about how completely vocabulary boundaries partition technical knowledge.

The form in which knowledge gets encoded likely determines whether it survives a paradigm shift, independent of whether the knowledge itself remains valid. Communities that form through aesthetic rejection of the previous generation will, almost by definition, rediscover what they could have inherited.

The compensation handler was always going to be reinvented. The name was the part that couldn't survive.