Problem
A provider total does not reliably explain which customer, workflow, or retry drove cost, while a problematic run may keep making supported model calls.
Attribute supported model-call cost to the customer and workflow, then apply the agreed boundary before the next call.
Product information
- Category: Agent FinOps · Cost attribution · Spend control
- Focus: Customer/workflow attribution, pre-call boundaries, reservation and settlement
- For: Teams operating customer-facing AI workflows
- Product status: Current KazenAI product; run receipts are part of it
Overview
Provider totals show how much was spent, but not always which customer, workflow, or retry created it. Agent FinOps connects supported model-call cost to that business context and checks an agreed boundary before the next call.
The product starts with one supported workflow: agreed identifiers, a clear allow or deny outcome, and cost evidence that run receipts connect to the resulting run.
Work with me:
Mechanism
The integration attaches business identifiers, checks the agreed rule before a supported call, reserves expected exposure where configured, and settles recorded actual cost.
Product outcome
The team can connect model cost to customer-facing work and verify one allowed path and one safely denied path.
Current scope
The formally certified path is synchronous, non-streaming OpenAI Chat Completions and Anthropic Messages. Other modes require separate verification.
Next step
Bring one customer-facing AI workflow and the cost or control problem you want to solve.
Send a problem briefTechnical evidence
Illustrative evidence from a budget denial before a supported provider call.
HTTP 402 Payment Required
available_budget_usd: 0.20
projected_spend_usd: 0.50
allowed: false
avoided_cost_usd: 0.50
provider_call: not executed
event: budget_reservation_deniedCurrent boundary: The hosted demo uses sample data. Customer production deployment, shared-policy behavior, and the customer’s safe response after denial require separate verification.
Goal
Make agent spend controllable before it hurts. Hard stops. Readable attribution. An operator view that treats cost as a reliability concern, not a finance afterthought.
What it does
- Pre-call model-spend control: the agreed check runs before the next supported provider call.
- Customer and workflow attribution: cost records carry the business identifiers supplied by the integration.
- Reservation and settlement: expected exposure and recorded actual cost remain distinct.
- Shared evidence: limit decisions and run receipts refer to the same run context.
How operators use it
Built for teams that already operate customer-facing AI workflows and need to understand which customer or feature drove cost, where a run crossed its agreed boundary, and what happened around that decision.
- Clear outcomes: allow versus deny is visible and reviewable.
- Safe application handling: the customer defines what its workflow does after a denial.
- Narrow adoption: one existing workflow is evaluated before any wider rollout.
Where it fits
- Use cases: customer-facing AI features with cost attribution, retry, or run-boundary problems.
- Signal: especially useful when the configured provider, gateway, and observability stack still leaves a specific gap.
What I built
I built Agent FinOps as the preventive half of KazenAI’s current product: attribute the cost, apply an agreed boundary, and preserve the decision in a run receipt.
Why it matters for clients
Product teams need more than a provider total: they need to know which customer-facing work caused the cost and whether the next supported call should have been allowed. That is the Phase I KazenAI product hypothesis.