An unnamed agent is spend nobody can defend
A renewal assistant that reads the account, opens the contract, drafts the note, and checks the CRM does not make one model call. It makes a stack of them. Each call can drag a large context window behind it.
Token consumption therefore scales with the degree of autonomy you grant the workflow and the size of the context it carries, rather than with the number of user interactions.
That is the billing shape of agentic work, whether the workflow sits in AI for sales or in an internal automation fleet. Comparing model prices and shortening prompts shaves a rate card. It does not tell finance which team spent the money, which AI agent spent it, or whether the spend stayed inside a budget anyone approved.
The fix isn’t a cheaper model or a smaller prompt. It’s an operating model.
That line comes from an AWS playbook for FinOps and platform teams, “Managing Amazon Bedrock costs end to end, ” by specialist solutions architects Aswath Ram A Srinivasan and Aamna Najmi, with Ajit Mahareddy. Treat it as an operating sequence. You will not find a customer case study here. It does not publish before-and-after savings from a named deployment. The thresholds, routing targets, and cache rates below are its guidance. Confirm any rate you plan to forecast on the Amazon Bedrock pricing page and in the AWS Pricing Calculator.
What to decide before the next invoice
Three decisions matter more than another prompt-trimming workshop.
Who owns the loop. FinOps leads attribution and the money review. Platform engineering leads logging, enforcement, and the defaults that change behavior. Application teams own retrieval, conversation compaction, and whether a smaller model can do the job. The review is joint. In most companies the people who own the invoice do not own the agent loop. The people who own the agent loop do not see the invoice until it is already a meeting.
When a runaway workflow may be stopped. Alert if you are still learning what normal looks like. Use an asynchronous deny if you can live with a late stop and a call that is already billed. Put a gateway in the path, and return HTTP 429, only if every client can be forced through it. Take the next split as the playbook’s judgment, not a universal rule. If spend is already in the millions per month, build enforcement now. If alerts can hold the line for another quarter, finish attribution and observability first.
Whether an efficient workflow deserves to run. A workflow can be perfectly efficient and still not be worth running. Comparing the agent with the human process it replaced is product and analytics work. A chargeback formula will not settle it.
Five stages, and the order is the point
The loop is attribute, observe, enforce, optimize, and operate. Each stage depends on the one before it.
Teams that jump straight to optimization without attribution and observability are guessing.
The sections below follow that order on purpose. Routing and caching are stage four. They are not a substitute for knowing who spent the money.
Attribute: give the bill an owner
AWS supports Amazon Bedrock cost allocation by IAM principal. Once you include caller-identity data in a Cost and Usage Report (CUR) 2.0 export, AWS records the caller’s IAM principal ARN in line_item_iam_principal. It is meant to replace reconciling CloudWatch and CloudTrail against the bill by hand. It does not happen the day you turn a model on. Tags still have to be applied and activated, and the identity has to make a real Bedrock call before its tag keys even appear for activation.
The decision that matters is simpler than the export schema. A shared LLM gateway that calls Bedrock with one IAM role attributes every dollar to that role. You get a total. You do not get a team. That is a shared bill with no owner.
How platform implements this
The playbook’s fix is per-user session management. Assume the invocation role once per user. Put the person in the role session name. Pass team, application, and cost center as session tags, and cache the credentials for up to an hour. One AWS STS call per user per hour, not per request. That pattern needs two roles: a gateway execution role allowed to assume a role and tag the session, and the Bedrock invocation role it assumes.
AWS warns against unique session IDs, timestamps, or random GUIDs as cost-allocation tag values. Identity belongs in the session name. Low-cardinality tags belong in the tags. Do not swap them.
The playbook’s example uses a placeholder account and role, BedrockRuntimeRole, session name gw-alex, and tags such as team=sales-ai, application=renewal-agent, and costCenter=CC-2041. The short label assumed-role/BedrockRuntimeRole/gw-alex is not the full ARN. AWS documents the full form, for example arn:aws:sts::123456789012:assumed-role/application-role/session-name. Query the ARN, not the nickname.
After activation, IAM principal tags appear in CUR 2.0 with an iamPrincipal/ prefix, so iamPrincipal/team does not collide with a resource tag that uses the same key. AWS says tag keys can take up to 24 hours to appear for activation and up to another 24 hours to activate. Its documented order is: apply tags, let that identity make at least one Bedrock call, activate the tags, then enable principal data in the export. In Cost Explorer, filter on the Tag dimension and the activated key. AWS’s own example is iamPrincipal/department.
Principal-level data is not free. AWS warns that it multiplies CUR rows by the number of calling identities hitting each model, which means larger exports and more Amazon S3 storage. Cheap next to an unnamed agent fleet. Not zero.
The playbook maps three attribution paths. IAM session tags for bedrock-runtime workloads. Application inference profiles, one per application, per model, per Region, when the set of apps and models is small and stable. Projects and workspaces for the bedrock-mantle endpoint and OpenAI-compatible workloads, because a project is not tied to one model and its tags are meant to flow into CUR and Cost Explorer.
Observe: who spent, and what happened
CUR tells you who spent. Invocation logs tell you what happened.
The playbook puts CUR lag at roughly a day. For a coding-agent fleet, a day is a long time to notice a workflow that has decided to reread the repository. It points to CloudWatch plus OpenTelemetry for views that can land in minutes. Do not promise that latency to a CFO until you have measured it in your account. The field paths in the playbook’s sample queries are illustrative, and those samples are capped at 25 results. Verify the schema before an example query becomes an alarm.
Request metadata is how you tell a renewal agent from a support agent from a tenant’s overnight batch. Stamp application, workflow, tenant, and agent. The playbook says Bedrock does not enforce those fields. If the platform does not inject them in one place, coverage becomes optional, and optional metadata dies in the first sprint. Track coverage as a platform health metric.
Provision logging as infrastructure: retention, encryption, and a check that records actually arrive, in every Region you call. Logging that exists only in dev is not a cost program.
Watch retries. A client-side timeout on a request that still finishes on the server, followed by a retry that also finishes, is two completed requests. You pay for both. You were not double-charged for one call, and this is not a billing bug. Aggressive retries in an AI automation layer will still make the error chart and the invoice disagree. Client-emitted telemetry and CUR can diverge for the same reason. Pick a system of record for chargeback, and say so.
Enforce: alerts, a late stop, or a hard gate
Alerts if you are still learning normal. An async deny, or a credential withhold, if you can tolerate a late stop and a call that is already billed. A gateway 429 only if every client can be forced through it.
Tier 1 is AWS Budgets. Alert, do not block. No added inference latency.
Tier 2 is asynchronous. In the playbook’s design, a Lambda reads invocation logs, tallies per-user token and dollar counters in DynamoDB, and adds a breaching identity to a shared IAM deny on Bedrock actions until the monthly reset or an admin override. A related pattern withholds credentials instead of updating a deny policy. Either way the stop is late: seconds to minutes after the breaching call if you update a policy, or at the next credential refresh if you check before issuing credentials. The call that crossed the line has already been billed. Native attribution does not require this pipeline. Enforcement might.
Tier 3 puts a gateway in the data path. The playbook describes sub-second blocking, per-user model allowlists, token rate limits, and routing you control in one place. Every client has to go through it. You then own latency, scale, security review, and what happens when the gateway is down. The playbook names those trade-offs and does not quantify them.
Connectivity decides the menu. Direct Bedrock calls, with no proxy you can force traffic through, leave you on tiers 1 and 2. A hard cap built on bad identity data is a political argument with extra IAM.
For Claude Code and Claude Desktop fleets, the playbook recommends a Claude apps gateway for AWS. For mixed-model, multi-provider estates, it points to a LiteLLM reference architecture on Amazon ECS with Fargate, or a serverless pattern in related guidance. Those are architectures to evaluate against current AWS guidance. They are not measured savings.
Optimize: most waste is a default nobody set
Most Amazon Bedrock waste is not individual carelessness. It is platform defaults nobody set.
Application teams still own the deeper cuts: fetch context just in time, compact long conversations, and distill repeated tasks onto smaller models. The platform’s job is to make the expensive path the exception, then publish a leaderboard so the exception is visible.
Routing is the first default. Inside a model family, or at the gateway, send routine turns to a smaller model and keep the frontier model for the hard ones. For agentic coding fleets where boilerplate dominates volume, the playbook says more than half of calls landing on cheaper models is an achievable target. Read that as a target. No named deployment produced that number, and it is a poor promise before your own logs exist.
Prompt caching is the second default, and the price tag needs a steady hand. The playbook states, as of October 2026, these multipliers for Anthropic Claude models on Bedrock in US East (N. Virginia). A cache write is 1.25 times the base input rate with a five-minute TTL, and 2 times with a one-hour TTL. Cache reads, it says, are 0.1 times on Claude Sonnet 4.6 and Claude Haiku 4.5, and 0.05 times on Claude Sonnet 5.5 and Claude Opus 5.5. It also says the multipliers vary by model and Region and can change.
Anthropic’s own pricing uses that same write structure. A footnote there matches the 0.05 times read rate for the 5.5 names, while visible price rows also list Claude Opus 5 and Claude Sonnet 5 at an effective 0.1 times read. Sonnet 4.6 and Haiku 4.5 sit at 0.1 times on those rows. Do not collapse Sonnet 5 and Sonnet 5.5, or Opus 5 and Opus 5.5, into one SKU. Anthropic’s website is not your Bedrock invoice. Confirm the model IDs you actually call before those multipliers enter a forecast.
If the playbook’s rates hold, the arithmetic is straightforward. Call it arithmetic. Do not call it a measured saving. It also only describes input tokens, and only if the entire input is one stable cached prefix.
A five-minute write costs 1.25 times the base input rate. The first read at 0.1 times more than recovers that premium, because the reused prefix is no longer billed at full input price. An unread write is pure loss: 25 percent extra at five minutes, double at one hour.
Ten calls against that stable prefix, one write and nine reads, come out near 22 percent of the uncached input price at a 0.1 times read: 1.25 plus nine times 0.1, divided by ten. At 0.05 times, the same sum is 17 percent. Output tokens are not in that figure. Cache the system prompt and the tool definitions that stay put. Do not cache a prefix that changes every call. That is laminating a sticky note.
The playbook’s candidate filter is a sensible starting query, not a law: more than 50 calls, and average input above 2, 000 tokens. Anthropic’s caching documentation adds constraints the cost note does not. Prefix order is tools, then system, then messages. Writes happen at explicit breakpoints. Automatic lookup looks backward through a limited number of blocks, and breakpoint slots are few. Minimum token thresholds exist. Confirm the current numbers before you design a prompt format around them.
Operate: review outcomes, not calls
Run the review weekly for a high-velocity fleet, biweekly otherwise. The playbook’s operating dashboard tracks four signals: model mix, failed request rates, cache effectiveness, and metadata coverage. Failed requests deserve a second look when the retry also completed and both calls are on the invoice.
The scorecard thresholds are the playbook’s starting points. Do not treat them as a standard, a benchmark from a measured fleet, or a formula to drop into a contract. The playbook does not define “successful, ” and it does not give an exact formula for cache-read hit ratio.
- Cost per successful outcome: at or under budget is green, 1 to 1.5 times budget is yellow, above 1.5 times is red.
- Daily spend per developer: under $100 is green, $100 to $300 is yellow, above $300 is red.
- Share of calls on cost-efficient models: above 50 percent is green, 30 to 50 percent is yellow, below 30 percent is red.
- Cache-read hit ratio: above 60 percent is green, 30 to 60 percent is yellow, below 30 percent is red.
The first row is the one worth arguing about. A green cache ratio and a cheap model mix can still describe work nobody should have authorized. Clean attribution turns that argument from an all-hands fire drill into a chargeback conversation: who spent it, on which AI agent, and whether the cap held.
Questions worth asking before the next invoice
- Who should own Bedrock cost control? FinOps owns attribution, budgets, and the money review. Platform engineering owns logging, enforcement, and the defaults for routing and caching. The review is joint. Application teams still own retrieval, compaction, and whether a smaller model can do the job.
- Does Bedrock attribute spend automatically? No. Caller identity has to be enabled in a CUR 2.0 export, tags have to be applied and activated, and the principal has to make at least one Bedrock call before its tag keys appear for activation. Native attribution does not require a custom metering product. Enforcement might. Principal-level data does increase CUR and S3 volume.
- What breaks attribution behind a shared gateway? One IAM role for every caller. The playbook’s remedy is a per-user assumed-role session, with the person in the session name and team, application, and cost center in session tags, credentials cached for up to an hour. Keep per-user identity out of high-cardinality tag values.
- How fast can you stop a runaway agent? Alerts do not stop anything. The playbook’s asynchronous IAM pattern lands seconds to minutes later, or at the next credential refresh, and the breaching call is already billed. A gateway can block in under a second only if every client is forced through it. Direct calls leave you on the first two tiers.
- Is prompt caching a guaranteed discount? No. Under the playbook’s October 2026 multipliers, a reused stable prefix gets cheap on input tokens, and an unread five-minute write is a 25 percent loss. Those rates are a single-source claim about Bedrock in one Region. They differ by exact model name. They are not the same thing as Anthropic’s public price rows.
- What should a weekly review actually measure? Model mix, failed requests, cache effectiveness, metadata coverage, and cost per successful outcome rather than cost per call. The green, yellow, and red bands, including daily spend per developer under $100 as green, are the playbook’s starting points. They are not benchmarks from a measured fleet.
- When is an efficient agent still a bad spend? When the outcome is not worth the human process it replaced, or when nobody can name the team that authorized the autonomy. Efficiency answers how you spent. It does not answer whether you should have.
Build the loop before you buy the next model
AI agents will keep getting more autonomous. That is the product direction, and it is the billing direction. A conversational bot is roughly one invocation per turn. An agent plans, reads, calls tools, and tries again. If the platform default is a frontier model, full context, no cache, and a shared role, the invoice will teach that lesson whether the architecture review does or not.
If you are not already on fire, start with the Guidance for Claude Code with Amazon Bedrock reference architecture for the first three stages, then Bedrock’s cost-attribution documentation for tagging. If spend velocity is already ugly, build a real stop in parallel. Do not let optimization outrun identity. A routing target is not a result you have already earned.
Build the five stages and you can answer, end to end: who spent it, why, and whether it was controlled.
Get to the point where you can say who spent it, why the workflow spent it, and whether the cap held. Then decide which agents deserve a larger budget. That is a better argument than another round of prompt trimming.