Two months into the ProcessOS story, the market conversation has moved from curiosity to implementation. Our first article introduced ProcessOS’ early momentum and the thinking behind the Great Re-Engineering. Our second looked at what customers are asking as they evaluate process re-engineering for themselves.
This installment goes one level deeper. It looks at how ProcessOS gets implemented inside a customer's environment, and the team responsible for making that happen: forward-deployed engineering.
A co-innovation model
Forward-deployed engineering at Camunda starts from a simple premise. Every engagement is an opportunity to improve ProcessOS, not just to configure it for a single customer. Our forward-deployed engineers approach each project with a co-innovation mindset, assuming that the work will bring up something worth changing in the product, whether that is a user experience improvement or an entirely new capability.
The industry uses the term "forward-deployed engineering" broadly, and it covers two very different models. One is professional services with a new label attached, where a consultant works alongside the customer but the product itself stays fixed. The other is engineering talent that actively changes the product while working with the customer.
Camunda's forward-deployed engineers operate in the second category. We spend time in a customer's environment, learn how that organization runs, and then customize and extend ProcessOS to match. The result benefits both sides. Customers get a solution built around their specific needs, and Camunda gets a direct signal on where the product needs to grow.
Customizing through skill files
Every organization runs differently, and ProcessOS accounts for that through skill files extensions, which capture how a specific customer's teams and processes operate. Our forward-deployed engineers customize these skill files for each engagement, tailoring the underlying capabilities to the customer's organization rather than forcing a generic template onto a unique environment.
That same flexibility extends to the underlying LLM. Our forward-deployed engineers build out support for existing LLMs or tech stacks. The goal is a product that works with the AI environment a customer already has, and that can adapt as those preferences change over time.
Choosing where to start
A ProcessOS engagement typically begins with one process, and forward-deployed engineers are deliberate about which one. The choice usually has less to do with scale and more to do with readiness.
Teams look for a process that is genuinely ripe for modernization, one that can demonstrate real value quickly and give the customer a concrete case to build on internally. From there, customers often plan to extend ProcessOS across a much larger set of processes, sometimes numbering in the hundreds, particularly when they are moving off a legacy BPM platform. As that scope grows, customers often bring in Camunda's forward-deployed engineers or a partner to help carry the work forward.
What these engagements have taught us
Camunda treats every forward-deployed engineering engagement as a source of product direction, and a few specific improvements have come directly out of that work.
The way ProcessOS structures its underlying harness changed as a result of these conversations, moving toward an approach that works consistently across LLM providers rather than favoring any single one. AI governance has also evolved. Camunda controls how agents operate and how each phase of a process begins and ends, and forward-deployed engineering work pushes that governance layer to capture more data and give customers deeper observability into what is happening at every step.
A newer capability is also taking shape directly from these conversations is a way to evaluate which LLM best suits a given process, weighing both token cost and accuracy. It reflects the same pattern the entire program follows, where field engagements find real needs, and those needs shape what ProcessOS becomes next.
Helping customers tell their AI story
Executive teams increasingly hand down a mandate to do more with AI, often without a clear picture of what that means in practice. Several customers have asked their forward-deployed engineering team to help answer that question directly. Because ProcessOS identifies exactly where the process needs agentic behaviors, and just as importantly, where deterministic execution is the better fit. It gives customers a concrete way to show where AI is creating value, whether that manifests itself as time saved, improved quality, or stronger regulatory rigor. The story becomes twofold: customers use AI to re-engineer their processes faster, and the processes that come out the other side have AI built into how they run.
One trend has stood out across recent engagements: interest in ProcessOS is increasingly coming from the line of business rather than IT alone. Re-engineering with ProcessOS speaks in terms that are closer to how the business actually operates, which makes the conversation more approachable for teams that do not think in technical terms day to day. Line of business leaders are often the ones absorbing the cost of legacy processes firsthand, which gives them a direct stake in seeing those processes modernized. IT remains an essential partner in these engagements, and forward-deployed engineers today play an important role in bridging the two. Over time, as ProcessOS becomes more intuitive, business teams are likely to take on more of that work themselves.
What comes next
Forward-deployed engineering is how ProcessOS moves from concept to production inside a real environment, and it is also how the product keeps improving. Our knowledge from each engagement feeds back into the platform, which means each customer benefits from what we’ve learned in the past. As ProcessOS moves toward general availability, expect that feedback loop to keep shaping where the product goes next. Stay tuned for our next ProcessOS blog for more information.
