The Telephone Game

I spent last weekend testing out Copilot for Power BI. I’ve been using it extensively as a developer, trying to make something that’s useful for people. I’ve been growing more skeptical of all my technical skills.

I went into the Azure calculator, pulled up the resource usage, all told would be no more than $5.00. Salespeople. I made the Power BI report, ran the Copilot queries. Documented the telephone game, deleted the resources.

Now I’m looking at what the telephone game cost. Not much, but for 5 hours for a single user running queries for only a small fraction of that time, a bill for $18.78. How did that happen?

I encountered the same when running my queries in Roo. This isn’t a post about money.

The Telephone Game

I showed in the last post that the Copilot pipeline is a chain: outer LLM rephrases the question, Q&A parser tries to match against the semantic model schema, if that fails a DAX generator fires as fallback, results go back to the outer LLM for formatting. Each step consumes CUs. Each retry consumes more.

The 107-second DAX generation with three retries was because a column got hidden in the semantic model. Metadata, not complexity of the ask. The Q&A parser kicked it to the DAX generator, which tried bad DAX three times before giving up. The diagnostic JSON shows all of it. Each attempt had its own token cost.

This is one tradeoff of a multi-agent system. Flashlight on the ground, looking for a problem that falls within its torch-light. Each node in the chain simplifies the problem to something it can solve. If you remove enough context or focus enough detail, anything becomes solvable. This means that four can chain together, with irrelevant details getting amplified. Telephone game.

The Q&A parser is good at what it does. The DAX generator is good at what it does. The handoff between them is where meaning drops out. That’s not a capability problem that gets fixed by making each node smarter. It’s a structural property of chaining agents.

Build vs. Run

The $18.78 bill on a restarted F2 capacity warrants another look, but not as a measure of cost, because if it means not hiring a third data analyst, then $3.70 per hour washes out. The problem is $3.70/hr/user. It runs counter to the trend of the last 40 years. Build vs Run.

Build. When you build a dashboard, it is a capital expense. Build it, done. Whether 5 people or 5,000 people look at it, the marginal cost per user is the same, nearly zero. If you use or rent a GPU, same.

Run. A Copilot query is an operating expense. Every question costs CUs. The more people use it, the more capacity it consumes. Until you invest in infrastructure or reserve capacity, success and cost scale together. Copilot answering “what were sales last month” for the 400th day in a row is going to incur 400 times the cost. The next person who asks pays again. To its credit, Fabric caches identical queries for 24 hours, though in my experience that also means you might get a “sorry Dave” question to multiple users if the first one had somehow triggered a refusal.

In between. I’ve seen people using Claude code to write the MCP tools where the tools exist and are deterministic after. The artifact is created and the marginal cost returns to zero.

The $0.91 in that Roo screenshot produced a working query and a colleague who now understands the data model. Copilot’s $0.075 produced an answer that evaporated when the session ended.

The Leverage Inversion

I went looking for data on how many people one person’s work typically serves.

Role	Ratio	How it works
Cashier	1:1	Sequential. One customer at a time.
Customer service (phone)	1:1	Synchronous. One call.
Customer service (chat)	1:3-5	Multiplexed. Concurrent sessions.
Nurse (acute care)	1:4-6	ANA recommends max 6 patients.
Teacher (OECD avg)	1:15	One-to-many, synchronous.
IT help desk	1:70-100	Gartner benchmark. Mix of sync and async.
Dashboard builder	1:dozens-hundreds	Asynchronous. Artifact serves people without you.
Software engineer	1:thousands-millions	Code is leverage. WhatsApp: 50 engineers, 1B users.

The low end is Baumol’s stagnant sector. William Baumol and William Bowen, 1966: the string quartet can’t play faster. Four musicians, same duration, every performance. The performer’s labor IS the output. You can’t increase productivity because there’s nothing to optimize away. But wages rise anyway because the progressive sector (manufacturing, tech) pulls them up. So the cost of live performance, healthcare, education rises without the work itself changing, called Baumol’s cost disease.

Software was supposed to escape this. Build once, serve at scale. Zero marginal cost of replication. Naval Ravikant calls code “permissionless leverage”: it works for you at scale without needing anyone’s permission. WhatsApp served 42 billion messages daily with a team that fit in a conference room. That’s what breaking out of the string quartet looks like.

The consumption model puts something interesting on the table. The “performance” (the query, the generation, the agent session) has a real cost every time it runs. A dashboard builder at 1:500 creates an artifact once and it serves viewers indefinitely. Copilot answering questions about that same dashboard is a separate interaction for each person, each question. The leverage ratio looks different.

“Pay for what you use” was cloud computing’s promise, and it was a good one. The meter was on your infrastructure. A VM you spun up, controlled, sized, shut down. This meter is on something else. Every person who asks a question, anywhere in the org, adds to the same shared capacity pool. The consumption is emergent. It’s the aggregate of individual curiosity across the entire company, billed to a shared resource nobody is watching at the question level.

Google handled this differently. Gemini is bundled into all Workspace plans at a flat rate, $7-26/user/month depending on tier. Prices went up 16-22% when Gemini was added. No per-query metering. Everyone pays whether they use it or not. Microsoft gives you the per-query meter but lets you opt out by not enabling Copilot. Different risk transfer models for the same underlying cost. When employees have access to both Copilot and ChatGPT, 76% choose ChatGPT. Both companies’ real moat is forced bundling with the productivity suite.

The Design Question

The consumption cost is proportional to how much reasoning you’re asking the LLM to do per interaction. That much seems clear from the data.

Copilot’s Q&A parser tier is a good example. Cheap pattern matching handles the easy stuff. If the user asks “what were total sales last month” and the semantic model has a measure for that, it matches directly. The LLM only fires on fallback. That tiered design keeps the per-interaction cost low for the 60-70% of questions that are straightforward. The same principle shows up in the MCP: five deterministic tools, the LLM picks which one and interprets results. Most of the work is in the tool, not the reasoning.

Contrast that with overly broad agent instructions. “You are a helpful data analyst, figure it out” with a dozen tools. The LLM is in the hot path for everything. Every instruction that could have been a tool, every decision that could have been a rule, every piece of context that could have been in the schema metadata, that’s reasoning you’re paying for per query.

People at my company are building Copilot Studio agents that encode their instructions into a prompt. That’s middle management in a different medium. Compare that to a coworker who wrote a script that bundles an entire repo into a file you can paste as context to an agent, with response parsing built in. One fills the existing pattern. The other gives people something they didn’t have before.

The “just make an agent” thing. A virtual employee that can be cloned infinitely sounds like an advantage until you notice that everyone else can clone one too. If the advantage can be replicated at marginal cost, it’s table stakes within six months. The question underneath that: what work stays valuable when everyone has agents?

Where I keep landing: general-purpose insight extraction layered on specific artifacts. Build a table, the AI uses it to answer a range of questions. Build a Gantt chart, the AI applies it to a suite of problems. The artifact is still the leverage. The AI is an interpretation layer on top. My colleague isn’t valuable because he has an agent. He’s valuable because he understands the business well enough to know which questions to ask and whether the answers make sense.

This isn’t only about LLMs either. World models, spatial reasoning, domain-specific architectures for things like protein folding. None of these are LLMs and all of them are moving fast. Yann LeCun left Meta and raised over a billion dollars betting that LLMs “will become useless within five years.” Whether he’s right about that is a different post. The design principle is the same regardless: minimize the expensive reasoning surface area, build specific tools underneath. If you build around a model type, you’re locked in. If you build around the principle, the reasoning layer is swappable.

The Turn

“Is It Okay” ended uneasy. The meter doesn’t help with that.

But the Power BI tool is important. It lets people find insights faster than I could. I’m not the bottleneck anymore. My colleague learned the domain through the MCP in ways he couldn’t have without it. He’s finding discrepancies nobody had surfaced before. That’s real. The MCP isn’t designed to teach him the business, but that’s what it does.

I entered the workforce at a time where the challenge was how to survive in a world where the model was front-load on education and hope it translates to experience before you retire. Drucker’s knowledge worker problem. Continuous learning as the strategy. Now I’m in a world where finding information is cost zero, but finding context is the whole game. The strategy was continuous learning. What’s the model for continuous experience?

Jack Dorsey cut Block from 10,000 to 6,000 employees and shipped 40% more production code per engineer. Tobi Lutke told Shopify employees to prove AI can’t do a job before asking for headcount. Salesforce stopped hiring software engineers. The investment thesis is headcount reduction. The “augmentation” framing and the “replacement” framing aren’t in tension. They’re the same companies saying both things in different rooms.

McKinsey says 6% of enterprises qualify as “AI high performers.” PwC says 56% of CEOs report AI has produced neither increased revenue nor decreased costs. S&P Global says 42% of companies abandoned most AI initiatives in 2025. IBM found that GenAI ROI averaged 31% in pilots but collapsed to 7% when scaled, below the typical 10% cost-of-capital hurdle. These numbers don’t mean AI doesn’t work. They mean the deployment model matters, and most organizations haven’t figured it out yet.

Both things are true at the same time. The consumption model changes the economics. And the tools let people do work that wasn’t possible before. There’s a version of this where the cost analysis is the whole story and the conclusion is “it’s bad.” There’s another version where the tools story is the whole story and the conclusion is “it’s great.” Neither version is honest.

The Landing

The purpose of a system is what it does.

The system isn’t designed to hide costs, but the 24-hour smoothing makes them hard to see. The system isn’t designed to invert leverage, but per-query consumption does change the math. Microsoft didn’t design Fabric to be opaque about Copilot costs. The Capacity Metrics app exists, the CU rates are published, the smoothing mechanism is documented. But the purpose of a system is what it does, and what the system does is make it very easy to not notice.

And the MCP isn’t designed to teach my colleague the business, but that’s what it does. The tool isn’t designed to surface discrepancies nobody found before, but that’s what it does.

Same principle. Both directions.

Look at the systems you’re building. Not what they’re designed to do. What they actually do.