Where Can We Add AI?

I have been sitting in a version of the same meeting for three years.

Someone presents a product. Someone else asks, brightly, where can we add AI to this? Everyone writes it down. It sounds like ambition, and for a long time I answered it as one.

I want to explain why I stopped.

The question hides an assumption so ordinary nobody notices making it: that AI is a thing you add. A layer on top of a product that already exists, to make it a little smarter.

Sometimes that is exactly what it is.

A better autocomplete. A summary where there used to be a list. If a capability is genuinely local — if it needs nothing from the rest of the system — then “add AI here” is a fine instruction, and you should stop reading and go add it. I am not here to make a simple thing complicated.

But most AI is not local. And the reason is not deep. It is practical.

The same feature, built in two houses

Take one capability — a system that recommends a fix for a problem it has found — and build it inside two different companies.

The first builds it as an add-on: its own data, its own model, its own private idea of what a good fix is. It ships. It works. Then the next AI feature is built the same way, and the next. Soon there is a shelf of clever features that share a logo and little else.

The second builds the same feature on shared foundations. On launch day the two look identical. They are not the same kind of thing — and the difference only shows once you add the second product.

Two houses for the same feature

Identical to a user on day one. The divergence is structural, and it compounds with every product you add.

Comparison of an add-on architecture versus a portfolio architecture across data, model, standard of quality, and cost of the next product.

	Built as an add-on	Built as a portfolio
Data	Its own pipeline	Feeds and draws from a common pool
Model	Its own model	One shared agent across products
Definition of “good”	Private, per feature	One standard, shared
The next product	Pays full cost again	Reuses the foundation; improvements compound
What the customer feels	Features that behave differently	One system that behaves like itself

The same visible feature, two completely different meanings — and the meaning was fixed by an architecture nobody remembers choosing.

I tried to make “add AI” the unit. It would not hold.

I ran product for a portfolio of AI security products — six lines, with a remediation layer across all of them. I kept trying to treat each AI decision as a local, per-product decision, the way the meeting wanted me to.

It refused to stay there.

The decision that mattered had always moved somewhere else — into the space between products, where three things want to be shared:

• Data. The fragmentation is almost never a data problem. It is an org-chart problem wearing a data costume: does a line pour its signal into a common pool, or keep it to itself?
• The model. A single patch agent sat at the center of all six lines. A shared agent is a shared bloodstream — an improvement reaches every product quickly, and so does a mistake.
• The definition of good. The one everyone skips, and the one I would lie down in the road for.

The decision I actually had to make

Here is the one that was not abstract.

The definition of good had to live somewhere. We built it into a single evaluation suite — one suite judging the quality of what the system generated, running across all the lines instead of a different bar hiding inside each.

The fight was not whether to share the standard. Almost everyone agreed on that. The fight was where evaluation should live, and who has to run it.

Where should evaluation live?

The same shared standard, two ways to operate it. One keeps everyone’s hands clean. One keeps control over what “good” means.

Comparison of a frictionless evaluation path against an owned, maintained evaluation suite across five dimensions; the maintained suite was chosen.

	Frictionless	Maintained suite
Who maintains it	No one — nothing to maintain	A team owns it
Developer effort	None	Run it locally
Control over “good”	Loose, checked downstream	Tight, in one place
Adding a new line	Fast	Slower — this is the tax
What it optimizes for	Speed	Trust

I chose the tax.

And the tax was real. A maintained suite has to be maintained. It slowed down adding new lines, and every new engineer had to learn the codebase before building on top of it. We paid for control in expansion speed, and I could feel us paying.

I would choose it again. Here is the reasoning, because the reasoning is the point:

• The product’s real currency is trust. A developer has to believe a fix before applying it. A frictionless path that quietly loosened its grip on “good” would buy speed by spending the one thing the product cannot afford to spend.
• The frictionless path hid a waterfall. A suite that solves every use case for every line at once is not small — it means solving the whole problem before shipping any of it. That is a straight road into decision paralysis.
• Iterative is the fast option, not the slow one. Nail the first two lines; then onboarding the rest is continuous, not one heroic launch. The big all-at-once release only feels fast in the planning meeting.
• The suite is infrastructure, not QA. It became the surface where AI engineers and developers — not just testers — found out whether what they built was any good. A shared definition of good is the thing the whole team builds against.

Two ways to build the standard

Same ambition, opposite outcomes. The unglamorous path is the one that ships.

The tempting path

Solve every use case, every line, at once → Build the “perfect” universal suite → Decision paralysis — nothing ships

The path I took

Nail the first two lines → Onboard the rest incrementally → A standard that ships and compounds

What it looks like when it compounds

So I stopped asking where we could add AI, and started asking something duller and more useful.

What one capability, held for the whole portfolio at once, would make the next several products cheaper to build and easier to trust?

The shared agent and the shared definition of good are exactly that. There is a simple test for whether it is working: can an improvement made in one place show up everywhere it belongs, without anyone rebuilding it?

When it was designed that way, the numbers did not just rise. They compounded — fix success improved roughly tenfold from launch baseline to steady state, active use grew several times over, and enterprise accounts that kept using it multiplied. Not because any one feature got brilliant on its own, but because a single improvement could land in more than one place at once.

I am keeping those relative on purpose. The real figures belong to the company; the point does not need them.

A portfolio compounds. A shelf of add-ons just gets longer.

Where I stop trusting my own argument

A way of thinking is only worth anything if it will tell you where it breaks. This one breaks in two places:

• The shared bloodstream is also a shared wound. One bad change to a central agent is a bad change everywhere at once — and the governance on top, the checks and explainability and the audit trail a regulated buyer will ask for, gets harder as sharing deepens, not easier. The portfolio buys leverage by concentrating risk, and that concentration is never free.
• The discipline curdles into centralization. There is a version where one team owns all the AI, moves like a glacier, and starves the products it serves. Sharing is not a virtue you maximize — it is a line you redraw product by product, and the tax I chose to pay is exactly the cost you have to keep re-justifying past the second or third line.

The question I would rather be asked

Where can we add AI? is not wrong because it lacks ambition. It is wrong because it cannot see the things that make AI compound — so it fusses over the feature while the portfolio quietly decides what actually matters: what the shared agent learns, and what the system is allowed to call good.

The difference between a company that has AI features and one that has an AI portfolio is not the number of models. It is whether anyone decided, on purpose, what those models were allowed to share — and whether anyone can still answer, when a customer or a regulator finally asks, why did the system do that, and how do you know it was good?

That was never a feature question. It only wore the costume of one.

So before we ask where AI can go next:

What have we already, without quite meaning to, built the whole thing on?

I ran product for an AI security portfolio through this reasoning; the examples come from that work, told in relative terms and with implementation kept behind the NDA it belongs behind. That AI is a portfolio decision before it is a feature is a position built from operating experience, not a validated model — and the part about where it breaks is the part I would most like to be argued with.