AWS Ends the Claude Code Black Box for GTM Teams: A Framework

What AWS actually launched on July 20

On July 20, 2026, Amazon announced CloudWatch Coding Agent Insights, a new view inside CloudWatch that surfaces how AI coding tools are being used across an organization. It is built on OpenTelemetry metrics that Claude Code, Codex, and GitHub Copilot already emit, and for Claude Code specifically it can pull that telemetry through the Claude apps gateway without any extra instrumentation on your end. The feature is live in every AWS commercial region except the Middle East regions in the UAE and Bahrain and the Israel (Tel Aviv) region.

I read a lot of coding-agent product announcements for this blog, and most of them are about the agent getting smarter. This one is not about the agent at all. It is about the org around the agent finally being able to see what is happening inside it, which is a different and, for a GTM team, arguably more useful kind of update.

Why a GTM team should care about an AWS observability feature

If you are running a revenue team, you might reasonably ask why a CloudWatch feature aimed at "engineering leaders" belongs on a GTM blog. The answer is that Claude Code stopped being an engineering-only tool a while ago. RevOps builds CRM enrichment pipelines with it, GTM engineers wire up dashboards and internal scripts, and agency operators run entire outbound systems out of a terminal. None of that shows up in a normal CRM report, and until now, most of it did not show up anywhere at all except a monthly bill.

That gap has real consequences. In a survey Growth Unhinged and GTM Strategist ran on 200 GTM operators earlier this year, "credits and usage limits" beat accuracy as the top Claude Code and Cowork complaint, with some Max-plan users hitting limits two to three times a day, a finding I covered in an earlier piece on that survey. Complaints like that are hard to fix when nobody can see which team, which workflow, or which time of day is actually driving the spend. Coding Agent Insights is the first tool I have seen that answers that question directly instead of leaving it to a spreadsheet someone reconstructs from invoices.

The black box problem this is trying to fix

Before this kind of visibility existed, a GTM leader who approved Claude Code access for a RevOps analyst or a GTM engineer had exactly two data points: the seat cost, and whatever that person self-reported about what they built. There was no way to see whether a workflow that ran fine in testing was quietly burning through a token budget in production, whether one person's usage pattern looked nothing like another's, or whether the tool was actually accelerating anything versus just being a novelty someone kept open in a tab.

That is a governance gap, not just a cost one. A team that cannot see usage cannot answer "should we expand access" or "should we pull it back" with anything other than a gut call. AWS is not the first to try to close this gap, Claude Enterprise's own spend alerts and Amazon's earlier OpenTelemetry setup guides for Claude Code both point at the same problem, but folding it into CloudWatch alongside the operational data teams already watch is the most direct integration of the two I have seen so far.

How Coding Agent Insights actually works

Under the hood, this is OpenTelemetry metrics, the same open standard a lot of application monitoring already runs on, presented next to your existing CloudWatch operational dashboards. For Claude Code, AWS's setup documentation describes two paths: a bearer-token setup for smaller teams, or an enterprise rollout tied to corporate single sign-on for anything bigger. Either way, once it is wired up, no individual user has to change how they work with the agent day to day. The telemetry rides along with normal usage.

That "no extra instrumentation" claim is the part worth double-checking before you assume it is fully turned on. In practice this still means someone on your team, usually whoever owns your AWS account, needs to enable the integration and grant it the right permissions. It is low-lift compared to building a usage tracker yourself, but it is not literally zero setup.

Pillar 1: visibility, who is using it and for what

The first and most immediate use of this data is the simplest: a list of who is using Claude Code, how often, and roughly what kind of work each session touches. For a GTM org, that usually splits into a handful of recognizable buckets, enrichment scripts, CRM data cleanup, internal dashboard builds, and one-off automation. Just seeing that breakdown for the first time tends to surface at least one surprise, often that a single workflow accounts for far more usage than anyone assumed.

Do this pass before you touch anything else. It is tempting to jump straight to budgets, but a budget set before you have looked at real usage is a guess wearing a policy's clothes.

Pillar 2: attribution, tying usage to outcomes

Visibility tells you where the tokens go. Attribution tells you whether that spend produced something. This is the pillar most teams skip, because it takes an actual conversation with the person behind the usage rather than just reading a dashboard. Walk through the top few usage buckets from pillar one and ask, plainly, what shipped: a dashboard someone uses weekly, a pipeline that replaced a manual export, or a prototype that never left someone's laptop.

This is also where usage data earns its keep as a coaching tool rather than a policing one. A GTM engineer whose usage is high and tied to three tools the whole team relies on is a different story than usage that is high and tied to nothing anyone else can point to. Treat the second case as a conversation about what they need, not an automatic cutoff.

Pillar 3: right-sizing token budgets by team

Once you have a few weeks of real visibility and a rough sense of attribution, you can set token budgets per team or department instead of a single number applied to everyone. AWS's own framing of this feature explicitly calls out "how can you right-size token budgets across departments" as one of the questions it is meant to answer, and it is the one I would lean on hardest if the credits complaint is already the top thing your team gripes about.

Size the budget to the pattern you actually observed, then leave headroom, not the other way around. A budget set to exactly what a team used last month with no slack just relocates the "hit my limit twice a day" complaint from an individual to a team, which is not actually progress.

Pillar 4: the access-expansion gate

The last pillar is the one most GTM leaders actually asked me for over the past few months without knowing this tool existed yet: a defensible answer to "who gets Claude Code access next." Instead of expanding access based on who asks loudest, you can point at usage and attribution data from people who already have it and expand toward the roles and workflows that look most like the ones already paying off.

This does not replace judgment. It gives the judgment call something to stand on besides a hunch or a headcount request.

What it does not show you

Coding Agent Insights is usage telemetry, not a quality or correctness signal. It will tell you that a workflow ran for forty minutes and consumed a given number of tokens. It will not tell you whether the output was any good, whether a script it helped write has a bug in it, or whether the CRM data it touched is now more accurate or less. It also will not see into anything outside the coding agent itself, so a Salesforge sequence, a Clay enrichment run, or any other point tool in your stack stays invisible to this specific feature.

Treat it as one input into the four pillars above, not as a replacement for actually reviewing what got built. The teams that get the most out of this kind of telemetry still pair it with a human periodically looking at the actual work product, not just the metrics about it.

Setting it up without derailing your week

If you already run on AWS and already use Claude Code for GTM tooling, this is a same-week project for whoever owns your AWS account, not a quarter-long initiative. The rough order I would follow: confirm your region is supported, wire up the Claude apps gateway integration per AWS's setup docs, let it run for two to four weeks untouched, then start the visibility pass in pillar one. Resist the urge to attach budgets or access rules to the very first data you see. A month one dataset is a starting point, not a verdict.

Where this fits next to the rest of my stack

This feature only sees the coding agent, so it does not touch the sending and lead-data side of what I actually run, Salesforge for sequencing and Leadsforge for lead data. What it does help with is the layer in between, the Claude Code scripts I use to pull data out of those tools and into a dashboard or a CRM view. Now that usage is visible in the same place as the rest of my AWS operational data, I do not have to guess whether a script I built once is still doing its job or has quietly turned into dead weight nobody is watching.

My take: what I would check first

If I were rolling this out for a client this week, I would not start with budgets or governance. I would start by pulling the visibility data for two weeks, then sitting down with whoever has the top two or three usage buckets and asking what they built. Half the value of this feature is the conversation it forces you to have that you had no good reason to have before, because you had nothing to point at. The dashboard is useful. The conversation it triggers is the actual point.

FAQ