Agent Health shows what changed in one time window of agent runs, and how sure we are.
traces.otlp.json1 Nov 2026 06:00:56 UTC → 1 Nov 2026 17:58:04 UTC · 11.9 hgenerated 6 Nov 2026 13:38:01 UTC
Result
The total status is the status of the weakest section below, read at the low end of its 95% likely range. If a hard rule applies, the status is UNHEALTHY in any case.
Numeric signals moved. In 23% of the runs after the first 100 runs, values were far from the normal values, by more than 10 times the usual spread.
In 2 groups of runs with one signal value in common, the share of failed runs moved by 20 percentage points or more. The 95% likely ranges do not overlap.
After the change 3.2→3.3 of credit.record_feed_version, the share of failed runs was 100%. On runs that stayed on the old version at the same time, the share was 16%. The 95% likely ranges do not overlap.
The report covers 400 workflow runs that start at loan_orchestrator invoke_agent, and 65 environment runs. A run with credit.final_decision = deny counts as failed, although a denial can be correct. The baseline is the first 100 runs. The report has 24 periods. See the proposal to return the bureau feed to 3.2
Globe
The globe shows the whole file of runs, and its lower half shows all 8 agents. The labels on the globe are technical, and the report below explains them.
AGENT HEALTH
drag to turn · click a zone · hover the ring
08 Value
Estimate, not an accounting figurerole controller · generic
The Value sheet prices the numbers in the report with your assumptions. Cost counts tokens (the units that AI models charge for), tool calls, computing time and review minutes. Decision value applies one value rule to each outcome. Loss covers the strongest change only. Loss is the risk difference against runs that stayed on the old version, multiplied by the affected runs and the cost of one wrong outcome. Every figure shows its likely range and its assumptions.
cost of this window€424€1.06 per run
decision value€9,168,271€22,921 per run · credit.requested_amount
loss on record_feed_version 3.2→3.3€489,853€421,022 – €518,609 · ~59 wrong outcomes (51–62)
loss per day if nothing changes€983,804projected from this window · cost €851 per day
Decision value, cost and loss in this window
net €8,677,994Loss covers the strongest change only. Another change would add to the loss if its runs on the old version are clearly different from its runs on the new version.
Per period: cost and decision value
€605,207€302,6040
t+0 ht+6.0 ht+11.9 h
cost per perioddecision value per period
Loss per change
signal
change
at
affected
wrong outcomes
loss
basis
credit.record_feed_version
3.2→3.3
t+5.3 h
70
59 (51–62)
€489,853 (€421,022 – €518,609)
risk difference +84 points (+72 to +89) against runs still on the old version; wrong_cost[deny]: share_of_amount 0.03 (example); mean credit.requested_amount among affected 277,000
credit.score_model_version
2.3→2.3.1
t+3.3 h
292
–
–
No runs stayed on the old version at the same time, so we cannot state a loss caused by the change.
credit.policy_version
2026.10→2026.10.1
t+6.0 h
200
–
–
No runs stayed on the old version at the same time, so we cannot state a loss caused by the change.
Assumptions behind these figures
tokens model-a-large: 0.002/0.008 per 1k (example)
tokens model-b-small: 0.002/0.008 per 1k (example)
risk difference +84 points (+72 to +89) against runs still on the old version
wrong_cost[deny]: share_of_amount 0.03 (example)
mean credit.requested_amount among affected 277,000
complaint probability 0.1 (example), cost 150 (example)
Every figure here uses the example values in value-example.yaml, marked (example) above. The live sheet takes your own values through the assumptions wizard. The sheet exports to a spreadsheet with live formulas over your inputs.
00 Timeline of failed runs
The chart shows the share of failed runs in each period. A failed run here is a run with credit.final_decision = deny. The share was 23% in the baseline (likely range 16–32%) and 37% after it (32–43%). The pattern changed 5.2 hours after the start of the file (t+5.2 h, 1 Nov 2026 11:15:24 UTC). The sign of this change is strong.
87%43%0%
t+0 ht+6.0 ht+11.9 h
share of failed runs per period (step line), band = likely range, 95%baseline (first 100 runs)moment the pattern changed
changes
environment
4,426 ms0
average run time
20
steps with an error
05 What changed
UNHEALTHY
The table lists every version change seen on workflow runs. We rank a change by the runs that stayed on the old version at the same time. A comparison of before and after can also mark a change that only happened at the same time as another change. Start with the change at the top of the table.
#
signal
change
at
risk difference
old version, same time
before and after
1
credit.record_feed_version
3.2→3.3
t+5.3 h
+84 points
clearly different
cannot tell apart
2
credit.score_model_version
2.3→2.3.1
t+3.3 h
−5 points
no runs on the old version
cannot tell apart
3
credit.policy_version
2026.10→2026.10.1
t+6.0 h
+13 points
no runs on the old version
cannot tell apart
Each change: runs on the old version at the same time, against before and after
credit.record_feed_version3.2 → 3.3 at t+5.3 hclearly different from the old version
old version, same time16% → 100% +84 points · clearly different
before and after22% → 38% · cannot tell apart
credit.score_model_version2.3 → 2.3.1 at t+3.3 hno runs on the old version
old version, same timeno runs on the old version
before and after23% → 18% · cannot tell apart
credit.policy_version2026.10 → 2026.10.1 at t+6.0 hno runs on the old version
old version, same timeno runs on the old version
before and after25% → 38% · cannot tell apart
0%share of failed runs with its likely range (95%)100%
old value / beforenew value / afterranges do not overlap (the gap is hatched)ranges overlap = cannot tell apart
1 signal that updates on a regular schedule (11 changes, given less weight: many values, none overlapping in time)
signal
change
at
before
after
credit.sanctions_list_version
2026.11.01a → 2026.11.01b
t+1.0 h
21% (11–38%)
33% (20–50%)
credit.sanctions_list_version
2026.11.01b → 2026.11.01c
t+2.0 h
33% (20–50%)
15% (7–31%)
credit.sanctions_list_version
2026.11.01c → 2026.11.01d
t+3.0 h
15% (7–31%)
27% (15–44%)
credit.sanctions_list_version
2026.11.01d → 2026.11.01e
t+4.0 h
27% (15–44%)
12% (5–27%)
credit.sanctions_list_version
2026.11.01e → 2026.11.01f
t+5.0 h
12% (5–27%)
36% (22–53%)
credit.sanctions_list_version
2026.11.01f → 2026.11.01g
t+6.0 h
36% (22–53%)
39% (25–56%)
credit.sanctions_list_version
2026.11.01g → 2026.11.01h
t+7.0 h
39% (25–56%)
42% (27–59%)
credit.sanctions_list_version
2026.11.01h → 2026.11.01i
t+8.0 h
39% (25–56%)
45% (30–62%)
credit.sanctions_list_version
2026.11.01i → 2026.11.01j
t+9.0 h
45% (30–62%)
33% (20–50%)
credit.sanctions_list_version
2026.11.01j → 2026.11.01k
t+10.0 h
33% (20–50%)
39% (25–56%)
credit.sanctions_list_version
2026.11.01k → 2026.11.01l
t+11.0 h
36% (22–53%)
61% (44–75%)
Version lanes: which value each run carried, over time
sanctions_list_version (rolling)12 values
record_feed_version3.2 19% · 3.3 100%
score_model_version2.3 24% · 2.3.1 37%
policy_version2026.10 24% · 2026.10.1 43%
share of runs on a value (stacked per period)value whose share of failed runs is above the upper end of the baseline's likely range (it may only have changed at the same time)value clearly different from runs on the old version
Environment runs (changes outside the workflow)
root
n
first
last
events
bureau_agent invoke_agent
49
2026-11-01 06:00:05
2026-11-01 17:45:00
bureau_feed_schema_updated ×1
kyc_agent invoke_agent
12
2026-11-01 06:00:10
2026-11-01 17:00:00
risk_agent invoke_agent
2
2026-11-01 06:00:15
2026-11-01 09:14:24
policy_agent invoke_agent
2
2026-11-01 06:00:20
2026-11-01 12:00:00
01 Vitals
WATCH
The section shows errors, response times, retries, volume and the number of steps in a run. A HEALTHY status here says nothing about whether the decisions are right. To see how the outcome moved, read What changed and Coherence.
runs with an error2.0%upper end of likely range 3.9%
error types8transient_retry_exhausted ×8
response time alarms5bureau_agent, document_parse, income_verify, intake_agent, kyc_agent
steps per run12off-modal 0%
throughput33.5/hgap 108 s, max 179 s
how even the arrivals are0.0751 = random arrivals
Response time per step
bureau_agent invoke_agent384 ms · p99 647 msalarm ×1.3
loan_orchestrator invoke_agent3,586 ms · p99 5,112 ms
kyc_agent invoke_agent443 ms · p99 1,794 msalarm ×3.3
policy_agent invoke_agent427 ms · p99 646 ms
risk_agent invoke_agent639 ms · p99 859 ms
affordability_agent invoke_agent446 ms · p99 642 ms
bureau_fetch execute_tool380 ms · p99 607 ms
income_agent invoke_agent427 ms · p99 648 ms
income_verify execute_tool387 ms · p99 608 msalarm ×1.4
intake_agent invoke_agent409 ms · p99 641 msalarm ×1.4
notify_applicant execute_tool180 ms · p99 180 ms3 err
document_parse execute_tool365 ms · p99 601 ms2 erralarm ×1.5
risk_agent chat594 ms · p99 791 ms
sanctions_screen execute_tool421 ms · p99 1,787 msalarm ×3.3
policy_engine execute_tool438 ms · p99 607 ms3 err
bureau_feed_sync execute_tool160 ms · p99 225 msalarm ×1.6
sanctions_list_sync execute_tool159 ms · p99 230 ms
policy_config_deploy execute_tool101 ms · p99 155 ms
score_model_release execute_tool128 ms · p99 175 ms
67 mslog scale6,134 ms
tick: half of the steps were faster · bar end: 95% were faster · thin line end: 99% were fasteralarm on the median of a periodsteps with an error
Typical response time per period (p50, the values the alarm watched)
bureau_agent invoke_agentalarm at period 10 · peak ×1.3
kyc_agent invoke_agentalarm at period 10 · peak ×3.3
income_verify execute_toolalarm at period 16 · peak ×1.4
intake_agent invoke_agentalarm at period 19 · peak ×1.4
document_parse execute_toolalarm at period 15 · peak ×1.5
sanctions_screen execute_toolalarm at period 11 · peak ×3.3
bureau_feed_sync execute_toolalarm at period 15 · peak ×1.6
loan_orchestrator invoke_agent3,354 ms–4,274 ms
policy_agent invoke_agent351 ms–572 ms
risk_agent invoke_agent560 ms–741 ms
affordability_agent invoke_agent303 ms–537 ms
bureau_fetch execute_tool255 ms–499 ms
income_agent invoke_agent351 ms–558 ms
notify_applicant execute_tool180 ms–180 ms
risk_agent chat440 ms–703 ms
policy_engine execute_tool202 ms–593 ms
02 Behavioural stability
UNHEALTHY
A signal is a value that Auga records for each run, such as income. The section compares every signal in the baseline with the rest of the runs. It shows how much the values moved from the baseline, and which values are far from the normal values. Compare the signals at the top of each list with the changes in What changed.
Numeric signals: how much the values moved from the baseline
dti_ratio0.4970 outliers
reported_income0.36
verified_monthly_income0.36
disposable_income0.28
existing_debt_payment0.2
risk_score0.17
bureau_score0.13
declared_income0.085
term_months0.069
requested_amount0.041
open_credit_lines0.028
moved 0.1: moderatemoved 0.25: shifted
How the values are spread, compared with the baseline
credit.existing_debt_paymentmoved 0.2 · test 0.17 (p 0.027)median 13,400 → 12,200
16,00010,000
credit.risk_scoremoved 0.17 · test 0.19 (p 0.0075)median 727 → 740
760720
baseline (outline)rest (filled)
5 more numeric signals
credit.bureau_scoremoved 0.13 · test 0.17 (p 0.027)median 719 → 731credit.declared_incomemoved 0.085 · test 0.083 (p 0.66)median 47,500 → 48,000credit.term_monthsmoved 0.069 · test 0.28 (p < 0.001)median 60 → 60credit.requested_amountmoved 0.041 · test 0.093 (p 0.51)median 295,000 → 290,000credit.open_credit_linesmoved 0.028 · test 0.27 (p < 0.001)median 3 → 3
Category signals: how much the values moved from the baseline
sanctions_list_version (prov.)1
score_model_version (prov.)0.911
policy_version (prov.)0.459
record_feed_version (prov.)0.128
income_mismatch_ratio0.128
income_source0.128
decision0.0391
notice_type0.0301
reason_code0.0255
risk_grade0.025
review_decision0.000545
product0
document_text_layers0
identity_verified0
sanctions_hit0
verification_status0
delivery_retries0
moved 0.05moved 0.15version signals always move when a version changes
Per value, baseline → rest
credit.sanctions_list_version · moved 1 · 10 values · version signal
2026.11.01c0% ← 34%
2026.11.01e11% ← 0%
2026.11.01h11% ← 0%
2026.11.01k11% ← 0%
2026.11.01a0% ← 33%
2026.11.01b0% ← 33%
2026.11.01d11% ← 0%
2026.11.01f11% ← 0%
2026.11.01g11% ← 0%
2026.11.01i11% ← 0%
credit.score_model_version · moved 0.91 · 2 values · version signal
2.3.197% ← 0%
2.33% ← 100%
credit.policy_version · moved 0.46 · 2 values · version signal
2026.1033% ← 100%
2026.10.167% ← 0%
credit.record_feed_version · moved 0.13 · 2 values · version signal
3.277% ← 100%
3.323% ← 0%
credit.income_mismatch_ratio · moved 0.13 · 2 values
077% ← 100%
0.99923% ← 0%
credit.income_source · moved 0.13 · 2 values
declared77% ← 100%
bureau23% ← 0%
credit.decision · moved 0.039 · 3 values
approve54% ← 57%
deny36% ← 19%
refer10% ← 24%
credit.notice_type · moved 0.03 · 3 values
approval56% ← 68%
adverse_action36% ← 19%
referral8% ← 14%
credit.reason_code · moved 0.026 · 2 values
none64% ← 81%
R0236% ← 19%
credit.risk_grade · moved 0.025 · 3 values
A64% ← 52%
B25% ← 24%
C10% ← 24%
credit.review_decision · moved 0.00054 · 2 values
approve69% ← 67%
deny31% ← 33%
03 Coherence
UNHEALTHY
Does the outcome still depend on the signals that should decide it? The section shows how much the outcome depends on each signal, before and after, and the groups where the share of failed runs moved. Check the groups in the table that moved by 20 points or more.
moved by 20 points or more, and the ranges do not overlapranges do not overlap, smaller movenew = a value not seen in the baseline, compared with the baseline's overall share of failed runs
04 Human agreement
HEALTHY
An override means that the final decision differs from the agent's decision. Auga finds overrides when two signals with the same set of values disagree on some runs.
override rate6.3%25 of 400 · (4–9%)
In 25 of 400 runs, the final decision differed from the agent's decision: 6% (likely range 4–9%).
06 Topology
n/a
The section shows which step calls which other step, and each step's share of the total run time. It also shows which environment runs come before changes in the share of failed runs. In version 1, the section is for information only.
link width grows with the number of steps (log scale)dashed node = tool (execute_tool)plain node = agent (invoke_agent)bright frame = the workflow root
Share of the total run time
risk_agent invoke_agent18%
kyc_agent invoke_agent15%
policy_agent invoke_agent12%
affordability_agent invoke_agent12%
income_agent invoke_agent12%
bureau_agent invoke_agent11%
intake_agent invoke_agent11%
notify_applicant execute_tool2%
loan_orchestrator invoke_agent1%
Which comes first: environment runs per period against the share of failed runs
environment root
n
best match, periods later
correlation
bureau_agent invoke_agent
48
2
-0.19
kyc_agent invoke_agent
11
2
-0.18
A correlation some periods later is an early sign, not a cause. The causal analysis separates the two.
07 Telemetry quality
HEALTHY
Telemetry is the recorded data about each run. A health status is never better than its telemetry. The section checks ids, clock times, the links between steps, status codes and whether signals are present.
spans4,704465 runs
workflow / environment400 / 65
duplicate span ids0
orphan spans0
clock violations0child outside its parent's interval
Attributes present on fewer than 95% of a span name's spans
span
input.id
record.complete
unit.id
bureau_score
final_decision
open_credit_lines
product
review_decision
type
application_id
bureau_agent invoke_agent
89%
89%
loan_orchestrator invoke_agent
94%
94%
94%
94%
94%
6%
94%
notify_applicant execute_tool
2%
policy_engine execute_tool
5%
document_parse execute_tool
2%
What Agent Health cannot say
The report says that the system changed, which symptoms moved and which versions changed at about the same time. It does not follow the cause chain across agents and runs. Without runs that stayed on the old version, it cannot separate a cause from a change that only happened at the same time. It does not say what a return to the old version would do, and it does not stop the next run. The causal analysis and the mandate cover these points.
Prototype. The report is real output of Auga's health code on Rootplant credit-4217, a synthetic file. The Value sheet uses example values. The globe is live, and it runs the engine's own script on the data of the report. The charts here do not move. The live report lets you hover over and pin every chart, and asks for your own values in a wizard. Here, every list is open.
Total status
The total status takes the weakest dimension and reads it at the low end of its likely range.
More exactly
Total = the weakest dimension on the lower bound of its 95% interval. A hard rule forces UNHEALTHY regardless.
Loss calculation
The loss figure covers only the strongest change.
More exactly
Loss = risk difference under concurrent control × affected traces × cost of one wrongful outcome. Every figure carries its interval.
The moment the pattern changed
The pattern changed at t+5.2 h, and the sign of the change is strong.
More exactly
Change point at t+5.2 h, gain 11 nats (strong). The band in the chart is a 95% Wilson interval per bucket.
How changes are ranked
The table ranks a change by the runs that stayed on the old version at the same time.
More exactly
Ranked by concurrent control: traces that stayed on the old value in the same window. A change is separated when the 95% Wilson intervals do not overlap. Local before/after alone also flags bystanders.
Response time alarms
An alarm means that the typical response time of a step moved away from its normal level.
More exactly
CUSUM alarm on the median per bucket (p50). p95 means 95% of steps were faster than this value. Arrival dispersion is variance / mean² of the gaps between traces, and 1 = Poisson.
How movement is measured
Moved means how much the values of a signal moved from the first 100 runs.
More exactly
Numeric signals: PSI on the baseline's quantile bins, and KS as the test figure. Categorical signals: Jensen–Shannon divergence in bits, and χ². Far from the normal values means robust z above 10.
Dependence and groups
The figure shows how much the outcome depends on a signal, not that the signal causes the outcome.
More exactly
Mutual information between the outcome and each attribute, baseline against rest, in bits. An invariant cell is a group of runs with one attribute value. A cell breaks when its share of failed runs moves by 20 pp or more with separated 95% intervals.
Early signs
A match some periods later shows which comes first, not what causes what.
More exactly
Lead-lag correlation of the environment-trace count per bucket against the share of failed runs, at the best lag. A correlation at a lag is a precursor, not a cause.