Camunda's ProcessOS Argues BPM Was Always the Right Layer for AI Agents

Most enterprise AI strategies in 2026 are built around the wrong layer. They govern agents at the model level, or they pick an agent platform and hope governance comes with it. Camunda just made the case that both approaches miss the point.

Quick Take: On May 20, 2026, Camunda announced ProcessOS at CamundaCon in Amsterdam, in front of roughly 1,200 enterprise leaders and technologists from 25 countries. ProcessOS sits as an AI intelligence layer on top of Camunda's existing orchestration platform, which already runs millions of concurrent workflow instances daily. The product uses four AI agents to cover the full process lifecycle: discovering how things actually run today, re-engineering them toward desired outcomes, building and deploying the new process, and improving it continuously in production. According to Camunda's May 20 announcement, the core thesis is that enterprise AI adoption has stalled at task assistance because agents haven't been given the authority or the governance structure to act at the process level. ProcessOS is Camunda's answer to that.

What ProcessOS Actually Does

The product works from natural language. You describe an outcome. ProcessOS generates a complete process-based solution: agentic workflows, data mappings, integration logic, decision rules, agent prompts, and the UI forms that humans still need to touch. It pulls from Camunda's Marketplace catalog of extensions, so it's building on existing connectors rather than inventing from scratch.

Four specialized AI agents share the work across the process lifecycle. The first maps how processes currently run, not how you think they run. The second redesigns the process around the outcome you specified. The third handles build and deployment. And the fourth watches production, flags drift, and feeds continuous improvements back into the loop.

What the Data Says

• Camunda's existing platform handles millions of concurrent workflow instances daily across large enterprise deployments (Camunda, 2026)
• CamundaCon Amsterdam 2026 drew approximately 1,200 enterprise leaders and technologists from 25 countries (Camunda, 2026)
• Enterprise AI adoption has stalled at task assistance, with most deployments limited to recommendations and chatbots rather than process-level action (Camunda ProcessOS launch brief, 2026)

ProcessOS runs natively on Amazon Web Services, with deep ties to Amazon Bedrock and Amazon Bedrock AgentCore. That covers foundation models, agent memory, identity management, and gateway services. It's currently in closed beta; enterprises can register interest at camunda.com/process-os.

CTO Daniel Meyer is Camunda's named executive on this launch. His framing is direct: companies need to stop thinking about which tasks AI can assist with and start deciding which tasks should be performed by agents vs. humans, at the process level, with full traceability.

Why the Process Layer Is the New Battleground

Business Process Model and Notation (BPMN) is a 20-year-old enterprise standard. Camunda is one of its largest platform vendors. The ProcessOS bet is that this layer, specifically the orchestration of multi-step processes with defined roles, handoffs, and SLAs (Service Level Agreements), was always the right place to govern agents. The LLM layer is too abstract. The chat layer is too shallow. The process layer already has what enterprises need.

And it's not just Camunda making this move. IBM, Pega, and Appian are all extending BPM tooling toward agents. At the same time, Salesforce Agentforce, ServiceNow AI Platform, and Microsoft Copilot are all building process capabilities into what started as agent platforms. Both camps are racing for the same control surface.

The question for CTOs isn't which vendor wins. It's which architectural layer should anchor your enterprise agent strategy. That's the real decision ProcessOS forces onto the table.

The Three CTO Implications

The convergence is real, and you need to pick a layer

BPM vendors and agent platform vendors are converging on the same control surface. Camunda's argument is that BPM already has the primitives enterprises need: audit trails, versioning, SLA enforcement, role-based handoffs, and human-in-the-loop checkpoints. Agent platforms are trying to retrofit those capabilities onto architectures designed for task execution, not process governance.

That doesn't automatically mean BPM wins. But it does mean that if you're currently governing agents at the model layer through prompt engineering and guardrails, you're doing it at the wrong level. Prompt-level governance doesn't survive a process with 14 steps and 4 handoffs.

Agents-as-tasks beats agents-as-apps for compliance

The pattern that matters most for regulated industries is "agent executes a step inside a governed process," not "agent operates as an autonomous application." A refund approval, a Know Your Customer (KYC) check, or an insurance claim adjudication all need the same traceability whether the executor is a human, a script, or an AI agent. The process layer already enforces that, because the process definition predates the agent.

This is where BPM platforms have a genuine structural advantage. When you run an agent inside a BPMN process, the audit trail isn't something you add, it's something you inherit. The compliance team doesn't need to trust the agent; they trust the process, and the agent is just one more executor of steps they've already approved.

See Governance Requirements by AI Pattern for how this plays out across different agent use cases, and Execute: When AI Changes External State for the broader context on why agent execution governance matters.

The procurement question just changed

Until now, the common CTO question was: "Which agent platform do we standardize on?" Now it has to be two questions. First: which orchestration layer governs how we design, deploy, and audit processes, whether the executor is human or agent? Second: which agent runtime do we use for the AI execution steps inside those processes? And critically: are those the same platform or different ones?

For some organizations, the answer will be consolidation: pick Salesforce or ServiceNow and accept that your orchestration and your agent runtime are the same vendor. For others, especially those with complex, regulated, multi-system processes, the answer may be to keep BPM as the orchestration layer and treat agent platforms as execution engines that plug into it.

ProcessOS is essentially Camunda's argument that you shouldn't have to choose: let the process layer own orchestration and governance, and let foundation models handle intelligence. It's a clean separation. Whether it holds in practice depends on your existing architecture. But the framing is right.

For a framework on how to approach this build-vs-buy-vs-partner question at the executive level, see The Build-vs-Buy-vs-Partner Framework.

The Process-Layer Control Test

Before any CTO commits to an agent governance approach, run this three-question test. Each question maps to a different layer.

Question 1: Does this process require a documented audit trail for compliance or legal review? If yes, you need the process-orchestration layer. Model-level guardrails don't produce the step-by-step audit log that compliance teams require. BPM does.

Question 2: Does this process involve handoffs between humans and agents, or between multiple agents? If yes, you need explicit orchestration, not just an agent that calls tools. Process-orchestration platforms define handoff points, escalation paths, and SLAs. Agent platforms typically don't, unless you build that logic yourself.

Question 3: Does this process need to be versioned, rolled back, or certified by a non-technical stakeholder? If yes, you need a layer that separates process definition from execution. BPMN diagrams are readable by process owners and compliance teams. Agent code is not. If your CISO or compliance officer needs to approve the process, they need to read it in something other than Python.

If you answer yes to two or three of these questions, the process-orchestration layer belongs in your evaluation. If you answer yes to none, an agent platform or direct model integration may be sufficient.

What to Put on a 90-Day Evaluation

The 90-day window matters because platform decisions made now will be hard to reverse in 12 months. Here's what a structured evaluation looks like.

Days 1-30: Map your regulated process inventory. Pull every multi-step process in your organization that has a compliance, audit, or SLA requirement. Score each one on the three questions above. You don't need to evaluate all of them, but you need to know where the governance risk lives.

Days 31-60: Run a parallel architecture test. Pick one medium-complexity process that currently uses an agent or is being built for agents. Implement it twice: once inside your current agent platform, once inside a BPM tool like Camunda (even the free tier). Compare the audit output, the time to add a new handoff step, and how a non-technical stakeholder would review and approve it.

Days 61-90: Produce a one-page architectural decision record (ADR). Document which layer governs which class of process in your environment. This is the output that prevents the next team from rebuilding the decision from scratch. Even if you conclude that agent platforms are sufficient, writing the ADR forces clarity on the tradeoffs.

For more on how this decision fits into broader AI workforce and operations strategy, see The Executive Decision Framework for AI Workforce Strategy and The Governance Gap: What Leaders Get Wrong About AI at Work.

What to Do This Week

The ProcessOS announcement is a forcing function, not because you need to evaluate Camunda specifically, but because it signals that the BPM and agent platform markets are officially in the same fight. Decisions you delay now will be harder to make under vendor pressure in six months.

This week, do three things. Pull one regulated multi-step process that is currently running with an AI agent or is being built for one. Run it through the Process-Layer Control Test above. Then schedule 30 minutes with your head of compliance and your agent platform lead in the same room to discuss whether your current governance approach would survive an audit.

That conversation will tell you more than any vendor briefing about whether the process layer belongs in your architecture. And if the answer is yes, ProcessOS just gave you a specific product to put on the evaluation list.

Learn More

• Autonomous Agent: Multi-Step Goals With Tool Use
• The ACE Framework: A Periodic Table for Business AI
• Introducing BPM: A Framework for Process Management

---

Frequently Asked Questions

What is Camunda's ProcessOS?

ProcessOS is an AI-powered intelligence layer built on top of Camunda's existing process orchestration platform. Announced in May 2026, it uses four specialized AI agents to discover, redesign, build, and continuously improve business processes. Users describe desired outcomes in natural language and ProcessOS generates the complete process solution, including integrations, data mappings, and agent prompts.

Why does the process layer matter for AI agents?

The process-orchestration layer already carries the governance primitives enterprises need for agents: audit trails, SLA enforcement, versioning, role-based handoffs, and human-in-the-loop checkpoints. Governing agents at the model or agent-platform layer means adding these capabilities after the fact. BPM platforms inherited them from two decades of enterprise process management.

How should a CTO evaluate ProcessOS vs. an agent platform like Agentforce or ServiceNow AI Platform?

The key distinction is what each layer governs. Agent platforms govern which agents exist and what tools they can call. Process-orchestration platforms govern how multi-step processes run, who or what executes each step, and how the full execution history is recorded. For regulated workflows (claims, KYC, approvals), you likely need the process layer regardless of which agent platform you choose. For simpler task automation, an agent platform alone may be sufficient. Use the Process-Layer Control Test in this article to decide where your specific processes fall.