Problem
Teams can see that a run was expensive or failed but still spend hours joining cost, calls, retries, and application logs.
Investigate the calls, retries, cost, and policy evidence behind an expensive or failed run.
Product information
- Category: Agent investigation · Incident evidence · Run history
- Focus: Calls, retries, cost, policy decisions, recurring incidents
- For: Teams operating customer-facing AI workflows
- Product status: Current KazenAI Phase I product, sold with Agent FinOps
Overview
A cost alert or failed result rarely explains the sequence that produced it. Teams may have provider logs, application logs, and traces, yet still join them manually during an incident.
Run receipts connect the FinOps decision to readable run history and incident evidence so the owner can review what happened without pretending that an existing-run comparison proves causality.
Work with me:
Mechanism
Run timelines and incident records use the same run context as Agent FinOps, with review history and bounded comparison of existing captured runs.
Product outcome
The technical owner can move from an alert to the relevant costly step, retry, or policy decision and record a reviewable conclusion.
Current scope
Incident workflows are locally integration-verified with synthetic data. Customer production use requires separate verification.
Next step
Bring one expensive or failed workflow and the investigation gap you want to close.
Send a problem briefTechnical evidence
Illustrative incident evidence from a captured run.
workflow: report_generation
run_id: run_01J...
incident: repeated_model_retry
occurrences: 4
cost_state: settled
review_status: needs_review
comparison: existing_runs_onlyCurrent boundary: Existing-run comparison is evidence, not causal proof or an automatic fix. Hosted evidence uses sample data; customer production deployment requires separate verification.
Goal
Make costly and failed agent behavior inspectable from the evidence already captured. Timelines operators can read, recurring incidents they can review, and explicit limits on what the evidence proves.
What it does
- Run timelines: a clear path through captured model, retry, and policy evidence for a given run.
- Incident review: recurring evidence can be grouped, assigned, and reviewed with a recorded reason.
- Existing-run comparison: compare two captured, authorized runs under explicit comparability conditions.
- Private regression evidence: prepare bounded evidence for offline testing when sufficient inputs exist.
Evidence boundaries
Run receipts separate what the captured evidence shows from what still requires an engineering investigation. A comparison can expose a difference without proving that the difference caused the outcome.
- Unknown remains unknown: missing or stale cost evidence is not silently changed to zero.
- Access remains enforced: derived incidents and exports do not grant access to underlying runs.
- Human review stays visible: ownership, status, and reason are preserved rather than inferred.
Where it fits
- Use cases: expensive-run investigation, recurring retry incidents, and supervised before/after review.
- Signal: especially useful when the current stack contains the evidence but engineers still reconstruct the story manually.
What I built
I built run receipts (the Agent Lens service) as the explanatory half of Agent FinOps: connect the cost and spending decision to the calls, retries, and incident record behind the run.
Why it matters for clients
Agent systems become operable when a team can explain a costly or failed execution without manually stitching together every provider and application record. That is the Phase I KazenAI product hypothesis.