Imagine you're an enterprise architect, and the business side wants a few AI agents to:
- Approve routine claims
- Route a flagged transaction
- Triage a support ticket before a human ever sees it
Before you agree, what do you actually need in place?
You know the model can reason well enough. That isn’t the issue. What matters is whether the agent operates within the guardrails the process enforces (deterministic checks, escalation paths, SLAs), and if you can show exactly what the agent did and why the moment someone asks.
If you can't answer that with confidence, you don't have a pilot problem. You have an architecture problem.
That's the gap this release is built for.
Value at a glance
Start with the agent itself. You can now watch its execution state live on the process diagram in Camunda Operate, whether it runs natively on Camunda or through a framework like LangGraph or CrewAI.
Zoom out a level and the same discipline applies to what your agentic orchestration runs on. You can split an orchestration cluster into physical tenants for fully isolated runtime environments, each with its own engine, storage, and endpoints. No need to stand up a separate cluster per business unit or regulatory domain.
Trust also has to survive change. Decision version selection as a FEEL expression lets a business rule task resolve which DMN version to call at runtime, so a rule change no longer forces a redeploy. Multi-instance activity execution listeners restore a collection-preparation pattern many Camunda 7 migrations depended on, so migrating doesn't mean redesigning the process either.
It shows up in everyday habits too. In Web Modeler, deleted files now get a 30-day recovery window instead of disappearing for good, with version history that stays intact, while a reworked append pad makes building out a process faster.
None of that is a coincidence. Every one of these features closes the same gap. Agents already reason well enough. Production infrastructure hasn't caught up enough to prove it's safe to let them act.
The automation ceiling is an architecture problem, not an intelligence problem
Most organizations running AI agents today haven't gotten past the pilot stage. Not because the agents can't do the work, but because coordinating them safely in production takes something most teams haven't built yet: isolation, observability, and versioning discipline.
Most pilots skip that discipline because none of it shows up in a demo. It shows up later: when compliance asks who approved something, when one tenant's agent workload starts degrading another team's process, or when a rule change needs a redeploy at exactly the moment you can't afford downtime.
Camunda 8.10-alpha3, now available for download, doesn’t have one headline capability. It's about solidifying the foundation, the isolation, observability, and versioning discipline described above, that lets an architect actually sign off on running agents in production. SaaS customers who are up to date may already see some of this automatically. Here's what matters and why.
AI agent visibility and explainability
This goes straight to the trust question. Today, when an agent runs inside a process instance, everything about its behavior technically exists: what it's doing, which tools it's calling, what it decided. But the information is often buried in process variables and reference documents that were never designed for operational use at 2 a.m. during an incident. To find out if an agent is reasoning, calling a tool, or just stuck, you'd have to parse a large JSON structure and mentally reconstruct the agent’s state from the raw data. Token consumption, tool call counts, and guardrail proximity are not surfaced and there is no way to detect an agent approaching its limits until it has already failed.
That gap has real costs. When an agent approves a loan, flags a transaction, or routes a request, nobody can explain why afterward. No decision trail means no way to validate the call, debug what went wrong, or hand a regulator proof the right controls were applied.
Operate now surfaces this directly. You see an agent's execution state (thinking, calling a tool, idle) highlighted on the process diagram itself, alongside its live tool calls, usage metrics against its configured limits, model, and system prompt. You can also trace the full reasoning chain behind a completed run: user prompts, assistant messages, which tools the agent chose and why, and the tool calls themselves, each one linked back to the diagram element it belongs to. Agents built in external frameworks such as LangGraph or CrewAI get the same visibility through the new Agent Instance API, so this isn't limited to agents modeled natively in Camunda.
Camunda is putting this in front of customers now specifically to get feedback before it ships in Camunda 8.10. If agent governance is on your roadmap, this is worth trying now, not after general availability, while there's still time to shape it.
This is just a start. More coming on agent visibility and explainability.
Strong isolation without a fleet of clusters with Physical Tenants
If you run Camunda as shared infrastructure across business units, customers, or regulatory domains today, you've likely faced a binary choice: put everyone on one orchestration cluster and accept noisy-neighbor risk and data comingling, or run a separate cluster per domain and accept the infrastructure, licensing, and operational cost of maintaining a fleet. Neither scales exactly like you need. One shared cluster means a heavy workload in one tenant degrades response times for everyone else. Separate clusters mean independent upgrades, backups, and monitoring, multiplied by however many domains you have.
Physical Tenants, available as a preview in alpha3, lets you carve a single orchestration cluster into fully isolated runtime environments. Each physical tenant gets its own dedicated process engine (its own Raft group and partitions), its own secondary storage, its own document store, and its own web application access. Workloads share broker infrastructure but nothing else: one tenant's load doesn't affect another's throughput, and data does not cross tenant boundaries.
A few specifics worth knowing if you're the one designing this:
- Every REST endpoint is namespaced under
/physical-tenants/<physicalTenantId>/v2/, and the gRPC API carries the tenant ID in a header, so clients target a specific tenant explicitly rather than relying on client-side routing logic. - Operate and the Admin application are each reachable per tenant at
<baseurl>/physical-tenants/<physicalTenantId>/<webapp>, giving operators a scoped view with no cross-tenant data exposure. - Authentication can be configured per tenant. Multiple OIDC providers can be assigned to individual physical tenants, so each one can use its own identity provider.
- Relational database storage supports three deployment modes: separate databases, a shared database with separate schemas, or a shared database with separate table prefixes, so you can match whatever data governance model your organization already requires.
The full feature ships in Camunda 8.10. But the architecture direction is the point: Camunda is becoming a platform that can genuinely host multiple isolation domains on one set of infrastructure, instead of asking you to choose between shared risk and duplicated cost.
Decision version selection as a FEEL expression
Here's a smaller change with an outsized architectural effect. A business rule task can now resolve which DMN decision version to call using a FEEL expression evaluated at runtime, instead of a version number baked into the process model.
Previously, calling a different rule version meant redeploying the process. If your business logic needed to branch (legacy product line versus current, region A versus region B), you either maintained separate process variants for each rule version, or used the "latest" binding and gave up control over exactly which version ran. Neither is a comfortable place to be when a version change carries real business consequences.
Now the version tag accepts an expression such as = decisionVersion or = if productLine = "legacy" then v1 else v3, resolved from process instance variables at runtime. Different instances of the same process can call different decision versions without a redeploy. If the expression resolves to a version that doesn't exist, an incident is raised with the evaluated value included, so diagnosing it doesn't mean guessing. Existing processes using static versions or "latest" continue to work unchanged.
Architecturally, this is what composability looks like at a small scale: decoupling how a rule evolves from how a process is deployed. That's the same principle Physical Tenants applies at the infrastructure layer, just applied here to decision logic.
Recently deleted: soft delete in Web Modeler
Deletion in Web Modeler used to be immediate and irreversible. Deleting a file inside a process application could retroactively corrupt earlier version snapshots, so your version history couldn't always be trusted even when nobody made a mistake.
Deleted projects, files, folders, process applications, and identity provider applications now move to a Recently Deleted view for 30 days before they're gone. Deleting a container cascades to its contents as a single event, and that event expands to show exactly what went with it, without silently undoing an unrelated deletion made earlier on its own schedule. Restoring something puts it back where it lived if the parent still exists, recreates the parent if needed, and won't restore an item inside a deleted project until the project itself comes back. Version history integrity is also fixed at the source: deleting a file removes it from the live project, but existing process application snapshots keep referencing it correctly.
For the cases where a file genuinely needs to disappear for good, for a compliance-driven data removal request, for example, a new API-only purge endpoint permanently strips it from all version history. It's deliberately not exposed in the UI, given how irreversible and history-rewriting that action is.
This is the kind of governance detail that matters the first time an audit asks who deleted what and when, and you actually have an answer.
Multi-instance activity execution listeners
If you migrated from Camunda 7, you may have relied on execution listeners to build a multi-instance collection dynamically from process variables, business objects, or an external system. In Camunda 8, there was no point in execution where you could prepare that collection before it got evaluated, which quietly broke a migration pattern some teams depended on.
A beforeAll execution listener now runs once on the enclosing multi-instance body, before inputCollection or loopCardinality gets evaluated and before any instances are created. Variables the listener produces are available to both. If you support lean-state architectures where collections get resolved at runtime from references rather than stored as large payloads, this restores the pattern without forcing you to redesign the process around its absence.
A reworked append pad in Modeler
Building a process is fundamentally a repeated "add the next step" action, and that action used to be mixed into the general context pad and the palette, without a clear, simple home of its own. Selecting a flow element now surfaces a dedicated append pad right next to it, with one click to the most common next elements (task, gateway, intermediate event, end event) and a "+" to reach the full set.
It's available by default in Web Modeler, and opt-in in Desktop Modeler via Settings > Enable new context pad. It might not change your architecture, but it will save you some clicking.
What to actually go try
If you're evaluating whether Camunda can carry real operational authority in production, alpha3 gives you three things worth testing directly rather than reading about:
- Stand up Physical Tenants in a test cluster and check whether its isolation model matches your actual compliance boundaries, not just your org chart.
- Watch a live agent run in Operate, including a case designed to fail or loop, and see whether the trace actually gives you what you'd need during a real incident.
- Rewire a business rule task to resolve its DMN version from a FEEL expression, and confirm the incident behavior is clear when the expression resolves to something that doesn't exist.
Both Physical Tenants and AI Agent Visibility are previews specifically because Camunda wants your feedback before they ship in Camunda 8.10.
Where this is headed
Together, these features are what it looks like to build the architecture underneath agentic orchestration in public, in the order enterprises actually need it: isolation first, then visibility, then the composability to let rules and processes evolve independently. That's the difference between an agent that performs well in a pilot and one you can actually put in charge of a process that matters.
Review the full release notes for everything else that shipped this month. If you try Physical Tenants or AI agent visibility, Camunda wants to hear what you find, good or bad, before 8.10 ships. Contact us directly or drop your notes on the forum.
Ready to orchestrate?
