Five Tests for Your First Company-Brain Use Case

The first use case sets the tone for everything after it.

Get this one right and the second is materially easier, because the first build leaves a slice of the foundation underneath it. Get it wrong and you spend the budget proving nothing. So the question of where to start deserves more care than it usually gets. This note gives you five tests to apply, and answers the fair questions that come up before anyone builds anything. The wider argument is in the pillar note on the company brain.

Where to start: five tests

A good first use case passes all five. Treat them as a checklist, not a wish list.

• It hurts, and it happens constantly. High volume, real hours sunk into every instance, and someone in the business can already put a number on it. If it is rare or cheap, the value is too small to prove anything.
• The inputs are reachable. The information exists in systems, documents or people's heads, and someone can actually get at it. Reachable is the key word. Knowledge that exists but cannot be retrieved is not yet an input.
• The work is bounded and checkable. A defined input, a defined output, and reviewing a result costs far less than producing one from scratch. If checking the answer is as hard as producing it, you have not saved anything.
• You can measure the before. A baseline exists, or can be set in week one, so the value is measured rather than argued about later. Without a baseline, every claim about impact becomes a matter of opinion.
• It sits at the centre, not the edge. The systems and entities it touches are the ones the next use cases will need too. A use case on the edge solves one problem. A use case at the centre solves one problem and builds the foundation.

Every use case adds something to the foundation. The one you want adds what the next ones will need.

That last test is the one firms skip most often, and it is the one that decides whether the second build is cheap or a fresh start. It connects directly to the sequencing choice in buy, rent, or own the AI layer.

Fair questions before anyone builds anything

These are the questions that actually decide whether this is worth doing. They are worth asking out loud.

Is this just RAG with a new name?

Retrieval is one part of it. A brain also holds why decisions went the way they did, and it writes back what it learns. Retrieval on its own resets every time. That difference, memory that persists versus retrieval that forgets, is the whole point, and it is covered in why every AI tool hits the same ceiling.

What stops this becoming another stalled data programme?

Nothing, if you sequence it the old way. The safeguard is that every build has to ship something usable before the next one starts. That is what keeps it from turning into a two-year foundation project with nothing to show in the middle.

Will it stand up to an audit?

Only if that is a property of the layer rather than a report bolted on afterwards. Every action should carry its source, its reasoning and who signed it off. Audit built in is defensible. Audit added later is a patch.

What if our data is a mess?

Cleaning what one use case needs is part of that build, so a mess is manageable when it is scoped to the work in front of you. Data that was never captured in the first place is the thing that actually stops you. Absent data is a harder problem than messy data.

What happens when the models change?

You swap them. Models, agents and interfaces are all replaceable. The context layer they draw on is the part that is not. Building on the layer rather than on any one model is what makes model change a non-event.

Sequencing is the risk, not the technology

Most of the risk here is sequencing, not technology. Models and tools are swappable. The order you build in decides what exists at month six.

Start where the work hurts today.

One use case, solved end to end, with a slice of the foundation built underneath it. That is the whole method, and it is deliberately modest, because a modest first build that ships beats an ambitious one that stalls.

You can download the full field note for the complete field note, or send us a first use case. We are happy to pressure-test one against the five tests, and say so if it is not one.