Monitor agent runs and read traces
Every execution of an agent is a run, and every run keeps a trace. Runs are grouped into sessions: one conversation, trigger, or API call read as a whole. The Observability section collects sessions from every agent in one place so you can find the one you care about and read what actually happened inside each run.
When an agent answers oddly, the trace tells you where: bad retrieval, a wrong tool argument, or a policy that transformed the payload.
Find a session and its runs
-
Go to the Observability section under Runtime in the navigation panel.
-
Review the counters above the list: Total sessions, Running now, and Needs attention.
-
Narrow the list with the filters above it. They carry no labels, so each one reads as its current value, such as "All statuses."
Filter
Values
Status
"All statuses," "Running," "Completed," "Failed," or "Cancelled."
Environment
A single environment, or all of them.
Initiator
Who or what started the run. A run started by someone who is not a Creatio AI Studio user, such as a web chat visitor, reads "External participant" followed by a short identifier. A run started by a scheduled trigger reports "Scheduled" and carries its planned fire time. Scheduled triggers are enabled per organization and appear only where they have been turned on. Learn more: Start an agent with a trigger.
Started from, Started to
The date range the run started in.
Sort
Newest or oldest first, or by agent type or agent name.
Error state, Type
With or without errors, and the agent type.
Use the search box to find a run by agent name.
-
Click View details on the session you want to inspect.
The session page shows the whole session, for example, its Active duration, and lists every run of the session in the Turns table. To inspect a run, click Open run in its row.
As a result, the list narrows to the sessions that match. Each session shows its agent, initiator, environment, agent version, and number of steps. A session with failed turns shows how many, for example, "2 failed turns."
Read the run overview
The General run information section identifies the run: its last activity, initiator, environment, agent version, and the times it started and completed. The run details also show the agent's prompt. It is the agent's current prompt, which can differ from the prompt an earlier run used.
The tiles above it give the outcome and the size of the run — Status, Duration, Tool calls, Model calls, and AI Credits used. Model calls counts every model call in the run, including the calls the platform makes on its own, such as memory updates. When there are such calls, the line below the count splits it between the agent and the platform. Click Show all metrics for Timeline events, Handoffs, Billed model calls, and Policy events. The Policy events tile is where a governance action such as a PII mask shows up. Learn more: Review policy decisions.
A run that timed out before the platform captured anything reports "Execution capture unavailable." If the timeline itself could not load, the step-derived metrics show a dash instead of a count — that is a loading failure, not a run with no steps.
Drill into a span
The Execution timeline lists every span of the run in the order the steps happened, each tagged with its category: Tool, LLM, Memory, Skill, Policy, and so on. When the agent works through multiple cycles in one run, a divider such as "Iteration 2" marks each cycle and shows its step count and duration. The timeline also shows the following:
- Each memory step, inside the iteration that triggered it.
- Each PII protection check, next to the model call it preceded.
- Each knowledge source search, each use of the built-in tools that list, read, or search files attached to the conversation, and each time the agent opens a skill it already opened.
- The outcome of each tool call. A tool call that fails inside a completed run shows as failed, including an MCP tool that reports an error and a failed call of an attached-file tool.
- A model call whose answer was cut off, timed out, was cancelled, or ended with a provider error, as a failed step with its error.
Older runs can show fewer of these steps.
-
Click a span in the timeline.
-
Review its detail in the panel.
- Input / Output — exactly what the step received and returned.
- Metadata — the event type, category, timestamp, trace ID, and the error, if there was one. On a model call, Available skills lists every skill offered to the model.
- Raw payload — the unformatted structure behind the step.
- Tools — on a model call, the tools the model could choose from at that point, listed under "Available tools," up to 100 entries. When more were sent, the tab reads "Tool list truncated at 100 entries." It does not appear on other span types.
As a result, you can see the precise input that produced a bad answer, instead of inferring it from the reply.
A payload can be hidden for your role. The span then reports "Payload hidden for your current role" rather than showing empty input — that is an access restriction, not a missing step. Reading step content for a run you did not start requires the Read run step content permission; without it, every step, count, duration, and status stays visible and only the content is hidden. Out of the box, only the Administrator role has this permission. Users with other roles, for example, Developer or Individual Contributor, see step content only for runs they started until you add the permission to their role on the Roles tab of the Security section. Learn more: Create a role and assign permissions.
Diagnose common symptoms
Symptom | What to look for in the trace |
|---|---|
The agent answered from general knowledge instead of your content | No span reading the source. The knowledge source is unattached, still fetching or failed, or its description is too vague for the agent to pick it. |
The agent ignored a procedure you wrote | No skill span. The skill is unattached, disabled, or its published version is not the one you edited. |
A tool failed or returned nothing useful | The tool span's input. The arguments the model supplied are usually the problem, not the endpoint. |
A value reached the model that should have been masked | The model input and the policy events. If the raw value is present, the policy did not cover that entity type. |
The run failed without doing any work | A usage limit. A run that a usage limit refused is recorded with the Failed status, including a run refused before it started, so check the budgets on the Usage analytics page. Learn more: Set a usage budget or spending limit. |
The run stopped partway through | A failed LLM span. A model call whose answer was cut off, timed out, was cancelled, or ended with a provider error shows its error, for example, that the model provider is unavailable. In that case, try the run again later. |