Referrals-to-zero: the anti-agency metric

There is a specific way that AI software companies stop being software companies. It is gradual, it is well-intentioned at every step, and it is usually invisible until the margin structure has already changed.

A customer hits something the product cannot do. Somebody helps. Helping works, the customer is happy, and the help is repeated for the next customer. Within a year there is a team whose job is doing the thing the product was supposed to do, and the company's economics have quietly become an agency's while its story is still a software company's.

The metric that catches this is a count of referrals to human services, and the target is zero.

What counts

A referral, for this purpose, is any moment where a customer's need is met by a human doing the work instead of by the product doing it. Whether the human is ours, a partner, or a contractor the customer hires on our suggestion does not change the count.

Three things deliberately do not count.

Support. Answering a question about how the product works is support, and support is permanent. Confusing it with a capability gap makes the metric useless.

Onboarding and configuration. Setup assistance is a real cost and a different problem. It shows up in a different number.

Advice. Telling someone what we would do is not doing it for them.

What counts is delivery. If the product cannot produce the outcome and a person produces it instead, that is one, and it goes in the record with the capability that was missing.

Visible, not reported

A metric that is compiled for a quarterly review will be compiled by someone with an interest in it looking reasonable. Not dishonestly — through the ordinary process of deciding what qualifies.

The version that works is recorded at the moment, by whoever made the referral, as part of doing it. No approval, no categorisation meeting, no threshold below which it is not worth logging. The recording has to be cheaper than the deliberation about whether to record.

The payoff is that the record becomes a product backlog with unusually good prioritisation. Each entry names a capability gap that a real customer hit at a real moment. That is a better roadmap input than any request board, because a request board records what people say they want and this records what they could not do.

Reading the trend

Three shapes, three different meanings.

Rising with a widening set of causes. You are entering new use cases faster than the product covers them. Common during expansion and not alarming on its own, provided the causes are new each time.

Rising with a narrowing set of causes. Warning. The same gap is being papered over repeatedly by people rather than closed by software. This is the shape that turns into a services team, and it does so within about two quarters if left alone.

Flat and non-zero. The most dangerous shape, because it is comfortable. A stable referral rate means an accepted permanent gap. Accepted permanent gaps become organisational structure, and organisational structure is very hard to reverse.

The rule we hold is that any cause appearing three times becomes a mission with acceptance criteria, not a note.

Starting the record

This does not need software and should not wait for any.

One shared list. Four columns: date, customer, the capability that was missing, and who did the work instead. Written by whoever made the referral, at the time, in under a minute. No triage, no owner, no status field — status fields turn a log into a workflow and workflows do not get filled in.

Two rules keep it honest. Anyone can add a row and nobody can delete one. And the list is read at the same cadence as revenue, by the same people, because a metric reviewed less often than the thing it is supposed to protect will lose every time they conflict.

Within a month the list will contain something you did not know. It usually contains a capability gap that three separate people had each worked around privately, each assuming it was specific to their customer.

Why this metric and not satisfaction

Customer satisfaction goes up when you help people. That is the trap. A company drifting toward services will see satisfaction improve throughout the drift, and will read the improvement as validation.

Referrals-to-zero is adversarial to the comfortable interpretation. It gets worse when you solve a problem the wrong way, which is the only useful property a metric can have.

It also encodes a commitment that is otherwise easy to state and hard to keep: software all the way down, with no agency inside. No Brainis employee executes customer work — delivery is your team plus governed agents, end to end. That claim is only worth making if something in the company is structured to catch its violation, and this is that something. The positioning argument sits on why Brainis; the delivery mechanism is the agent fleet.

Why we are not publishing ours

We track it. We are not publishing the figure, because we are not yet publishing any operating number we cannot render live from the underlying records.

A number typed into a blog post is a number a human chose and could have chosen differently. That is precisely the class of claim this whole estate exists to refuse, and making an exception for a flattering internal metric would be the least defensible place to start. When the trend can be rendered from the record, it renders. Until then, the honest version of this post is the mechanism and not the value.

The category argument for why the drift matters — and why it is a structural problem rather than a discipline problem — is in why AI agencies won't scale.