Platforms · 9 min read · August 15, 2026

I Shipped a Workflow Engine 23 Years Ago. AI Agents Rebuilt It. Except for the Two Guarantees That Mattered Most.

By Anjaneyullu Tamma

What I built 23 years ago

About 23 years ago, I designed a workflow engine and a visual designer built on the workflow patterns catalogued by van der Aalst and ter Hofstede: sequences, exclusive choices, parallel splits, synchronization, deferred choice, cancellation regions. You dragged nodes onto a canvas, and the designer refused to save a process with a missing connection or an unbound parameter.

Under the hood it did the unglamorous things well: serialized the process on save, deployed with one click to a server cluster, deserialized and re-validated on the server, and executed on triggering events, load-balanced, with process state persisted so any node could resume any instance. Step-by-step debugging in the designer. Transactional rollback around side-effectful steps. Group ownership, audit fields, and access controls in the properties pane.

Not a toy. A distributed, validated, recoverable, governable execution engine.

The surprising recognition

Recently I have been studying how modern AI systems orchestrate agents. The recognition was immediate and slightly unsettling: the industry has been reinventing that engine, often without knowing the pattern catalog exists.

The mapping is nearly complete. A conditional edge is an Exclusive Choice. Fan-out to parallel branches with an aggregator is Parallel Split followed by Synchronization. The orchestrator-workers pattern, where a lead model spawns a runtime-determined number of subagents, is Multiple Instances Without A Priori Runtime Knowledge. Human-in-the-loop approval gates are the old human task plus Deferred Choice. Timeouts and guardrail aborts are Cancellation Regions. Prompt chaining is Sequence.

The surrounding tooling returned too. Process variables became graph state. The action-node toolbox became the tool registry, the same atomic capabilities now exposed through function interfaces and protocol-based registries instead of drag-and-drop. Sub-process nodes became subagents. Trigger nodes became webhooks, queues, and event streams. And the visual designer itself, declared obsolete for years by the “workflows as code” crowd, is back as the agent-builder canvas, because the same people who needed visual designers then need them now.

But I want to be precise about what this recognition means, because “AI reinvented workflow engines” is both rhetorically powerful and technically imprecise.

What came back was the control-flow substrate: sequence, branching, parallelism, synchronization, cancellation, human approval, state, triggers, scheduling, persistence. What changed is something much more consequential: who decides what happens next.

The one node that changed everything

In my designer, an If node carried an explicit condition, a rule someone could read and a validator could check. In an agentic system, that gateway is a language model. The branching predicate moved from an inspectable expression into a model-mediated decision function.

That single substitution is the whole story.

But there is a deeper architectural implication than “the gateway became an LLM.” In traditional workflow, the workflow defines the behavior and the runtime executes it. In agentic systems, the workflow defines the boundaries and the model participates in defining the behavior. The model has moved from payload processor to control-plane participant.

In classical architecture, the control plane held explicit conditions and explicit transitions. In agent architecture, the control plane holds workflow structure, model reasoning, policies, and evaluation, and the model sits inside it. That explains why everything becomes harder. Once the control plane becomes probabilistic, you need new mechanisms around it.

And the real villain here is not nondeterminism. It is implicit semantics.

Consider the difference:

Classical gateway: IF creditScore > 700, approve. ELSE, review.

Agent gateway: Determine whether this application should be approved.

The problem with the second is not merely that it may produce different answers on different runs. The problem is that the policy itself has moved into the model. You cannot easily inspect it, prove it, diff it, version it, or test its boundaries exhaustively. The architecture has traded an explicit semantic contract for an implicit one. That is the architectural revolution.

In The Four Pillars of Extensibility Haven’t Changed in 20+ Years, I described the same shift from the extension side: dispatch became probabilistic. The gateway and the dispatcher were the two places where a human’s explicit decision lived in the architecture, and both are now occupied by a model. The article you are reading is the same observation from the process side.

Once the model moves into the control plane, every guarantee the old engine gave for free must be rebuilt in a new form. Here is the inventory.

The guarantees we lost, and what replaced them

Guarantee 1: Know what can happen before execution.

My designer refused to save an invalid process, a deterministic check performed once. That was static verifiability: before a single message was processed, you could inspect the artifact and know whether it was complete and consistent.

You cannot statically verify that a model will make the correct decision. So validation moved from compile time to execution time: structured outputs, constrained decoding, retry-on-invalid loops. Static validation became runtime defense. We can constrain the output format; we cannot prove the model will make the semantically correct choice. The guarantee was not recovered. It was replaced with a statistical approximation.

This is why I argued in The First Four Pillars Were About Structure. The Next Four Are About Behavior that Evaluation is the new Contract: when the routing logic cannot be read, it must be measured continuously. Eval suites are not a testing phase. They are the ongoing substitute for the proof the validator used to give for free.

Guarantee 2: Know exactly what happened after execution.

My debug mode could step through a process deterministically. Given the same input, the same branches fired every run. More precisely: the workflow engine knew the execution path, because it defined it.

An agent system often has to reconstruct why the execution path happened. That is a fundamentally different relationship between a system and its own behavior. So the tooling changed shape: record every model call, tool invocation, and state transition, then reconstruct the path after the fact. That is the Provenance pillar in operation.

Deterministic replay now has to be manufactured. Durable-execution runtimes persist each model output so a replay reuses the recording instead of reconstituting the original reasoning. The execution path is known; the reasoning behind it remains partially opaque. That is a weaker guarantee than the original, and it is important to say so.

The transaction node quietly disappeared, and that may be the most important missing piece.

My 2006-era toolbox had a Transaction Operation node: rollback around side-effectful steps as a drag-and-drop primitive. Most agent stacks have nothing like it.

But this is more consequential than it first appears. A workflow engine could sometimes roll back software state. An agent might send an email, create an order, call a payment API, provision infrastructure, modify a CRM record, or notify a customer. You cannot simply roll back those things. The harder problem is not making an agent reason correctly. It is making the consequences of incorrect reasoning recoverable.

That requires compensation, idempotency, transactional boundaries, approval gates, write barriers, and reversible action design. These are architectural properties, not implementation details. And almost none of today’s agent frameworks treat them as first-class concerns. Teams are rediscovering this one production incident at a time.

We used to contain code. Now we contain agency.

My old designer had a properties pane: group ownership, sharing scope, audit fields. Governance as a boring, solved feature. Today, even the basic question of whose credentials an agent acts under is unsolved in most deployments.

The traditional permission model was User, then Application, then Permissioned action. The agentic model is User, then Agent, then Model decision, then Tool, then Permissioned action. Every link in that chain raises a new authorization question: who authorized the model to make that decision on behalf of that user against that system?

That is Containment, and it is precisely why Trusting AI Agents Without Getting Burned argues for a deterministic, auditable checkpoint between a probabilistic system and anything it is about to commit. You cannot reliably validate uncertain output with more uncertainty. The checkpoint’s predictability is the feature.

Even the scheduler survived, with one new constraint.

Queue-and-worker execution, checkpointed state, resume-anywhere on the cluster: identical to the old engine. The difference is the scarce resource being balanced. I balanced compute. Agent platforms balance token throughput and rate limits, with steps that take minutes and cost real money per invocation. The scheduling architecture survived; the cost model it optimizes did not.

The bigger lesson

Agent orchestration is not replacing workflow architecture. It is inserting a probabilistic decision-maker into an explicit orchestration substrate. That single change removed guarantees that enterprise systems had quietly depended on for decades. A significant part of today’s agent infrastructure exists to reconstruct them.

The lifecycle is still: verify, freeze, distribute, execute. All four stages survived. But the two properties that made the first and last stages trustworthy did not: the ability to know what can happen before execution, and the ability to know exactly what happened after it.

Those properties did not disappear because the engineering community forgot about them. They disappeared because the decision node changed. And the response, evals, structured outputs, tracing, checkpointed replay, pinned model versions, write barriers, compensation patterns, is not a set of new capabilities. It is a reconstruction of old guarantees under new constraints.

If you spent years thinking in synchronization semantics, cancellation scopes, and transactional compensation, that toolkit is not legacy knowledge. It is precisely the vocabulary for describing what is missing, and for knowing where the next production incident will come from.

The patterns did not disappear. The guarantees did. And the enterprise architecture problem of the next decade is not merely building smarter agents. It is rebuilding, around probabilistic decision-makers, the guarantees that explicit decision-making used to provide almost incidentally.

If you have built workflow or integration platforms in a previous era: which guarantee do you miss most in today’s agent stacks, static verifiability or deterministic replay? In my experience, the answer tells you which production incident you are about to have.