AI as a platform, not a feature

The quickest way to ship AI is to bolt it on. A chat box in the corner, a “summarise” button, an assistant that answers questions about your data. It demos beautifully, and the trouble only shows up later. It always shows up in the same place.

Every one of those features has to solve the same hard middle. Get the right context in front of the model, keep the answer tied to something real, and don’t make things up. That part is genuinely difficult and completely invisible in a demo, so each feature ends up solving it alone: its own retrieval, its own prompt, its own idea of what counts as a source. Ship three AI features and you’ve built the same fragile plumbing three times, three ways.

The alternative is to treat AI as a platform rather than a feature. Build a layer between your data and your products that does the hard middle once. Documents and feeds land on top: PDFs, emails, tickets, a table in the warehouse. Underneath, one pipeline ingests them, splits and embeds them, indexes them, retrieves and re-ranks against a real question, and runs the agent that answers. Products draw on that instead of reinventing it.

Put that way it sounds like tidiness for its own sake, which is never a good enough reason to build anything. The reason it’s worth it is trust.

The part you can’t bolt on

A feature will answer. That’s the whole problem. Ask a bolted-on assistant “what was our 2027 revenue forecast?” and, if the honest answer is that there isn’t one, it will still hand back a confident number. It has no notion of grounding, so it has nothing to decline with.

A feature will answer. That's the whole problem.

A platform can be built to behave differently, because the behaviour lives in one place. Every claim carries the span it came from. When nothing in the corpus supports the question, the answer is “no supporting source,” not a plausible invention. Getting that right is fiddly. Provenance, refusal, the evaluations that keep them honest: you don’t want to be solving all of that separately in every feature. You want it to be a property of the ground everything stands on.

So the real case for a platform isn’t that it’s neater. It’s that the things you most want from AI in a serious product, a citation under every claim and a refusal instead of a guess, are properties of a foundation. They are very hard to make properties of a button.

When it isn’t worth it

None of this is free, and the honest version has to say so. A foundation is far more work up front than a feature. If you’re adding one AI touch to one product, and it doesn’t much matter when it’s wrong (a first-draft helper, a piece of internal tooling), build the feature and move on. The platform is the wrong shape for that, and you’ll carry its weight for no return.

Is AI a feature of this product, or the ground it stands on?

The foundation earns its keep when AI is central and recurring. When you’ll ship more than one surface on top of it, or a single surface that genuinely has to be trusted. That’s the test worth applying before you write any code. Not “should we use AI,” because everyone will, but “is AI a feature of this product, or the ground it stands on?”

It’s a product decision long before it’s a technical one, and the answer sets the architecture. For what it’s worth, that’s the thinking behind the platform I build on now. Solve ingestion, retrieval and trust once, and let each product be a thin, honest surface on top. The first of them is already in people’s hands. The foundation is the point.