The five jobs inside every AI business system.

AI products are hard to compare because everyone describes them differently. One vendor sells a copilot, another an agent, another a platform, another an assistant. The demos look nothing alike and the pricing pages are worse.

Underneath, they are all doing some subset of the same five jobs. Gathering, finding, judging, acting, proving. That is the whole list, and it has not changed in the three years the technology has been usable.

The useful part is that most products only do two or three of the five. The rest is left to you, and whether that is fine or fatal depends entirely on which ones are missing. Here is the map.

1. Gathering

Getting your business into a form the system can see: records, documents, events, and the rules nobody wrote down. This is the data foundation, and it is the job most often assumed rather than done.

A system that gathers well can answer questions about your accounts. A system that gathers badly answers questions about businesses that resemble yours. Both sound equally confident, which is what makes this the easiest job to skip and the most expensive one to skip.

The question to ask: what exactly can it see, and how did it get there?

2. Finding

Pulling the right slice of that material at the right moment. A model cannot hold your entire business in its head at once, and even where it technically could, feeding it everything makes it worse rather than better. Precision beats volume.

This is the job people mean when they say retrieval or RAG, and it is where a lot of the real engineering lives. Finding the six relevant paragraphs out of forty thousand documents is a harder problem than it sounds, and getting it slightly wrong produces answers that are wrong in ways nobody catches.

The question to ask: when it answers, can it show you which records it used?

3. Judging

The part everyone pictures when they hear AI. The model reads what was found and produces something: a classification, a summary, a draft, a score, a recommendation, a decision about what to do next.

This is also the job that has become the least interesting commercially, which surprises people. The models are extremely good and they are largely interchangeable for most business work. If your entire advantage is which model you picked, you do not have an advantage, because your competitor can buy the same one this afternoon.

The question to ask: what happens to this system when a better model ships next quarter?

4. Acting

Doing something in the world that outlasts the conversation. Filing a document. Updating a record. Sending a notice. Flagging an exception. Staging a draft for someone to approve.

This is the line between a tool you consult and a system that runs. It is also where authority has to be explicit, because an action has consequences a paragraph of text does not. A well built system acts only where it has been granted permission, inherits the access of the person it works for, and leaves every action reversible.

The question to ask: what can it change, and who decided it could?

5. Proving

The record of what the system did and why. Which records were read. What was produced. What action followed. Who approved it. When.

This is the job that gets cut first and missed most. It is what makes an answer checkable rather than merely persuasive, and it is the only thing that lets you improve the system, because you cannot correct a pattern you cannot see. In a regulated business it is not optional at all.

The question to ask: six months from now, can you reconstruct why it did that?

How to use the map

The next time someone demonstrates an AI product, run the list. Which of the five does it do, which does it assume you already have, and which does nobody own?

“Most disappointing AI purchases are a job-three product bought by a company that needed jobs one and five.”

The pattern is consistent. A great many products are excellent at judging, competent at finding, and silent on the other three. That is genuinely fine if you already have a data foundation and an audit trail, and it is the whole explanation for the pilot that impressed everyone and then quietly stopped being used.

It also explains why two companies buying the same product get different outcomes. They are not running the same system. They are running the same middle third of one, on top of very different first thirds.

None of this requires you to become technical. It requires five questions, asked in order, of anyone who wants to sell you something. What can it see. Can it show its sources. What happens when the model changes. What can it change. Can you reconstruct why.

Any vendor worth working with will enjoy being asked.

— Charlie