Camunda 8.10 and ProcessOS — From Process Documentation to Governed Automation with AI

ProcessOS helps with the first task. Agent orchestration, testing, and monitoring capabilities address the second. Engineering work still connects the two: validating models, integrations, and the solution's behavior.

Product status is crucial here. The release of Camunda 8.10 does not mean that ProcessOS has reached General Availability (GA). At the time of writing, it is available in Early Access. 

Why Rethink a Process Before Introducing AI

Adding an agent to a poorly documented process will leave some problems in place: unnecessary approvals, unclear authority, and manual data handoffs. It therefore helps to start with the business outcome: which decision needs to be faster, which errors should be reduced, and where human involvement is required.

For example, when handling an application, an agent could prepare a recommendation, while mandatory eligibility checks and final approval remain separate steps. This is an architectural example, rather than a ready-made scenario that becomes available after upgrading the platform. The team must design the rules and boundaries of authority itself.



An example from the Camunda 8.10 announcement: a next-step suggestion and reuse of the Check Lending Policy component. Source: Camunda.

How ProcessOS Helps Turn Existing Materials into a Solution

The Early Access announcement describes the journey in three stages: Discover, Re-engineer, and Build. The team supplies existing process materials, validates the reconstructed model, discusses changes, and receives a project for further development. 

Discover — Reconstruct the Current Process

ProcessOS can use materials such as exports from conversations, project tools, and documents. It builds a BPMN model from this material and identifies gaps. Questions are sent to a process expert through Tasklist, and the answers help refine the result. Because this work relies on the supplied context and on people, the quality of the source materials has a significant effect on the model's usefulness. 

Re-engineer — Agree on the Future Process

After validating the current model, the team considers the future process, from small improvements to a more substantial redesign. Migration can also follow a lift-and-shift approach: moving the existing process without rethinking it first. At these stages, the models support discussion and are not yet an executable solution. 

Build — Prepare Executable Artifacts

Implementation produces models and supporting artifacts: BPMN, DMN, forms, and code. Developers review and test the output and complete the necessary parts. Receiving a generated project does not remove the need for technical acceptance. 

The ProcessOS Harness documentation breaks the journey down into four phases: Scope, Discover, Transform, and Implement. Scope explicitly defines the boundaries of the work. Expert review cycles take place between milestones; the governance process runs on Camunda, and artifacts are committed to Git. The blog's three stages and the Harness's four phases describe the approach at different levels of detail. 

The Limitations of ProcessOS Early Access

The Early Access terms also apply: the product is not yet intended for production, its APIs, dependencies, and configuration may change, and it is neither feature-complete nor covered by a maintenance service. Support is provided on a best-efforts basis, and upgrades to subsequent releases are not guaranteed. This status is intended for evaluation and feedback before GA. 

Who Takes Part in a Pilot

A pilot needs a technical specialist to lead the project and an expert who understands the process's actual rules and exceptions. Both should be able to read BPMN. The supported AI coding tools are Claude Code CLI and GitHub Copilot CLI. The instructions cover installing the Camunda CLI and the appropriate Harness bundle, and creating a version-controlled project. Only one bundle for the selected agent can be installed in a project at a time. 

Camunda Hub Brings Teams Together

Camunda Hub replaces Web Modeler and Console, becoming a shared point of access for working on process solutions. Workspaces organize team collaboration, while projects bring together a solution's materials. Modeling and management tools are combined in one product. 

The terminology changes also matter during the transition: what was a Project in Web Modeler corresponds to a Workspace in Hub, while a Process application becomes a Project. When planning an upgrade, teams should therefore check how they will find their models and manage access. 

For an organization, this is an opportunity to agree on ownership of shared components and how they should be reused. A unified interface does not determine who is responsible for a template's quality or who approves a process change: those roles still need to be assigned.



Workspaces and environment navigation in Camunda Hub. Source: Camunda 8.10 documentation.

How Processes Become AI Agent Tools Through MCP

The Processes MCP Server allows deployed BPMN processes to be exposed as Model Context Protocol tools. For automatic registration, a process must use the MCP start event template. A call starts a new instance and immediately returns its key: this is not yet the result of executing the entire process. 

The server uses the authentication and authorization model of the Orchestration Cluster REST API. It must be explicitly enabled for production and several other deployment types. The documentation also states that the Processes MCP Server is not part of the Camunda 8 public API. 

The architectural implication is practical: a business operation can be modeled as a process with checks and exception handling, then made available for an agent to call. However, the permitted operations and the calling client's permissions must be defined in advance.

There is another detail to consider when designing audit logging: by default, the log records user operations rather than client operations. To capture a client's MCP calls, logging for those operations must be enabled. An MCP interface does not, by itself, replace audit configuration. 

How to Test and Monitor Agent Behavior

Operate Shows Execution and Interaction History

Operate lets teams inspect an agent's state, model, system prompt, tool calls, and usage metrics. Conversation history is grouped by iteration, helping connect actions to the inputs and tool responses received. 

However, reasoning is displayed only if the model returns the corresponding content. The interface should not be treated as guaranteed access to every internal reasoning step of any LLM. Some artifacts may require additional configuration. 

The AI agent monitoring panel in Operate. Source: Camunda 8.10 documentation.

Tests Account for Variation in Responses

For an AI agent, checking for an exact string match is often insufficient. Camunda Process Test supports LLM-as-a-judge evaluation and semantic comparison, allowing teams to assess response quality even when the wording changes. 

These checks are useful alongside strict business invariants. For example, an agent must not execute an operation without mandatory approval, and exceeding a limit must route execution to the appropriate process branch. These are recommendations for test design: the team defines quality criteria and permitted actions, and evaluation by another model does not provide an absolute guarantee of correctness.

What to Check Before Upgrading to 8.10

An upgrade requires compatibility checks. Version 8.10 removes the legacy Operate API and Tasklist API, Tasklist V1 mode, and Zeebe Process Test. Affected integrations and tests must use the current replacements, including the Orchestration Cluster REST API and Camunda Process Test. 

The new AI Agent templates also need attention. Legacy templates are deprecated but continue to work. Migration to the new templates is manual for each element; it should not be assumed to happen automatically when the cluster is upgraded. 

Before migrating a working solution, review its APIs, connectors, tests, and supported infrastructure, then run through the upgrade in a test environment. This is a separate task from experimenting with ProcessOS.

Where Companies Should Start

For an initial pilot, it makes sense to choose one clearly bounded process with available source materials and an owner who can validate the model. Before starting, define the expected outcome, mandatory approvals, and acceptance criteria.

Next, validate the current model, agree on changes, assess the generated artifacts, and test the solution in a test environment. A useful pilot outcome is an understanding of which parts of the work the tool accelerated, which required corrections, and what is still needed for a production solution.

Camunda 8.10 provides more tools for this work. ProcessOS offers a way to explore a new development approach, Hub brings the team environment together, and MCP, tests, and Operate help connect AI to governed execution. Responsibility for business rules, integration quality, and the decision to go live remains with the team.

Planning a Camunda upgrade or an AI automation pilot? Talk to Reunico about your process, oversight requirements, and criteria for a successful implementation.