From the practice

Your Analysts Are Becoming Human APIs

When definitions live in people instead of a governed layer, analysts become a request-response interface to their own data — high-latency, salary-priced, rate-limited by burnout. The fix isn't headcount.

4 min read

Watch a data team's intake channel for a week and tag each request as it arrives. Not by urgency or by requester — by kind. Is this analysis, work that produces something new? Or is it retrieval — the answer already exists somewhere, and the somewhere happens to be a person?

Most teams that run this exercise are surprised by the ratio. The requests are overwhelmingly retrieval: which dashboard is the right one. What this metric includes. Whether trial accounts count. Why two reports disagree. Whether this number is safe to put in the deck. Each routes to an analyst, because the analyst is where the answer lives.

That's the pattern the practice calls human-API analysts: an organization's most expensive query engine, made of people. High latency. Salary-priced per call. Rate-limited by burnout. And — this is the part that compounds — completely undocumented, so every answer served evaporates instead of accumulating.

It's a systems gap wearing a job description

The tempting read is that this is what analysts are for. Answering questions is the job.

Answering new questions is the job. Re-answering solved ones is a symptom — and the distinction matters because the two problems have opposite fixes. If your team is underwater on genuine analysis, you hire. If your team is underwater on retrieval, hiring adds capacity to the wrong layer: the queue drains faster for a quarter and refills at the same rate, because the thing generating the queue — answers stored nowhere durable — hasn't changed.

The recurring questions recur for structural reasons:

  • No canonical definition. The metric means slightly different things in three tools, so every use requires a human to adjudicate. The adjudication is repeated because it's recorded nowhere.
  • No legible trust. Nothing distinguishes certified content from ad-hoc content, so careful stakeholders re-verify everything through a person. The re-verification is the trust system.
  • No capture loop. Slack answers, meeting decisions, exception rulings — the institutional knowledge gets produced daily and consolidated never.

Look at a senior analyst's calendar in this state and you can read the architecture: recurring blocks for "data questions," the same five metrics explained to the same three departments in rotation. The organization's real metric registry is that person's memory. It's unversioned, it doesn't back up, and it's two weeks of PTO away from an outage.

The copilot mistake

Here's where it gets expensive. Leadership looks at the intake queue and draws the obvious conclusion: this is exactly what an AI copilot should absorb. They're right about the destination and wrong about the sequence.

A copilot pointed at the same ungoverned sprawl the analysts navigate is not inheriting their judgment. It's inheriting their workload minus their caution. The analysts know which dashboard is stale, which definition the CFO means, which numbers need a caveat — that knowledge is precisely what never got written down. The copilot retrieves what did get written down: the sprawl. It then serves the four conflicting answers faster and more confidently than any human ever could.

This is how the human-API pattern feeds directly into credible failure. The queue was a symptom of missing governance; automating the queue without the governance automates the confusion.

The way out is the same for humans and machines

The fix is a governed layer that serves the recurring answers directly — to people and to AI alike — so both stop paying the retrieval tax.

Concretely, and in order:

  1. Instrument the intake. A month of tagged requests tells you which definitions carry the retrieval load. It's rarely more than the 15–40 metrics decisions actually run on — and that list, not "everything," is the scope worth governing first.
  2. Give each of those metrics a contract. One certified definition — formula, grain, owner, version — as code, where every consumer reads it. The re-litigated meanings get litigated once. (What that artifact looks like.)
  3. Make trust legible. Certified versus ad-hoc, marked and enforced, so the quiet "can you double-check this?" tax stops being the trust system.
  4. Then the copilot — grounded on the certified surface, citing what it reads, refusing what falls outside. It absorbs the retrieval queue safely because the queue's answers finally live somewhere a machine can be trusted to read.

The order is the point. Steps one through three pay for themselves in recovered analyst hours before any AI ships — and they're what make step four an asset instead of an incident.

The question worth asking this quarter

Could your team answer stakeholder questions if your most senior analyst left tomorrow?

If the honest answer is no, the problem isn't that person's irreplaceability — it's that your knowledge architecture has a bus factor of one and a salary line that grows with every hire. The analysts didn't choose to become an API. The system around them made it the only interface available.

Build the layer. Free the people. Then bring the machines. The five-minute scorecard will tell you how far from that sequence you're starting.

First published 2026-07-11 · kept current

Adjacent notes

Find out if your analytics layer is AI-ready.

Two paths: score yourself in five minutes, or bring the question to a working session.