Enterprises can build AI agents. Getting them trusted enough for production is the harder problem, and it takes testing, observability, and explainability working as one system.
At Camunda, we talk to a lot of enterprises trying to get AI agents into production right now, and the same story keeps coming up.
An agent works beautifully in the demo. Then it goes live, makes a decision about a real customer, and the first hard question arrives: why did it do that?
Say an agent declines a loan application, and the applicant calls to ask why. Operations pulls up the process data and the agent's logs: pages of reasoning text with no clear decision point and no record of which policy rule fired. Nobody can give the applicant a straight answer.
The gap between the pilot and the payoff
According to Camunda's 2026 State of Agentic Orchestration and Automation Report, 71% of enterprises are running AI agents somewhere in the business today, in pilots, sandboxes, and limited trials. Only 11% have put a single one into live production, making real decisions about real customers, and 85% say they don't have the process maturity to make that jump.
Every one of those pilots already proved the agent could do the job under controlled conditions. The missing process maturity comes down to one crucial thing: trust. Once an agent starts making decisions inside a live business process, the people responsible for it can't say how it will behave, what it’s doing right now, or why it did what it did.
The same questions come up in every enterprise conversation about deploying an agent into production, often from a different person and at a different moment:
What it costs to fly blind
Some enterprises don't wait until they have answers to all these questions. They push agents into production without them, and the costs start showing up.
- The regulatory cost comes first. The EU AI Act requires auditability, explainability, and human oversight for high-risk AI systems. If you get transparency wrong then the penalty can reach 3% of worldwide annual turnover or €15 million, whichever is higher. An agent that cannot explain a decision it made about a customer is not a technology risk anymore; it’s a regulatory liability waiting for an audit.
- The commercial cost is the one a board asks about. Every quarter an agent sits in proof-of-concept, a competitor spends that same quarter shipping it, and the CFO wants to know why the AI budget hasn't turned into anything measurable yet. We've sat in enough of these reviews to know "it worked in the demo" gets you one meeting. It doesn't get you a second.
- The operational cost is the one teams underestimate until they are living it. A single business case, a claim, a loan, an order, moves through people, systems, and agents together, but the tools built for each side don't talk to each other: an agent framework logs what the agent did, a human-in-the-loop tool logs what the person approved, and neither records the handoff between them. A human steps in to approve or override the agent's decision (the exact moment an auditor will later ask about), and that is where the story splits: the agent's reasoning sits in one system, the human's decision sits in another, and nothing ties them into a single record of what happened. Visibility disappears right where a business case runs: at the handoff between a person and an agent.
Test it, see it, explain it
Camunda's answer starts from those questions, not from a feature list. We call it Production Agentic Trust, the part of agentic orchestration that makes it safe to run in production. Three things have to hold at once. You prove how an agent behaves before it ever reaches a customer. You watch what it is doing while it runs. And every decision it makes leaves a record you can hand to an auditor.
Test it: proves how an agent behaves before it ever touches a live customer, and it has to answer a harder question than most testing does. The same agent, given the same input, can make a different, equally defensible decision twice. That is not a bug to fix. It is how these systems work, so testing an agent means running it many times over the same scenario and checking that the spread of outcomes stays inside what the business considers acceptable, not checking that one run passed. Statistical methods do that work: measuring how often an agent's decisions vary, how far they vary, and whether that variance shrinks or grows as the agent changes.
See it: means an operator can watch what an agent is doing while it is doing it, rather than reconstruct it afterward from a log file. That view starts with the system prompt and the model the agent is running on, so the context behind its behavior is visible, not assumed. It covers the conversation between the agent and whoever or whatever it is serving, and every tool call with its input and output. And it extends to the tools the agent had available but chose not to call: an agent that never uses the escalation path it was given is a different risk from one that was never given an escalation path at all, and only seeing what it could have done tells the two apart.
Explain it: means every decision leaves a record automatically, built to answer the questions a regulator or an auditor asks: what context the agent was working with, which tools it called, whether it escalated when it was uncertain instead of guessing, where a human stepped in, and why it landed on the outcome it did. The guardrails in force at the time are part of that record too: the approval thresholds, escalation rules, and limits that applied when the agent acted, not a policy filed somewhere else. That is possible because Camunda governs an agent on two levels at once, how it participates as one part of a larger business process that already includes people and other systems, and what it is allowed to do once it decides to act. When a regulator asks why a decision was made, or an operations lead asks where a case is, the answer already exists.
None of that has to be rebuilt every time a new agent ships, either. The same record that explains one decision rolls up into a running view of how an agent performs across hundreds of them: escalation rates, how its behavior drifts as volume climbs, whether this week's version is holding up as well as last week's. That answers the question nobody asks in week one: is this still working well?
What everyone else gives you
Most of the tools enterprises already own solve one piece of this and stop. Monitoring tools built for IT operations show you whether a system is up, not why an agent chose one path over another. Workflow and case-management tools show you a log of what ran, but that log stops at the edge of whatever built the agent: chain agents from two different frameworks into the same business process, and each one only accounts for its own half of the story. Point solutions for testing, for observability, and for compliance evidence exist too, each sold separately, each covering its own slice.
Nearly half of enterprises, 48%, say their AI agents operate in silos, never woven into the end-to-end process around them, according to the same Camunda report. Enterprises already running agents from more than one framework feel this blind spot directly: an agent built on an open-source framework hands off to a human approval step, which then feeds a second agent built entirely in-house, and nobody has a single view across the deterministic steps, the people, and the agents all sitting right next to each other in the same process. Assembling that view by hand, across three different tools' worth of logs, is a full-time job, and it is one every enterprise scaling past a handful of agents ends up hiring for.
What Camunda gives you instead
The alternative is a platform where testing, seeing, and explaining an agent are one system, built for how agents behave: capable of a defensible decision on one run and a different, equally defensible decision on the next.
This approach answers all of it in one place. . Camunda shows the whole process as a single view: the user tasks a person completes, the services a system calls, the Camunda AI agents, and the agents built entirely somewhere else (in LangGraph, or a custom Python script a team already shipped) that Camunda orchestrates as a step in the same process. Chain an externally built agent into a Camunda process and it shows up next to the native ones: same conversation view, same audit trail, not a black box with a line in and a line out.
Most tools can only audit what they built. Camunda audits the process instead, whichever agent framework is doing the work inside it: one place where the agent's decision, the human's approval, and the process around both of them stay connected, instead of scattered across three systems that do not talk to each other. That is the difference between watching an agent and watching the business process the agent is part of.
Getting agents into production this year comes down to one thing: answering all four questions for every agent, every time, without pulling a team into a room to reconstruct what happened. The fanciest model doesn't help you there, but Production Agentic Trust does. It's built to close exactly that gap, and getting there today puts you ahead of nearly everyone still stuck in pilot.
Next in this series: what does it mean to test an agent that can make a different, equally defensible decision on the same input twice? That is post two, coming soon.
