A slide I used regularly during the microservices hype—and just had to dig out again for agents.
After some successful agent pilots, a lot of organizations are quietly discovering that the efficiency gains are leaking. Disconnected agents create rework, conflicts, and edge cases nobody owns. Speaking to customers, I realized I've seen this movie before.
Every technology wave has a question that feels obvious in retrospect and gets skipped in the excitement. For microservices it was: who actually owns the end-to-end flow of a customer journey? For agents, I think it's the same question.
The promise of microservices was that software development teams could stay independent and move faster—services would just react to events, no coordination overhead required. At the beginning, it even delivered on that promise. Adding a new service was easy: just consume events from what already existed, no need to talk to any producer. Teams moved fast.
The dominant coordination style was called choreography: services don't talk to each other directly. Instead they emit events (eg, order placed, payment confirmed, stock reserved), and other services react to those events independently. That way you don’t need a central coordinator and possibly don’t need to express an explicit sequence. Each service minds its own business resulting in a loosely coupled architecture (spoiler alert: loosely coupled it was not—as I dissected in a talk called “Loosely or lousily coupled? Understanding communication patterns in Microservices architectures”).
But then event flows multiplied, implicit dependencies piled up, and debugging a broken business flow meant tracing events across multiple services that had no idea the others existed. Maintenance became painful. And whenever there was a real business requirement with a logical sequence—you only ship orders that are paid, you only commit to a delivery when stock is actually reserved—expressing that implicitly through choreography turned out to cause a lot of trouble.
The sequence was an actual business requirement. It deserved to be visible, enforceable, and owned by something. That's orchestration: one explicit owner of the flow, not a chain of independent reactions. Teams discovered the hard way which problems needed which approach, and many eventually added explicit orchestration for the flows that required it.
Choreography vs. orchestration in event-driven microservices. From my 2019 InfoWorld article — the pattern hasn't changed.
That adjustment wasn't a failure of microservices as such. The industry simply needed to learn where the pattern works and where it doesn't—and that boring process orchestration is still required even in "modern" architectures.
Agentic AI is following the same arc
Agentic AI is following the same arc. And the early signs are familiar.
Right now, the conversation is almost entirely about what agents can do: reasoning, tool use, autonomy. And the capabilities are fascinating. But I'm having a lot of conversations with architects and engineering leads who deployed their first agents, saw good results, deployed more—and are now quietly discovering that coordination debt is eating the efficiency gains. Agents are making conflicting decisions or work is duplicated because two agents didn't know the other had already started. And worse: nobody is owning what happens when a step fails three operations in, after other systems have already been updated. I recently wrote about the technical reasons in detail (see Why Bolting LangChain onto a Workflow Engine Backfires at Scale and What a Native Agentic Architecture Actually Looks Like).
In the book I'm currently writing with my colleague Amy Johnston—Agentic Orchestration: How Process Discipline Governs and Scales AI Agents in Enterprise Operations—we call this the agentic value trap. It's common. And like the microservices version, it's avoidable, but only if you ask the right questions early.
The important questions
And the right questions are old questions, not the ones about exciting new technologies.
- Who owns the end-to-end outcome? Not which agent handles which task, but who owns the customer journey from start to finish, including the handoffs nobody designed for.
- What happens when something fails halfway through, after earlier steps have already been executed? Not in the happy path demo—in production, when step three fails and step two has already updated several systems.
- Where does the state of the work live, such that any participant—human, agent, or downstream system—can pick it up with full context, even days later?
- What's the audit trail? Not the LLM's reasoning log. The business-process record that answers a regulator's question six months from now. In regulated industries, this isn't a nice-to-have—it's often what determines whether you can go live at all.
These questions feel administrative, but they are actually architectural. Skipping them doesn't show up in the pilot. It shows up in production, when you're discovering you need that manual cleanup team.
I want to be clear about what I'm not saying. I'm not arguing that BPM is back, or that you should spend six months drawing swim lane diagrams before writing any code. Process discipline isn't a methodology. It's a habit of asking who owns the end-to-end outcome before you deploy something autonomous—and being honest when the answer is "nobody."
The microservices teams that got this right weren't the ones who modeled processes the most. They were the ones who treated the orchestration-versus-choreography question as a real design decision rather than something that would sort itself out. The agent equivalent is the same question: what genuinely runs independently, and what is actually a process—a sequence with business logic, dependencies between steps, and someone who has to own the outcome when something goes wrong?
There's one more counterintuitive thing worth naming. We expect the most mature agentic systems becoming more deterministic over time, not less. They start agentic because nobody knows the patterns yet. The agent discovers them through production exposure.
Once you know the pattern, you harden it into deterministic logic, which is faster, cheaper, and fully auditable. The agent earned its retirement by discovering something you can now encode as a rule. Version 1 is a clever agent, but version 4 is a governed process with agents handling only what genuinely requires judgment. That evolution only works if you build the orchestration foundation to support it.
The autonomy spectrum shifts over time. Version 1 is a clever agent. Version 4 is a governed process.
Boring technology enables agentic on a whole new level
Dan McKinley's Choose Boring Technology makes a famous point I keep coming back to: boring technology is worth choosing precisely because its failure modes are well understood. Process orchestration qualifies. It's been running mission-critical enterprise flows for two decades.
And here's what that foundation actually unlocks. Process thinking forces you to look at a customer journey end-to-end—not at individual tasks but at the whole flow. Once you're looking at the whole flow, you can ask a much more interesting question than "how do we make this faster?" You can ask whether the process should exist in its current form at all.
AI agents don't just automate steps; they make it feasible to redesign the journey entirely—collapsing handoffs, eliminating waiting, handling exceptions that previously required specialists. But you can only do that redesign if you first understand and own the end-to-end. Process discipline isn't the old way of doing things. It's what makes the new way possible.
I'll admit that "process discipline for AI agents" is not a pitch that gets anyone's pulse racing. Probably it never was. I recall that at a conference in the early days of Camunda, an organizer asked me, with genuine puzzlement, why two young guys like us (my co-ounder Jakob and me) were working on such an old men's topic like BPM. The answer then was the same as now: end-to-end automation of real business processes is one of the most impactful things software can do.
Twenty years later, a new generation of teams is about to discover that boring and unnecessary are different things.
