ai
Cost Watcher: An AI Agent That Tracks Spend per Rail
The Cost Watcher is an AI agent that tracks inference and infrastructure spend against the budget on each rail of a customer data platform (CDP). It sits at read level (L1) for platform leads and finance partners, and it works from metering data only. It never changes a budget, scales infrastructure or pauses a rail, and it sees no customer data.
Rail level: L1 · Risk: low · Function: platform operations
By Art Kukharenko · Published · Updated
All AI agent railsBudgets belong to the rail card in the AI agent rails method, and this agent tells each owner how theirs is holding up. The platform and data pipeline operations playbook shows the wider function.
Rail at a glance
The Cost Watcher's rail covers reporting alone, and budgets keep enforcing at the gateway whether it runs or not. The gateway holds the limits, so a reporting fault cannot lift one.
Scroll horizontally to see all columns.
| Field | Value |
|---|---|
| Job | Track inference and infrastructure spend against the budget on each rail. |
| Trigger | A daily schedule, or a budget threshold. |
| Data scope | Billing and usage metering by rail, with no customer data. |
| Tool scope | Read: usage meters, billing exports, rail budgets; propose: no changes; execute: no actions. |
| Output contract | Spend by rail, budget variance, unusual runs. |
| Gate | None, since the rail owner and finance partner decide any change. |
| Limits | Metering data only, with requester IDs stripped from the view. |
| Ledger | Period, rails reported, alerts raised. |
| Evaluation | Reconciliation against invoices. |
| Owner and kill switch | Platform lead, with finance; stopping the schedule ends the reports, and budgets still enforce at the gateway. |
What it does and who uses it
The Cost Watcher tells a rail owner what each rail costs before the invoice does. Fixed queries do the arithmetic over billing exports and usage meters, and the model only writes notes on unusual runs. If a scheduled report would tell you the same thing, use the report.
Illustrative daily output, in invented budget units:
Scroll horizontally to see all columns.
| Rail | Budget to date | Spend to date | Note |
|---|---|---|---|
| Reporting Summariser | 1,000 | 940 | Within budget. |
| Segment Drafter | 1,000 | 1,620 | One request accounts for most of the overrun, through repeated tool calls. |
| Journey QA Reviewer | 1,000 | 40 | No runs since Monday, so check the rail is still live. |
| Unallocated | 0 | 310 | Shared GPU nodes with no rail tag. |
Spend behaves differently depending on where a model runs. Salesforce listed Agentforce at $0.10 per action through Flex Credits when checked on 17 October 2026, so metered rails move with use. On owned inference, cost per token is inversely proportional to GPU utilisation, so a quiet week can raise unit cost while total spend stays flat; Agentforce pricing vs owned inference works through both. The FinOps Foundation adds that billed tokens often exceed what a user typed, because system prompts, history and retrieved content count too 3. The FinOps Open Cost and Usage Specification (FOCUS) maps tokens into its Consumed Quantity and Consumed Unit columns, which lets AI lines sit beside cloud lines 2.
Why this level
Spending decisions carry trade-offs a dashboard cannot see, so the Cost Watcher stays at read level (L1). Reversibility is not the issue with a report. The issue is what an agent with a cost-based pause could do: stop a consent or deliverability rail to save small sums, which could cost far more than it saved.
By the Rule of Two 1, the session holds little. Billing exports carry no customer data, so the sensitive-data property is absent. Vendor-recorded labels in those exports are untrusted text, and no tool changes state. That is one property of the three, though contract rates remain commercially sensitive, so restrict who reads the report.
Promotion is off the table. Automatic cost controls belong at the gateway as written rules, which is where OWASP's guidance on denial of wallet points, with rate limits, quotas and timeouts 4. A model's opinion should never decide them, as the rail levels make clear for any limit.
Three ways it fails, and the control for each
Cost reports mislead when a number is right but its reading is wrong, so these controls show the context beside each figure.
Scroll horizontally to see all columns.
| Failure | What it looks like | Control |
|---|---|---|
| Savings that are not savings | Spend drops because a rail stopped or a meter broke, and the report reads as good news. | Spend always appears beside run count and meter freshness. A sharp fall is flagged to the rail owner. |
| Shared cost hidden | GPU nodes and gateways carry no rail tag, so per-rail figures look low. FinOps Foundation guidance, read on 1 November 2026, says no accepted method yet exists for multi-agent workloads 3. | A written, versioned allocation key, plus an unallocated line that is always printed. |
| Meter and invoice disagree | List prices, commitments, expiring credits and exchange rates open a gap that appears at month end. | Monthly reconciliation against invoices. The finance partner owns rates, and differences are reported rather than absorbed. |
How to evaluate it
A Cost Watcher is doing its job when finance learns nothing new from the invoice. Reconciliation is the main test, and a seeded runaway is the second.
- Variance found before invoice, comparing what the report flagged with what the invoice later showed.
- Reconciliation differences, by rail and vendor, with each one explained.
- Time to flag a runaway. Replay a seeded loop through test meter data, since the FinOps Foundation says anomalies such as agent loops are more frequent 3.
- Unallocated share, which should shrink as tagging improves.
- Cost per accepted task, beside raw spend, because cheap work that people reject is no saving.
Where it runs
Metering data carries no customer records, which leaves room for an external model where the contract permits one. Regulated teams may still choose private inference, and the on-premise LLM guide covers that option. PrivyCDP lets you bring your own model into the customer environment, so inference there would show up as your own capacity, but the watcher itself is not a product feature.
Related
- AI agents for platform and data pipeline operations: budgets in the wider platform function.
- Sync Medic: retry loops are one common cause of an overrun.
- Agentforce pricing vs owned inference: the arithmetic behind each cost model.
- Rail card template: the Limits field is where each rail's budget gets written down.
The AI agent rails hub shows how budgets fit the wider method. Download the rail card template to give each rail a budget and an owner who reads this report.
Browse use casesFunction playbooksAgent roster
FAQ
How do you monitor AI agent costs?
Meter tokens, tool calls and capacity per rail, then compare them with a written budget and reconcile against invoices. Tag every run with its rail, and show unallocated cost openly. Agent loops and prompt growth are the patterns to watch.
Can the Cost Watcher stop a runaway agent?
No. Limits at the gateway stop it, under rules written in advance. The watcher reports what happened and who should look. Keeping them apart means a reporting fault cannot switch off a budget.
Should cost be measured per run or per accepted task?
Track both. Cost per run shows efficiency, and cost per accepted task shows value, because a cheap draft that people reject has been wasted. Read a rising figure with the rail owner before cutting anything.
Do you need an LLM to track costs?
Not for the arithmetic, which fixed queries do more reliably. A model adds plain-language notes on unusual runs. If a dashboard already gets your owners to act, skip the agent.
Sources
Further reading
- AI Agents for Data Pipeline Operations
- AI Config Change Review Agent: Connector
- Backup Restore Drill Reporting: Restore
- Agent rails
- AI Agent Permissions Template Download
Published: · Updated:
Editorial dates describe content changes. Confirm current sources before making legal, security or purchasing decisions.