This guide is for anyone who builds or runs AI agent workflows and gets an agent analysis back. It explains every part of the report, so you can read one and know what to fix.

An agent analysis reads the record of an agent’s workflow (its trace) and checks each step in two passes. First, fixed rules flag possible problems. Then a reasoned review looks at some of the flagged items: what the step was for, whether it did that, and where a problem started. Each finding gets a severity, which says how big its effect is. The same labels appear in the dashboard, in the report, and in what your agent gets back over MCP (the connection that lets your agent call LLM Prover’s tools).

You need: an agent analysis of one of your workflows. Agent analysis is on Pro and above.

What a report shows

A report has four parts:

The workflow: where the trace came from, and how complete it was.
The steps table: one row per step, with its cost, time, turns and tool calls.
The findings: each problem found, with where it is, whether it costs money or time, how sure the analysis is, and what to do.
How far the review got: whether the reasoned review reached every flagged item.

Each finding also says what fixing it saves: money, time, or neither (the “Money, time or context” section below has the full list). Here is one finding from one of our own workflows:

Example finding (from one of our own workflows)

Finding: Uneven work split
Where: the three workers that ran side by side (436, 345 and 225 seconds)
Fixing it saves: time
What to do: split the work by expected effort, not by count

Insight: Every finding says what to do about it. Start with the high-severity findings that save money or time.

The workflow

Source: where the trace came from: Kiro or Claude Code.
Trace completeness:
- Full: every step’s transcript was present.
- Partial: some steps had none, so some checks were skipped for those steps.

The steps table

Column	What it means
Step	The step’s name in the workflow.
Role (inferred from step name)	Inferred from keywords in the step name; see the roles below.
Cost	What this step cost, in the workflow’s own unit.
Time (s)	Wall-clock seconds from start to finish.
Turns	Times the model thought and decided.
Tool calls	Actions it took: reads, fetches, searches, edits.
Failed calls	Actions that returned an error.
Memory used (peak %)	The most of the model’s working memory the step used at once.

Roles are inferred from the step name, so treat them as a hint:

Role	Usually
Planner	Plans or splits the work.
Worker	Does the main work with tools.
Checker	Checks or grades results.
Summariser	Summarises or reports.
Classifier	Sorts items into categories.
Extractor	Pulls fields out of text.
Other	Role not recognised from the step name.

The findings, and what to do about each

Finding	What it means	What to do
Uneven work split	Steps that run side by side got very different amounts of work, so the workflow waited on the slowest. This costs time, not money: the same work is done either way.	Split the work by expected effort, not by count, or let finished branches pick up remaining items.
Same documents read by every step	Several steps each loaded the same files on their own, so that reading is paid for once per step.	Read shared documents once and pass the content, or a summary, to the steps that need it.
Caused by an earlier step	A problem seen in one step traces back to an earlier step’s instruction or output. The fix belongs where the problem started.	Change the earlier step named in the finding; the later step should then improve on its own.
More turns than needed	The step took far more turns than an identical step in the same workflow. This usually means vague instructions, repeated work or harder input, and harder input can be a fair reason.	Tighten the step’s instructions, with a clear stop condition and fewer optional checks, or spread hard items across steps.
Step produced nothing	The step spent money but produced no usable result. This is only waste if the step failed; an honest empty result is marked “examined, not waste”.	Check the step’s input and stop conditions. If it failed, fix the input or add an early exit.
Kept going after repeated failures	After several failures in a row, such as every fetch failing, the step carried on and kept spending.	Add a stop condition, for example “after 3 failures in a row, stop and report”.
Same call repeated	The step made the exact same tool call more than once. Identical calls return the same result.	Reuse the earlier result, or tell the step to keep track of what it already fetched.
Retry loop	The same call failed several times in a row and was retried unchanged.	Cap retries, and change approach (a different input or tool) after a failure.
Working memory nearly full	The step used most of the model’s working memory. Models then drop or confuse earlier details, and steps slow down.	Pass less into the step, summarise earlier results, or split the step.
Largest cost	The step accounts for a large share of the workflow’s cost. This is information only.	Start any cost work here, and read the other findings on this step for the reasons.

Make your agent workflows faster, cheaper and more reliable

An agent analysis checks every step of a workflow and shows where it wasted money, time or effort, and what caused it. On Pro and above.

See Pro

Where a finding sits

Findings are grouped by the kind of problem:

Group	What it covers
Root cause	Links a symptom to the earlier step that caused it.
Value of the work	Steps that produced nothing or kept going without progress.
Shape of the workflow	Problems in how work is split and shared between steps.
Within one step	Repeated calls, retries, extra turns and memory use within one step.

Money, time or context

Label	What fixing it does
Cost	Saves money: work can be removed, so fewer credits are spent.
Time	Saves time, not money: the same work finishes sooner and the workflow’s cost in credits is unchanged.
Info	Context, not a saving on its own; it helps explain other findings.

Cost and time are reported separately and never added together.

Insight: A “Time” finding makes the workflow finish sooner but does not lower what it costs. A “Cost” finding lowers what it costs.

How sure the analysis is

Status	What it means
confirmed	Measured directly from the workflow by fixed rules, with no judgment needed.
judged	A reasoned review looked at what the step was for and confirmed the problem.
examined, not waste	It looked like waste, but the review found a good reason, for example an honest empty result.
examined, unclear	The review could not tell either way; treat it as a lead.
not reviewed	Flagged by the rules, but the plan’s review limit was reached before this item; treat it as a lead.
review rejected	The review’s answer was unusable and was discarded, so the item stays an unconfirmed lead.

How big the effect is

Severity	What it means
high	Large effect on cost or time.
medium	Noticeable effect.
low	Small effect.
info	Context only.

How far the review got

The report says why the reasoned review stopped, and what to do if it stopped early:

Reason	What to do
every flagged item was reviewed	Nothing; the review is complete.
the plan’s review limit was reached	Larger plans review more items per analysis.
your balance or monthly limit was reached	Top up or wait for the monthly reset, then use Continue review to finish the remaining items.
the time limit was reached	Use Continue review to finish the remaining items.
the rate limit was reached	Wait a few minutes, then use Continue review to finish the remaining items.
the review model was unavailable	Later, use Continue review to finish the remaining items.

Continue review checks only the items not yet reviewed, using the stored step data, so you do not need to upload the trace again. Analyses made before Continue review was added cannot continue; analyse those workflows again.

Insight: “not reviewed” items are still worth a look: the rules flagged them, the review just did not reach them.

Agent Analysis Guide