AWS Builder Center

Builder Center

What data to feed it, and where to start

What data to feed it, and where to start

Everything resolves to one join key: the AWS signals you switch on per account, how to reach other platforms, and the four human inputs no telemetry provides.

Faris Haddad - AWS

Data and Ai lead at AWS
Part 8 of the series "Containing the agent, counting the value"
Series Article 1,  2,  3,  4,  5 , 6 ,  7 , 8 
A ledger is only as honest as the data behind it. Article 7 built the ledger; this article is about what you pour into it, which is the part most teams leave until it hurts. Some of what the six tests need already flows from AWS and can be switched on an account at a time. Some has to be coaxed out of other platforms. And a handful of things, the ones that decide whether cost and value can be measured at all, come from no system you can simply plug into, because they are facts about your business, not your models. This article works through all three, and ends with the only sensible way to begin: a single workload.

Everything hangs on one join key

Of everything in this build, the stubborn part is not writing code. It is making every source resolve to one identifier for the workload — ledger.workload_id. Get that right and cost, value and risk all attach to the same owner. Get it wrong and you have a fast pipeline producing numbers nobody can be held to.
There is a resolution order, first match wins, and the method used is recorded so you can see how any figure was attributed:
  1. An OpenTelemetry resource attribute on the span, for any instrumented agent.
  2. A tag on a Bedrock application inference profile, Project or Workspace.
  3. A tag on the IAM role or session of the caller.
  4. A tag on the AgentCore Runtime, Gateway or Memory resource.
  5. Custom metadata on an Agent Registry record.
  6. A gateway virtual key or route.
  7. A provider project, workspace or API-key mapping, for OpenAI, Anthropic, Azure or Vertex.
  8. A cost-allocation or FOCUS tag column on the bill.
  9. No match — flagged as orphan.
The ladder matters because it goes from most to least precise, trace level down to invoice level, and it tells you the fidelity of every number that follows. Most of the integration work in this whole project is climbing this ladder for each source. It is unglamorous, and it is the difference between a ledger and a rumour.

AWS: connect once per account, not once per workload

On AWS the signals mostly already exist, because the ledger's join key is the same tag Bedrock and AgentCore use for cost attribution. So you onboard an account, once, rather than instrumenting each workload.
One deployable pack, a CloudFormation StackSet, turns on the native signals in a member account and forwards them to a central ledger account: Bedrock cost and usage, AgentCore metrics, traces and logs, the cost report, and the audit trail. A workload team then does the one thing only it can do: add the ledger:workload_id tag to its resources, and optionally one OpenTelemetry resource attribute for trace-level attribution. Bedrock's native cost methods then deliver billed dollars to the cost report by tag, and the tag appears there once activated as a cost-allocation tag, which takes up to 24 hours.
One caveat worth building for from the start: behind a shared gateway, Bedrock records the gateway's role as the caller, so per-workload attribution is lost unless the gateway assumes a per-workload role or passes the workload ID through. Decide that before you have one gateway serving thirty workloads under one identity.

Agent Registry: the denominator, not the register

AWS Agent Registry now auto-detects agents and MCP servers on AgentCore Runtime and Gateway across an Organization. It is tempting to treat it as the Workload Register. Do not — article 7's register holds owners, value cases and cost classes that the Registry has no concept of. The Registry's job in the ledger is different and valuable: it is the inventory, the denominator for coverage.
That gives the ledger its third kind of orphan. Alongside orphan spend (cost that resolves to no workload) and orphan tool calls (calls to tools in no approved record), the Registry surfaces orphan agents: agents it has detected that have no ledger owner. These are the agents nobody registered, and they are exactly the ones most likely to be running without a value case or a tested stop. A coverage number without this denominator flatters you, because it is a percentage of the agents you already knew about.

Non-AWS platforms: gateway, then push, then pull, then files

Most estates are not all AWS, and the ledger is vendor-neutral by design, so it needs a way onto every other platform. Prefer them in this order, best fidelity first:
  • Gateway. Route model traffic through an AI gateway and you get per-call data for every provider behind it from one integration. This is the highest-fidelity option short of full tracing.
  • Push. Have an instrumented agent send OpenTelemetry spans directly.
  • Pull. Call a provider's usage API on a schedule, for daily aggregate data.
  • Files. Ingest invoices or FOCUS cost exports where nothing better exists.
The pattern is deliberate: one gateway integration covers many providers at good fidelity, so it beats building a bespoke pull adapter for each one. Reserve the file route for sources that offer nothing else, and accept that those sit at the bottom fidelity tier.

The four inputs no platform will ever hand you

Here is the part teams underestimate, and it is on the critical path for two of the six tests. Four inputs are produced by no telemetry system, no cloud platform and no observability tool, because they are facts about your business and your operations, not about the model:
  • Human review time — how long people spend starting, checking, correcting and approving the agent's work. Costed's full-cost denominator is wrong without it, so a workload with no source of review time shows unknown, not a flattering low cost. It comes from ticketing systems, task-review tools or sampled time studies.
  • Business outcomes — whether the agent's work actually succeeded, in business terms: the ticket resolved, the claim approved, the invoice paid without correction. Without it there is no denominator for cost per successful outcome at all. It comes from the business system, joined on a business key.
  • Benefit sign-off — Finance confirming that a claimed benefit is real. Proven depends on it entirely, and it is a human approval, not a metric.
  • Drill records — the measured time to halt from an actual stop rehearsal. Stoppable is unprovable without it, and as article 5 argued, an untested stop has no measured time to halt.
The implication for anyone building this is blunt: the telemetry pipeline is the easy half. These four inputs need connectors to business systems, approval workflows and a drill runner, and if you leave them to the end, Costed and Proven stay grey while the containment tests look busy. Choose first workloads whose outcomes are already recorded in a system, and stand up the review-time and sign-off paths early.

Where to start: one workload, not the estate

You do not boil the ocean. The ledger earns its place one workload at a time, and the right first move is a single pilot — ideally one already on AWS, whose outcomes are already recorded somewhere, with a named owner willing to be the first.
Onboard that one account with the pack. Tag the one workload. Set its ceiling, its outcome definition and its value case in the register. Wire the one source of review time. Run the stop drill once and record the seconds. Then read its six statuses and see which come back grey. That single workload will teach you more about your data gaps than any amount of planning, because the grey unknown cells are a precise map of the inputs you do not yet have.
From there the ledger grows the way the estate does: the next workload reuses the same account onboarding, the same register schema, the same six tests. A lightweight starting profile (a short register card, one infrastructure pack and the six tests in starter form) lets a team run its first one or two workloads without the full platform, and graduate to it later with nothing re-entered. Start narrow, prove the loop, then widen.

The question, answered

This series began with a question that the 2026 incidents forced into the open: when an agent does the wrong thing, can you stop it, and how long will that take? Eight articles later, that question has a home. It is one of six a ledger asks of every production workload — owned, costed, proven, contained, stoppable, accountable — each answered separately, each backed by evidence with a date on it, none blended into a score that could hide a missing kill switch.
The models became actors in our systems in 2026. Containment is what keeps those actors in check; the ledger is how you prove it on any given morning, workload by workload, in dollars and in evidence. The controls in Part B are what make an agent safe to run. The ledger in Part C is what lets you show it — and show, with the same honesty, whether it was ever worth running at all.

References

  1. AWS, "Track usage and costs in Amazon Bedrock." https://docs.aws.amazon.com/bedrock/latest/userguide/cost-management.html
  2. AWS, "Understanding Amazon Bedrock CUR data." https://docs.aws.amazon.com/bedrock/latest/userguide/cost-mgmt-understanding-cur-data.html
  3. AWS, "Using AWS Agent Registry with AWS Organizations." https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/registry-organizations.html
  4. FinOps Foundation, "FOCUS: the FinOps Open Cost and Usage Specification." https://focus.finops.org/
# cost-optimization# agents# generative-ai# ai-security# governance
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article