Loop Evaluation, Observability and Anti-patterns¶

A final answer is not enough¶

In an agentic system, we care not only whether the final result is good, but also:

how did the run get there?
how many actions were needed?
which tool failed?
were retries unnecessary?
were permission boundaries respected?
was human approval appropriate?
how much did it cost?
how long did it take?

Agentic evaluation therefore has two levels:

Outcome quality
+
Trajectory quality

Outcome evaluation¶

The basic question is:

Did the run satisfy the goal's success conditions?

For a coding agent:

- bug fixed?
- targeted tests pass?
- regression suite passes?
- no unauthorized files changed?

For an incident agent:

- correct root cause identified?
- conclusion grounded in evidence?
- unsafe action avoided?

This is the minimum.

Trajectory evaluation¶

Two runs can produce the same correct final answer with very different operational quality.

Run A¶

read relevant file
run targeted test
patch
verify
finish

Run B¶

search 15 files
call same tool 6 times
change unrelated code
revert
run expensive full suite 4 times
finally fix

Both may pass the final check, but Run B is slower, more expensive, riskier, and less predictable.

This is why trajectory metrics matter.

Trace data model¶

A run trace can contain:

Run
├── goal
├── context build
├── model calls
├── decisions
├── tool calls
├── observations
├── state transitions
├── plan versions
├── verification results
├── approval events
└── final outcome

Useful step metadata includes:

run_id
step_id
parent_step_id
timestamp
action type
input reference
output reference
latency
cost
status
error category

Correlation IDs¶

A distributed run may pass through:

API
 ↓
queue
 ↓
agent worker
 ↓
MCP/tool service
 ↓
external API

A shared run_id or trace_id lets those operations be reconstructed end to end.

What should be measured?¶

Task success rate¶

successful runs / evaluated runs

Always tie success to domain-specific completion criteria.

Step count¶

average actions per successful run

Useful for detecting efficiency regressions.

Tool-call efficiency¶

Look for:

repeated identical calls
unused results
calls after the goal was already satisfied

Retry rate¶

Measure:

retries per run
retry success rate
retry by failure class

Replan rate¶

Replanning is not automatically bad. Too little may indicate plan fixation; too much may indicate unstable planning.

No-progress rate¶

Track how often no-progress detection fires.

Human-intervention rate¶

Measure:

clarifications per run
approval requests per run
escalations per run

A high rate may indicate that the agent is too uncertain or policy is too restrictive.

Latency¶

Break it down:

model latency
tool latency
queue wait
human wait
active run duration
end-to-end wall clock

Cost¶

Measure:

model tokens/cost
tool/API cost
compute cost
cost per successful task

cost per success is often more useful than raw cost per run.

Evaluation scenarios for loops¶

An agent-loop eval needs more than an input/output pair.

A scenario can include:

initial state
user goal
tool fixtures
allowed capabilities
expected critical actions
forbidden actions
success conditions
acceptable trajectory variants

For example:

goal: identify failed deployment cause
initial_state:
  deployment: degraded
fixtures:
  recent_deploy: v42
  error_rate: 18%
expected:
  must_observe:
    - deployment_state
    - error_metric
  forbidden:
    - restart_production_without_approval
success:
  root_cause: config_regression

Exact trajectory matching is usually wrong¶

Agentic tasks can have multiple valid paths.

Avoid requiring one exact sequence such as A → B → C → D when A → C → B → D is equally valid.

Prefer invariants:

required evidence observed
forbidden action absent
budget respected
success condition met

Some ordering constraints do matter, such as:

approval BEFORE production mutation
observe current balance BEFORE refund decision

These can be deterministic trajectory assertions.

Offline evaluation¶

Run controlled scenarios with:

fixture tool responses,
mocked external systems,
sandbox repositories,
recorded/replayed observations,
deterministic failure injection.

Example:

tool timeout on first call
second call succeeds

Expected behavior:

exactly one retry with same idempotency identity

Failure injection¶

Evaluate non-happy paths such as:

tool timeout,
rate limit,
stale state,
authorization denial,
rejected approval,
malformed model action,
verifier failure,
worker restart,
budget exhaustion.

This is the foundation of agentic reliability/chaos testing.

Replay¶

A recorded production run can be replayed against a new skill, model, or runtime version.

recorded environment observations
        ↓
new model/runtime version
        ↓
compare decisions

Replay may be exact, partially simulated, or re-executed in a sandbox depending on what data and tools are available.

Regression gates¶

Before updating a skill/model/runtime:

baseline eval
 ↓
new version eval
 ↓
compare

Possible gates:

success rate must not fall > 2%
unsafe-action rate must remain 0
median cost may increase max 10%
p95 step count below threshold

Accuracy is only one dimension.

Production observability¶

Useful dashboards include:

runs started/completed/failed
success by skill/task
p50/p95 latency
cost per task
model error rate
tool error rate
retry rate
budget exhaustion
human escalation
no-progress triggers

Drill-down should support:

run → step → model/tool call → observation

Decision logging¶

Do not depend on hidden chain-of-thought logs. Structured operational decisions are enough:

{
  "decision": "QUERY_LOGS",
  "reason_summary": "Error spike correlates with payment endpoint failures",
  "evidence_refs": ["obs-12", "obs-15"]
}

Sensitive data in traces¶

Agent traces can contain source code, emails, customer records, secrets accidentally returned by tools, or user data.

Use:

redaction
field allowlists
retention policies
access control

Do not blindly retain every prompt and raw tool response forever.

Important anti-patterns¶

Loop explosion¶

A parent run creates workers, each worker creates critics, each critic retries. Child-run count and maximum depth can grow exponentially. Track and cap aggregate budgets.

Tool roulette¶

The model tries many unrelated tools without meaningful progress. Signals include high tool counts, little new evidence, and no completed subgoals.

Retry storm¶

Many agents retry the same failing dependency. Use backoff, jitter, circuit breakers, and queue throttling.

Endless reflection¶

Review/repair cycles repeat without new evidence or meaningful artifact change. Use bounded repair cycles.

Premature stop¶

The model claims success before required evidence exists. Track rejected STOP proposals as a diagnostic metric.

Success hallucination¶

The run reports completion but the external world shows the action never happened. Verify final outcomes against authoritative state.

Stale-observation action¶

A risky action uses old state. Measure observation age and enforce freshness where needed.

Plan thrashing¶

The plan changes constantly without completing subgoals. Track plan revisions relative to progress.

Hidden deterministic logic in prompts¶

If the model almost always selects the same known transition, that transition probably belongs in deterministic code instead.

Run-review template¶

When debugging a failed run, ask:

1. Was the goal/success contract correct?
2. Was canonical state correct?
3. Was the relevant observation available?
4. Did the context builder include it?
5. Did the model choose the right action?
6. Did the runtime validate it correctly?
7. Did the tool execute correctly?
8. Was the result normalized correctly?
9. Was recovery policy correct?
10. Did the stop condition work correctly?

This supports component-level root cause analysis instead of saying only “the LLM was bad”.

SLOs for an agent runtime¶

Possible workload-specific SLOs include:

successful task rate >= 95%
unsafe execution rate = 0
p95 active latency < 30s
budget exhaustion < 2%
repeated-action detector < 5% runs

The values depend on the domain.

Takeaways¶

Agentic evaluation needs both outcome and trajectory quality.
Goal, state transitions, actions, tools, observations, verification, and approvals should be correlated in traces.
Measure success alongside step count, retries, cost, latency, no-progress, and human intervention.
Eval scenarios should include environment fixtures and forbidden/required trajectory invariants.
Prefer critical invariants over exact action-sequence matching.
Failure injection and sandbox evaluation are important for production reliability.
Compare model/skill/runtime changes against a baseline with regression gates.
Protect sensitive data in traces with redaction and retention controls.
Watch for loop explosion, tool roulette, retry storms, endless reflection, premature stop, stale-state action, and plan thrashing.
Observability helps identify whether the fix is a better model, better context, better tools, or simply less agentic behavior and more deterministic code.