Since CamundaCon, our field teams have taken the ProcessOS conversation directly to customers. The Great Re-Engineering rallying call is resonating, but each region is approaching it from a different starting point.
Regardless of where companies are in their AI journey, re-engineering can make a major impact on overall efficiency and business value:
- Companies who haven't invested much in AI yet make ideal re-engineering candidates, precisely because they carry no legacy AI investment to unwind.
- Experimentalists who've had some AI success at the task level face growing pressure to prove enterprise-scale value. For them, the value is in re-engineering the entire process rather than the individual task.
- Committed organizations further along in their AI journey may be well-versed self-service tools, but require a partner to help drive transformation.
In other words, ProcessOS is for any enterprise running mission-critical processes, where the outcome of re-engineering is measurable and material.
Let’s explore trends from our conversations in each region, along with common questions enterprises are asking about AI usage, preparing for re-engineering, and measuring success.
What we're hearing in the Americas
Conversations with North American customers keep circling back to a single distinction. When people hear “agentic orchestration,” they hear “agents” first, because AI agents are the new part of the story. Camunda has been doing process orchestration for its entire existence, and agents add a powerful new tool to that existing toolbox rather than replacing everything else in it. That framing has helped customers see ProcessOS as a vehicle to implement agentic orchestration
It also speaks to why so many of these processes never got re-engineered in the first place. The processes causing the most pain tend to be the most regulated, complex, and expensive to get wrong. The fear of breaking something that works, even imperfectly, has kept teams from touching them. ProcessOS lowers the cost of finding out what a re-engineered version would look like, so a team can see the redesign before committing to a full implementation.
One customer described this moment as the most transformative shift in process technology in years: earlier waves added AI inside existing processes one step at a time, but this wave builds an entire AI system around the process model itself, governance included, all the way through to execution.
What we're hearing in Europe
Conversations across Europe start from the question, “If your organization designed this process today, with AI already available, would it look anything like the process you're running now?”
Most enterprises that add AI to an existing process get a visible win. The process runs faster, and that improvement is easy to see and easy to sell internally. What stays hidden is the cost that comes with it: token consumption, model validation, and the compliance overhead of managing AI decisions inside a process that was never designed to be audited that way. Re-engineering with ProcessOS means the process is built with AI in mind from the start. And Camunda provides consolidated visibility into AI usage, with governance and auditability in one place.
Companies who have had some AI success at the task level make up the majority of ProcessOS conversations today. For them, the shift is from re-engineering individual tasks to re-engineering the process those tasks sit inside. For example, a telecom operator approached Camunda wanting 11 separate applications, until reframing the problem from multiple applications to a single order-to-delivery process.
What enterprises are asking about ProcessOS
Despite the different entry points, customers in both regions are asking versions of the same questions.
How do you measure whether a re-engineered process actually worked?
Measurement should include a quality goal for how the process should perform, and an ROI outcome tied to the business case for re-engineering it. An example might be a delivery exceptions process with a 24-hour resolution goal, alongside a separate ROI goal, such as hours of manual work eliminated. Both get defined by the process owner (the person accountable for that outcome) and both get expressed in plain language that ProcessOS uses to guide the redesign.
When testing ProcessOS on a wire transfer compliance process, we set a two-business-day goal and deliberately described a slow, fax-dependent current process. ProcessOS flagged the conflict directly, warning that keeping the fax step in place would make the two-day goal unreachable.
Which large language model (LLM) does ProcessOS use, and can we bring our own?
Yes, organizations can bring their own models in both regions. ProcessOS architecture is model-independent, and Camunda is already working with customers who want to use a variety of models. Composability has always been core to how Camunda builds, so ProcessOS connects to whatever LLM an enterprise already uses, keeping data inside that enterprise's own environment and avoiding new licensing costs. When the Camunda Forward-Deployed Engineering team works directly with a customer, that team uses the customer's preferred model rather than a default.
What do we need to do to prepare as an organization?
Nothing, at least not technically. What helps is knowing which process to start with and having some early thinking about what the future version should look like, but the real requirement is focus, time, and organizational commitment to seeing the change through.
The technical work of discovering, redesigning, and implementing a process is the easy part. The hard part is the willingness to let a process work differently once it's live, since a re-engineered process changes what employees do day to day (not just how fast the old steps run). Close attention and support is needed for employees involved to ensure new process buy-in, adherence and adoption.
How do you keep AI agents under control?
There’s a common misconception that AI guardrails are just prompts telling an agent what not to do. However, a prompt-based guardrail can still let an agent go somewhere it shouldn't. Real control comes from limiting an agent's tool surface to a defined set of deterministic actions in the first place, so the agent can call a pre-built function with a specific variable rather than write open-ended code.
A visually defined BPMN process makes those boundaries easy to see and easy to audit. Camunda's own practice includes a catalog of approved, governed components that ProcessOS reuses rather than generating new code from scratch, combined with a rule that nothing generated ships without human review. In other words, give agents real authority within boundaries that stay visible.
Where does ProcessOS get its information when process knowledge is scattered across systems?
The ProcessOS discovery layer is built to work with incomplete, scattered inputs. For example, there are a range of sources a ProcessOS discovery agent can draw on including existing files, a web research agent, a GitHub agent for reading code from existing systems, and an interview agent that generates questions based on what the other sources found, refining its understanding as a subject matter expert answers.
Discovery deliberately brings up the gaps in process knowledge, not just what it finds, since the point isn't only understanding what exists but identifying where a subject matter expert needs to fill in what doesn’t. For many companies, it’s important to keep a single source of truth across processes that touch shared context, such as KYC or bank governance data. Camunda Hub, arriving alongside ProcessOS this fall, will serve as a shared repository of process fragments and domain knowledge that gives discovery a second source beyond a single team's own documentation.
The underlying trends across both markets
The two regions confirm the same underlying thesis from opposite directions. In the Americas, the barrier has been risk. Mission-critical, regulated processes once felt too dangerous to touch, but are now made safer to explore because ProcessOS lets a team see the re-engineered version before committing to it. In Europe, the barrier has been diminishing returns. Organizations that have already invested in task-level AI are discovering the hidden costs of that approach, and are now looking for a way to consolidate that investment into something that scales.
Both point to the same conclusion. The obstacle to re-engineering has rarely been technology. It has been risk tolerance, organizational readiness, and the willingness to ask a bigger question about how a process should work in the first place.
Stay tuned for the next installment in the ProcessOS blog series!
