Attribute agent spend to a job, not a model bill.
A model invoice tells you what you spent. It does not tell you which job, which owner, or which decision caused it.
Teams often see a model bill without a job. Fill a TWIMCO Agent Cost Attribution Card before scale: every run carries a job id, a cost center, token and tool spend, and an owner who can stop the job. A vendor invoice is not attribution.
Monday morning, one invoice, no owners
The finance forward arrives before standup. One line from the model vendor. Another from the tracing vendor. A third from a tools marketplace you forgot you enabled. Nobody can say which agent job spent what. Product thinks support’s triage agent is cheap. Support thinks the overnight research job is the burner. Engineering shrugs at retries. The only number in the room is the total—and totals do not let you turn anything off.
This is ordinary now. Enterprises often get real-time model usage and still lack job-level attribution: they can see spend rising and still cannot point at a responsible workflow. The trend is a hook. The decision is design. If cost is not a first-class field on the job, you will keep debating the invoice.
Sit with that Monday for a moment. The useful question is not “how do we cut AI spend by some invented percent?” It is “which job may we pause without guessing?” If nobody can answer, the platform is not ready to scale the next agent—it is ready to scale the argument.
This note is a scene you can walk into, then a TWIMCO Agent Cost Attribution Card you fill so the next invoice splits. The card is the asset. No survey percentages here—only the operating move: tag the job, own the spend, cap what can run unattended.
When you are building agents that run as real work, the home is AI applications & agents.
What the card puts on every run
Fill one TWIMCO Agent Cost Attribution Card per agent job—not per model, not per team Slack channel.
Job id. Stable name the runtime sends on every call: support.triage.v3, ops.research.nightly. If the runtime cannot stamp it, attribution is already dead. Do not reuse a job id across unrelated prompts just to keep the catalog tidy.
Owner. The role who may change the job’s prompt, tools, and budget, and who receives the weekly spend for that job. A shared channel is not an owner. Two owners means no owner when the cap fires at 2 a.m.
Cost center. The finance or team code the spend rolls to. Pick one. Dual-coding everything to “AI platform” recreates the single invoice with extra steps.
Meter. What you count: model tokens in and out, tool calls, vendor retrieval units, human review minutes if you bill them internally. Write the units you can actually collect. Do not invent a unit the systems do not emit. Partial meters are fine if you label them partial.
Cap. Soft and hard limits per day or per run. Soft notifies the owner. Hard stops new runs or sheds to a cheaper path you already designed. A cap with no stop is a dashboard decoration. Write the shed path on the card—silent failure is not a shed.
Retry and fan-out rule. Whether retries inherit the same job id (they should) and whether a single user action may spawn N child runs without a new authorization. Fan-out without a cap is how a polite loop becomes the bill.
Export. Where daily job spend lands so finance and the owner see the same table. If only the platform team can see vendor consoles, you do not have attribution—you have a priesthood.
Stamp these on the run before you optimize the model. Cheaper tokens on an unowned job still surprise you on Monday.
How the work moves
From invoice to job
- Stamp the job
Runtime sends a stable job id on every call.
- Meter the spend
Tokens, tools, and other units you can collect.
- Roll to owner
Cost center and named owner on the same row.
- Enforce the cap
Soft notify, hard stop or shed.
- Export the day
Finance and owner see one table.
A model bill without a job id is a cost you can see and still cannot steer.
The scene again, with a card
Same Monday. The forward still arrives. This time it is a rollup: three jobs, three owners, three caps. One job is over its soft cap from a retry storm after a bad tool schema. The owner gets the alert Sunday night and freezes new runs. The other two jobs are quiet. The meeting is ten minutes: fix the schema, raise or keep the cap, move on.
That is the whole point of attribution. Not a prettier chart. A person who can stop a job.
You will still have shared platform overhead. Put it on a platform job with a platform owner—do not smear it across every product job until nobody owns the variance. Shared overhead is allowed. Shared blame is not.
Vendor discounts and committed use still sit at the account level. The card does not replace procurement. It tells you which jobs consume the commitment, so renewal is an operating conversation instead of a guessing game. When someone proposes a fifth agent “because the commit has headroom,” you can ask which job’s headroom—and whose cap moves.
This scene is illustrative. It is not a measured before-and-after from a client engagement, and it does not claim a savings percentage.
Sequence of work
Total versus attributable
- Run starts
Job id and owner already on the span.
- Spend accrues
Model and tool meters update the job row.
- Soft cap
Owner is notified while the job still runs.
- Hard cap
New runs stop or shed to the designed fallback.
- Weekly rollup
Invoice lines map to jobs, not only to vendors.
Refuse the invoice as the only lens
A few habits keep teams stuck on the total.
One API key for every experiment. Spend cannot be split even if you wanted to. Per-job keys or per-job metadata—pick one mechanism and enforce it. Metadata without enforcement is a field nobody fills.
Cost dashboards that show model and not tool spend. The tools marketplace was the quiet half of the bill. Meter both or admit the card is partial—and put “partial” on the export so finance does not invent precision.
Owners who only see monthly totals. Soft caps need a daily or per-run loop. Monthly is for finance; operators need a tighter clock.
“The agent will get cheaper next quarter.” Maybe the model will. Without attribution you will not know whether volume, retries, or a new job ate the gain. Optimize after you can see.
If you recognize these, fill the Agent Cost Attribution Card for the noisiest job first. Then the next. Do not wait for a perfect platform. A card on one job beats a strategy deck about FinOps for agents.
Put this into practice
- List the agent jobs that ran last week. If you cannot list them, that is the first finding.
- Open a TWIMCO Agent Cost Attribution Card for the job with the least clear owner. Fill job id, owner, cost center, meter, cap, retry rule, export.
- Make the runtime stamp the job id on every model and tool call. No stamp, no production.
- Route the weekly rollup to owners, not only to the platform channel.
- When you scope new agent work, bring the card into AI applications & agents so cost is designed with the job—not bolted on after the invoice lands.
See the bill. Name the job. Give someone the stop button.
Related work: Sutton|Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.