Attribution is who called, never what they asked

You cannot grow agent adoption you cannot see. Most agent traffic reaches an API through SDKs, plugins, and MCP servers that never identify themselves, so the usage gets undercounted and the channels that drive it look like they do nothing. The fix is boring: a client identifier in every integration you ship, and in every one you can send a pull request to. The line I hold is that attribution records who called, never what they asked. Measurement that costs developer trust is not worth having.

The invisible channel

Here is how agent usage typically reaches an API. A developer installs an agent framework. The framework has a plugin or tool for your service, maybe written by you, maybe by a contributor. Or the developer connects an MCP server that wraps your API. The agent decides, mid-task, to call that tool. The request arrives at your API with a valid key and very little else.

From the API's point of view, that request looks the same as one from a hand-written script. There is no referrer, no campaign tag, no signup form that asked "how did you hear about us". The integration that actually produced the call, the plugin you spent a month on or the MCP server someone else maintains, leaves no trace.

Multiply that across every framework and every wrapper and you get a strange picture. Total usage grows, but when you try to explain where it came from, the biggest share lands in "unknown". The channels doing the most work look like they do the least.

Why undercounting is a strategy problem

It is tempting to treat this as a reporting annoyance. It is more serious than that, because unmeasured channels lose arguments.

When I moved my team's north star from site traffic to whether agents reach for us, I made the question measurable in principle, not in practice. Planning runs on evidence. If the framework integrations cannot show their contribution, then in the next planning cycle they compete against work that can, like a landing page with clear conversion numbers, and they lose. Nobody decided to defund the agent channel. It just never appeared in the numbers, so it never won a slot.

This compounds. The integrations that do not get maintained drift out of date. Agents using them hit errors and stop calling. Usage from that channel drops, which nobody notices because it was never visible to begin with. You can lose a distribution channel you did not know you had.

There is a second cost. When you cannot see which clients drive usage, you cannot talk to them. You do not know which framework maintainers to thank, which wrappers are broken, or which integration a new customer started from. The feedback loop that makes developer platforms better depends on knowing who is on the other end.

The fix is boring on purpose

The fix is a client identifier: a small, stable string that says which integration made the request and which version it was. It goes in a header or a user-agent field on every request.

Integration	Example identifier
Your own Python SDK	acme-python/2.3.1
A framework plugin you maintain	acme-langchain/0.9.0
An MCP server	acme-mcp/1.4.0
A community integration you contributed to	acme-community-plugin/0.2.0

That is the whole mechanism. It works in two places.

In everything you ship. Every SDK, plugin, and MCP server your team publishes should set the identifier by default. This is the easy part, and it is also the part teams skip, because each individual integration seems too small to bother with.

In the integrations you do not own. A lot of agent traffic flows through integrations maintained by other people. Many of them will accept a small pull request that adds an identifier, especially if the change is tiny, documented, and clearly harmless. This is unglamorous work. It is also some of the highest-leverage measurement work you can do, because it turns unknown traffic into named traffic in the places where agents actually live.

The line: who, never what

The moment you start instrumenting integrations, you will be tempted to collect more. If you know which plugin made a call, why not also record the prompt that led to it, or the query the agent sent? It would make for richer analysis.

I do not cross that line, and I think it is the most important design decision in this whole area.

The identifier should answer one question: which client made this request, at which version. It should never carry what the user asked, what the agent was doing, or anything derived from the content of the request. The developer who installs your SDK is trusting you with access to their workflow. If attribution becomes a way to watch what they build, the trade is bad for them, and once developers learn about it, it is bad for you.

There is a practical argument too. Developers read source code, especially for anything that sits between an agent and their production systems. An identifier that is a short version string is easy to audit and easy to accept. A telemetry payload that ships query content will get noticed, forked out, and written about, and it will cost you the integrations you were trying to measure.

So the rule is simple enough to put in a design review: record who called, never what they asked.

What to do about it

If you run a developer platform with any agent traffic, here is the order I would work in.

1. Measure the unknown share first. Look at your usage and find how much of it arrives with no identifiable client. That number is your baseline and your argument for doing the rest.
2. Add the identifier to everything you publish. SDKs, plugins, and MCP servers, all of them, with a consistent naming scheme and the version included. Ship it as a default, not an option.
3. Send small pull requests upstream. Pick the community integrations with the most usage and offer a one-line change. Keep it minimal and explain exactly what it sends, which should be nothing beyond the client name and version.
4. Write the privacy line down. Put "who, never what" into your engineering guidelines and your public docs, so the boundary is visible to both your team and the developers who depend on you.
5. Set a decision rule for the data. Decide in advance what you will do with it. For example, an integration whose named usage stays near zero after a set period gets reviewed, and one whose usage is growing gets investment. Rules set ahead of time keep the numbers from becoming a story you tell afterward.

Seeing the channel you already have

Most teams building for agents already have more agent adoption than they can prove. The traffic is there. It is just unnamed. A client identifier in every integration does not create that adoption, but it makes it visible, which is what lets it survive planning.

The restraint matters as much as the instrumentation. The point is to know which doors agents are coming through, not to read over their shoulders once they are inside.