There's a diagram on a wall — or more likely buried in a Confluence page — that maps how your company handles a customer complaint. It's a flowchart. Boxes, diamonds, arrows. Every decision point drawn in advance. Every exception accounted for. Every path leads somewhere.

It probably took months to build. It's probably wrong.

Not wrong because someone drew the wrong arrow. Wrong because real business processes don't follow scripts. They improvise. A customer calls about an invoice, but halfway through the conversation it turns out the real issue is a contract renewal. A compliance check that takes ten minutes on Tuesday takes three days on Friday because the approver is on holiday. A VIP escalation triggers a chain of events that nobody mapped because nobody imagined a client would ask for all three things at once.

I've spent twenty years watching companies try to force reality into flowcharts. The flowcharts always lose.

The Imperative Trap

The dominant language for designing business processes is BPMN — Business Process Model and Notation. It's been the standard for two decades. And it's built on a simple premise: draw every step before it happens.

BPMN is imperative. It tells the system: "Do this, then this, then if X happens do this." It's a movie script. Every line written, every scene choreographed, every possible ending accounted for in advance.

This works beautifully — for simple, predictable processes. Approving a purchase order with three tiers. Routing a document through a fixed sequence of reviewers. Onboarding an employee through a checklist.

But the moment the process gets complex — the moment it involves real humans making real decisions in real time — the imperative model starts to crack. Research shows that process participants routinely deviate from pre-defined workflows because the designed process can't accommodate the situation they're actually facing. The fix? More boxes. More diamonds. More exception paths. Until the diagram becomes so complex that nobody reads it, nobody maintains it, and the actual process lives in the heads of three people who've been here since 2014.

And now we're adding AI agents to this equation. Camunda's research on agentic BPMN patterns highlights the core tension: BPMN lacks constructs for expressing an agent's planning capability or the constraints that govern it. You can draw a box labeled "AI decides," but you can't express how it should decide, when it should escalate, or what it should do when the world doesn't match the map.

The Reactive Alternative

There's a different approach. It comes not from enterprise software, but from game development and robotics — two fields where the environment is unpredictable by definition, and rigid scripts are a guarantee of failure.

It's called a Behavior Tree.

Instead of scripting every step, a behavior tree defines how to react to what's happening right now. Think of it as the difference between a classical orchestra (every note written on the score) and a jazz ensemble (a structure, a key, a set of rules — and then you listen and respond).

A behavior tree doesn't say "Step 1, Step 2, Step 3." It says:

• "If the customer is angry and the order value is high, escalate to a human."
• "If the AI's confidence is low, ask for verification before acting."
• "If the compliance check times out, retry twice, then flag for manual review."

Each rule is a small, self-contained module. Modules compose into larger behaviors. You can add, remove, or rearrange modules without rewriting the entire process. Research comparing both approaches consistently finds that as complexity grows, behavior trees become easier to maintain, easier to test, and easier to extend than their imperative counterparts.

This matters enormously for business leaders. Not because of the technical elegance, but because of what it means in practice.

What Business Leaders Should Care About

BPMN assumes you can predict the future. Behavior trees assume you can't.

Here's how that difference plays out:

The practical implication is this: when you automate a process using an imperative model, you're betting that the map matches the territory. When you automate using a reactive model, you're building a system that navigates the territory as it finds it.

The Conversation You Should Be Having

If your organization is exploring process automation, AI agents, or digital transformation, the question isn't just "which processes should we automate?" It's "are we designing for the process we drew, or for the process that actually happens?"

Most leadership teams I work with have never asked this question. They've inherited BPMN-based process models from a decade ago and assumed that automating them is the logical next step. Sometimes it is. But when the process involves human judgment, exceptions, AI decisions, or real-time adaptation — the imperative model creates an expensive illusion of control.

The reactive alternative doesn't require throwing away everything you've built. It requires a different question at the start of every automation initiative:

"What should happen when things don't go as planned?"

If the answer is "follow the flowchart," you have an imperative design. If the answer is "evaluate the situation and respond based on these rules," you have a reactive one.

The first approach works for simple, predictable processes. The second works for the messy, human, exception-heavy processes that actually drive your business.

And in a world that improvises, your processes should too.

Sources:

• Camunda — Essential Agentic Patterns for AI Agents in BPMN (2025)
• PRIME BPM — How AI Agents Will Redefine BPM in 2026
• Springer — Seven Paradoxes of BPM in a Hyper-Connected World
• ArXiv — Behavior Trees and State Machines in Robotics Applications (IEEE TSE 2023)
• Flowable — BPMN Is Dead, Long Live BPMN
• Polymath Robotics — State Machines vs Behavior Trees