Someone asks why a customer's case was flagged three weeks ago. The answer spans a Camunda AI agent, a LangGraph agent, an LLM judge, and a human reviewer. To reconstruct it, teams typically open the agent framework's traces, the process history, and the application logs, then line up timestamps by hand.
That works once, but you can't repeat it every time an auditor, a customer, or an operations lead asks about a decision an agent was part of. Questions about an agent tend to turn into tickets for a developer. Incidents can take longer to resolve when nobody can see what the agent was doing when it stalled. And regulation such as the EU AI Act increasingly expects you to show how an automated decision was reached.
Once an agent is in production, two questions come up about it constantly: what is it doing right now, and why did it do what it did?
Camunda 8.10 answers them in Operate, for every agent in the process, whether Camunda runs the agent's loop or an external, agentic framework does, and in the same record as the people and systems around it.
Seeing and explaining an agent is one part of running one in production you can trust. It sits alongside the architecture that makes agentic orchestration trustworthy in the first place, the testing that proves an agent behaves the same way across thousands of runs, and the cost controls that keep that behavior affordable. This post is the observability piece: once an agent is live, can you see what it is doing and explain why it did it.
Following one case across agents, people, and systems
Take a customer onboarding process. An application comes in, a screening agent checks identity and sanctions, another agent runs adverse media screening, a smaller model acts as an LLM judge on the agents' output, and any case that needs enhanced due diligence goes to a compliance reviewer before a decision is made.
The screening agent and the adverse media agent are built in different ways:
- The screening agent is a Camunda AI agent, built as an AI Agent sub-process. Camunda's engine runs its loop: the LLM picks a tool, Camunda executes that tool as an element in the process, and the result goes back to the model for the next iteration.
- The adverse media agent is an external agent built with LangGraph. Its loop runs in LangGraph's own runtime. Camunda decides when it runs and what happens with its result, and receives its state through the Agent Instance API.
Visibility is half the story. Because a Camunda AI agent's tools are steps in the process, you can also enforce a must-follow step (a human approval, a policy check) between the agent's decision and its action. Operate then shows both what it did and the guardrail that shaped it.
From the process's point of view, both are steps in the same case, and Operate treats them that way.
Seeing what an agent is doing right now
An agent that has been working on a case longer than usual could be reasoning through a hard problem, calling the same tool in a loop, or a few calls away from its limit. From the outside, you can't tell which one it is.
In Operate, each agent instance has its own section in the Details tab, and its state is highlighted on the process diagram: initializing, thinking, calling a tool, or idle. Next to the state you see:
- Current tool calls: which tools the agent is calling at this moment, so you know what external action is in flight.
- Usage against limits: model calls made against the configured maximum, tokens used, and tool calls. You see an agent approaching its guardrail before it hits it.
- Configuration: the provider, the model, the system prompt, and the tools available to the agent.
An operator answers "is this agent broken?" from the instance view, without filing a ticket. An agent cycling through the same tool with its model calls climbing toward the limit looks very different from one that called its tools and is waiting on a reply.
Explaining why an agent did what it did
Why an agent did something is usually asked later by someone who wasn't watching its execution: a reviewer, a customer, or an auditor. The answer lives within the process instance, in the agent's full conversation history, so you can review the business case end-to-end.
Say a reviewer asks why the screening agent referred a case to enhanced due diligence. You open the process instance, select the agent, and read its oldest history first. The conversation is grouped by loop iteration, each one a pass where the model reasons, picks a tool, and evaluates the result.
In every iteration, you see what the agent was given, which tool it chose and why, and what the tool call sent and got back. The referral turns into a chain of steps you can follow: identity verification, a politically exposed person match from sanctions screening, and the agent's explanation of why that combination required a closer look.
When a step in that chain looks wrong, the tool behind it is an element in the same process, with its own entry in the instance history. Open it to check what the tool received and returned, next to the reasoning the agent gave for calling it. If the problem is the tool rather than the model, that's where you look next.
Cases rarely pass through an agent only once. If the reviewer sends the case back for more information, the process loops back to the agent, and the agent instance continues the same conversation with its memory intact.
The record also holds up when the infrastructure doesn't. Agent messages are marked pending, committed, or discarded. If an agent's job fails partway, for example, after a network drop or a crashed worker, the retry may pick a different tool and give a different reason. Only the messages from the run the engine actually acted on are committed, so the history shows what actually drove the process, not what an interrupted run said it was about to do.
Bringing external agents into the same view
Enterprises rarely build every agent on one stack. One team picks LangGraph, another a different framework, a third builds its agents in Camunda, and many of those agents are in production before anyone decides how to govern them.
Camunda is open and composable by design: it orchestrates the agents you already have, regardless of which framework built them, and keeps the process logic independent of that choice, so you can swap an agent runtime or a model without redesigning the end-to-end process.
Visibility has to follow the same principle. If only one kind of agent shows up in the record, the audit trail has a gap wherever the other kind sits. So the adverse media agent running on LangGraph appears in Operate with the same section as the screening agent: state, usage, system prompt, tools, and conversation history.
The interaction model is simple. The external agent's loop keeps running in its own runtime. As it works, it reports its state and conversation to Camunda through the Agent Instance API, and Camunda attaches that record to the element the agent belongs to, in the same process instance as the deterministic steps, the people, and the Camunda AI agents around it. An operator doesn't need to know which framework built an agent to see what it's doing or why.
How much you see depends on what the framework exposes. A LangGraph agent can report everything a Camunda AI agent does, so the two look the same in Operate. A framework that doesn't expose its metrics through an API still shows what it reports, such as its state and conversation, without the usage numbers.
Auditing the whole business case in one place
An agent's own trace answers part of the question. The rest sits around it: what the judge concluded, who reviewed the case, whether someone retried a failed step or changed a variable before the decision went out. Some approaches to agent observability stop at the agent. Camunda records the agent as one participant in the business case, next to everything else that touched it.
In the same process instance view you have:
- The execution timeline: every element, retry, and escalation in the order it happened, agents included.
- Each agent's decision trail: the conversation history, for Camunda AI agents and external agents alike.
- The Operations Log: who completed the review task, who modified, migrated, or canceled the instance, who resolved an incident or updated a variable, and when. When an agent performs an operation on behalf of a user or client, the log records the agent as well.
Across the cluster, every agent definition deployed with a process, Camunda AI agent or external, is registered and queryable, so you have a list of every agent running in your processes.
That's the difference between explaining an agent and explaining a decision. When the question is "why was this case flagged," you open one process instance and follow it from the application to the outcome, through every agent, person, and system that touched it, without exporting traces from one tool and matching them against logs from another.
Real-time agent visibility is available in the Camunda 8.10 alphas today and ships with Camunda 8.10. Pick one agent you already run, open one of its process instances, and see if you can answer both questions without leaving it.
Check out this video that shows you how you can access this real-time agent visibility.
Be sure to check here to learn more about agent observability in Camunda.
Explaining a decision is one leg of running agents you can trust. The architecture underneath decides whether an agent's decisions can be trusted at all, testing proves it behaves the same way across thousands of cases, and cost visibility keeps it from getting there by spending without limit. Seeing and explaining what an agent did is what holds once it is already live.
Next in this series: once you can see every agent in a single case, how do you tell if it behaves the same way across thousands of them?