How a small brain watches a large business

There is a design tension at the centre of any system that reasons about a business in real time, and it is worth understanding because it explains why most "AI dashboards" are slow, expensive, or quietly out of date.

The reasoning part has to be fast. It runs in memory. That is where the speed comes from, and it is also the ceiling: memory is finite and fixed. Give it more than it can hold and the load fails.

The data part is not small. One performance feed produces a row for every entity, every hour, for every connected ad account, and each row carries a couple of dozen columns. Multiply by every account, every client, and all of history, and you are in the billions of rows. You cannot pour that into a fast in-memory engine. You also should not want to: it would never read most of it.

The graph does not need your rows

Look at what the reasoning actually needs to know:

• This campaign burned its entire daily budget in the first hour.
• This creative's cost per conversion has climbed week over week.
• This budget line is 80% spent with three days left.
• Click-through over the last 7 days is well below the trailing 30-day median.

Not one of those is a raw row. Every one is an aggregate over a time window and an entity. Which means the engine does not need the data. It needs the statistics.

So you compute the statistics where the data already lives, in a columnar warehouse built for exactly that, and you feed the engine only the summaries. The graph stays a lean, live model of the business instead of a lake it has to swim through.

The hard part is freshness, not size

Aggregating is easy. Aggregating continuously, cheaply, for many clients whose data arrives at unpredictable times, is the actual engineering problem.

Note the first example above: a campaign that burns a day's budget in an hour. You only catch that if two things are true at once. The statistics have to resolve to the hour, and they have to reach the engine while that hour is still young. Nightly rollups surface it the next morning, by which time the money is gone. Fine grain and near-real-time freshness, together, or the whole thing is a report rather than a control.

The way through is to organise the pre-computed statistics around the unit that data actually arrives in, which is a single connected account. When one account delivers new numbers, only that account's slice is recomputed. Every other account, including every other client's, is untouched. Refresh cost then tracks the size of the change rather than the size of the history, and it can run all day without the bill climbing.

Why any of this matters to you

Two reasons, and neither is technical.

Speed of the answer is a design consequence, not a promise. When someone says a system decides in days rather than quarters, this is the layer that makes it possible or makes it a lie. A system that has to scan history before a rule can fire is a system whose rules fire too late to change the outcome.

Watching costs something, and the architecture decides how much. A design that recomputes everything whenever anything changes is a design that gets more expensive per client. That cost has to end up somewhere: in your fee, or in less frequent checking. Both are worse for you.

Which is the real reason to ask a vendor how the watching works. Not out of technical curiosity. Because the answer tells you whether the speed survives your tenth month.

The plain-language version of a problem being worked through in public by the teams building autonomous growth systems. Manta's note on larger-than-memory graph statistics has the full engineering treatment.