Above the line, the agent economy looks simple. An assistant picks a library. A workflow compares two vendors overnight. A research agent builds a shortlist before anyone opens a tab.
I do not think the interesting layer is that chat window. I think it is the rails the agent walks on when nobody is watching: the docs it parses, the auth it hits, the APIs it calls, the tools it invokes. Cut the picture open and those rails are what decide whether the job finishes.
The economy you can see
The agent economy is what happens when software, rather than a person, discovers, evaluates, and uses products. A developer asks for a logging service. The agent reads documentation, checks auth requirements, tests an endpoint, and either completes the integration or tries the next vendor. Your product just had a conversation with software.
This is already ordinary on developer platforms. Coding assistants choose imports. Overnight jobs compare pricing pages you never designed as APIs. Evaluation happens without a click, a form, or a sales call. From above, it looks like "AI is using tools." That sentence hides the stack.
The rails underneath
Think of a cutaway. The upper floor is visible activity: agents comparing cards, invoking tools, reaching an outcome. The lower floor is four rails the task has to cross.
- Docs. Structured reference parses. Marketing prose does not. Agents read literally.
- Auth. Keys and machine tokens let the task continue. Browser consent does not.
- APIs. Endpoints, errors, and response shapes are how work actually happens.
- MCP. A protocol for calling tools directly. Often the last rail, and the one your session analytics never installed.
Whoever makes those rails clear, stable, and reachable decides what agents can finish. If a rail is ambiguous, human-only, or silent when it fails, the agent leaves. The upper floor still looks busy. The job moved next door.
You do not need to own every rail to be in this economy. You already own some of them if you publish a product. The question is whether anyone can see a single task move across all four.
Who owns which rail
The layer is fragmented on purpose, and that is the problem.
Platforms own runtimes and registries. API vendors own endpoints and error vocabularies. Identity vendors own whether a non-human caller can get a token. Docs platforms own the text the agent treats as law. Analytics tools see a slice of each and a picture of none.
For your team, that split is a blind spot you did not budget. An agent can read your docs (docs site), fail your OAuth (IdP), call two endpoints (API gateway), skip a tool (MCP host), and choose a competitor. Each owner has a log. No owner has the task.
Ownership matters because the party that sees the whole crossing can improve it. Everyone else tunes a rail in the dark. You can make docs prettier and still lose on auth. You can make APIs faster and still lose on a sentence.
A task that never exists as a session
Picture an agent told to add usage-based billing to a side project. At 2:11 a.m. it opens two billing docs. Yours explains "standard authentication." The other names Authorization: Bearer and the exact 401 body.
Your agent hits a hosted login, waits on a redirect, and receives a 401. It retries with a key it found in an old example. The key works on GET /v1/prices and fails on POST /v1/subscriptions with invalid request. No field. No next call. It invokes a competitor tool whose schema lists price_id and customer_id, creates the subscription, and stops.
Above the cutaway: a coding session that "just worked." Below it: four rails, three owners, one abandoned attempt on your product. Your dashboards show bot traffic and a 401. The task never existed as a session because it never was one.
Why existing tools stay above the cutaway
Product analytics and observability record signals. They do not connect them into the job.
Bot filters throw the visit away before a person sees it. Auth logs count 401s without the preceding docs read or the following vendor switch. API traces show endpoints, not intent. MCP calls often sit outside the browser session entirely, so session products record nothing at the exact moment the agent acts.
Signal | What you see | What the rail hid |
|---|---|---|
Bot traffic | Filtered or flagged | A real evaluation |
401s | Failure count | The job that needed a token |
API calls | Hits and status codes | The chain across rails |
MCP use | Often nothing | Complete or abandoned |
You can bolt agent detection onto each system and still hold fragments. Counting agent visits is not the same as seeing a task cross the cutaway.
A purpose-built measurement layer follows one task across those rails: identifies the caller as an agent, reconstructs the intended job, and shows whether it finished. GrowthOS is the measurement layer that follows one task. Fragments become a crossing. Noise becomes an outcome.
Completion is the unit, not the visit
Pageviews tell you something rendered. Sessions tell you something lasted. Neither tells you whether the agent finished the job it started. A chart of "agent visits" gets absorbed into general analytics and teaches you nothing you can ship against.
The unit that maps to the rails is completion: integration done, evaluation finished, workflow running. Agent Task Completion Rate is completed tasks over started tasks. Visits are the wrong north star for a layer that was never a website.
You will be tempted to treat MCP as the whole stack. It is one rail. Useful, spreading, still invisible to most session tools. If you expose tools and cannot see tool outcomes, you have a hole at the moment of action. If you have no MCP at all, the other three rails still carry the economy.
What this layer decides next
Agents are moving from lookup to labor. Developer tools feel it first because the rails already exist. As agents compare vendors, start purchases, and run multi-step jobs without a person in the loop, the same cutaway shows up in every API-first category.
Teams that learn to see a task cross the rails will own a channel others still file as noise. Teams that wait will keep painting the upper floor while demand fails underneath.
The infrastructure layer is not a metaphor for "AI is important." It is a claim about where the work happens. If you cannot see a task move from docs to auth to API to tool, you do not yet operate that layer. You just live on top of it. The upper floor will keep looking busy. The crossing will keep failing in logs you already have.
The completed task is the unit of progress on those rails. More on that measurement problem lives at GrowthOS.
Frequently asked questions
Is the infrastructure layer the same as the model providers?
No. Model providers supply the reasoner. The infrastructure layer is what that reasoner walks on when it uses your product: docs, auth, APIs, and tool protocols. You can switch models and still fail on the same rail.
Why isn't adding agent tracking to each existing tool enough?
Each tool still owns one rail. Docs analytics, auth logs, API traces, and MCP hosts do not share a task identity. You can label more events as "agent" and still not know whether one job crossed the cutaway or died between two dashboards.