The Field Guide · Term

Human-API Analysts

When your best analysts spend their week serving lookups a governed layer should serve.

Definition
Human-API analysts is the pattern where an organization's analysts function as a request-response interface to its own data — re-answering the same questions, re-validating the same numbers, re-explaining the same definitions — because no governed layer exists for people or machines to read directly.

The most expensive query engine you own

Watch a data team's intake channel for a week. Most of what arrives is not analysis — it's retrieval. Which dashboard is right. What this metric includes. Whether this number can go in the deck. Each request routes to a person, because the person is where the answer lives. The analysts have become an API: high-latency, salary-priced, and rate-limited by burnout.

The pattern is a symptom, not a staffing problem. Answers recur because they're stored nowhere durable; definitions get re-litigated because none is canonical; validation is re-performed because trust was never made legible. Hiring more analysts adds capacity to the wrong layer — the queue drains faster and refills at the same rate.

It's also the honest test of AI readiness. The questions flooding your analysts are exactly what leadership hopes a copilot will absorb. But a copilot pointed at the same ungoverned sprawl the analysts navigate by memory doesn't inherit their judgment — only their workload, minus the caution. The way out is the same either way: a governed layer that serves the recurring answers, so both humans and machines stop paying the retrieval tax.

How it shows up

A senior analyst's calendar is diagnostic: hours blocked for “data questions,” the same five metrics explained to the same three departments in rotation. The organization's real metric registry is this person's memory — unversioned, unbacked-up, and two weeks of PTO from an outage.

The compounding cost is invisible in any single week: the analysis that never happened. Teams staffed for insight ship lookups instead, and the interesting questions — why the cohort behaves differently, what the margin pattern means — wait indefinitely behind the queue.

How to detect it

  1. 01

    Sample a month of intake requests. Tag each as retrieval (the answer exists somewhere) or analysis (new work). Most environments are surprised by the ratio.

  2. 02

    Ask what fraction of analyst hours goes to repetitive, mechanical requests. If nobody can answer, that is itself the answer.

  3. 03

    Test the bus factor: could the team answer stakeholder questions if the most senior analyst left tomorrow?

  4. 04

    Check whether recurring questions are captured anywhere durable — or re-answered from scratch each time they arrive.

Questions, answered plainly

Isn't answering questions literally the analysts' job?

Answering new questions is. Re-answering solved ones is a systems gap wearing a job description. The distinction to draw is retrieval versus analysis: retrieval belongs in a governed layer both people and AI can read; analysis is what you actually hired for.

Does a copilot fix this?

Only after the governed layer exists. A copilot on ungoverned definitions automates the confusion — it serves the four conflicting answers faster. Sequence matters: govern the definitions, then let a grounded copilot absorb the retrieval load with citations and refusal built in.

What's the first practical step?

Instrument the intake. A month of tagged requests tells you which 15–40 definitions carry most of the retrieval load — and that list is the scope of the governed layer worth building first.

Watch it run

Adjacent terms