Your Platform Should Meet You Inside the AI You Already Use

I've been putting off the third piece in this series because it's the one with a dependency. In the first I argued that bolt-on AI hits a ceiling, and that getting past it is a question of architecture rather than features. In the second I argued that when a system is built to be operated by AI, intent becomes a second way in — a faster path alongside the screens, for the people and moments it suits.

Both of those rest on something I kept deferring: for any of it to be real, the platform's actual operations have to be reachable. Not describable. Reachable — by a machine, acting on your behalf, from wherever you already work.

That's the open part. It's also the part that has quietly stopped being theoretical.

The tab problem was never about the AI

Go back to what firms in our industry actually use AI for: copy, emails, product descriptions, mockups, reporting. All of it useful, and all of it happening in a separate tab. You describe what you need, you get a draft, and then you carry it back by hand into the system where the work lives.

I called that the tab problem, and the tell is the carrying. PPAI's own research found the number-one barrier to AI in branded merch wasn't cost or skepticism — it was system integration, named by more than half of distributors. That is not a complaint about AI being bad. It's a complaint about software being closed.

The AI was never the missing piece. The door was.

What changed

For most of software's history, if you wanted two systems to talk, somebody wrote an integration. Then REST arrived, and the cost of that conversation collapsed — not because REST was clever, but because it was common. Everyone agreed on roughly the same shape, so a connection stopped being a project.

Something equivalent has now happened for AI. There is an emerging open standard for how AI clients call software — a common way to describe what a system can do, and to let an assistant do it. The name matters less than the consequence: the AI tools our industry has already standardized on can, in principle, reach the platforms our industry runs on. Not through a scraped screen or a copied paragraph. Through the real operations.

Which reframes the question I left hanging at the end of the first piece. It isn't whether your platform has an AI feature. It's whether your platform shows up inside the AI you already use — or asks you to leave it.

Reachable is not the same as exposed

Here's the uncomfortable part, and the reason this is an architecture story rather than a roadmap story.

You can't retrofit reachability. An assistant bolted onto a twenty-year-old system can only touch what that system already exposed — and what most systems expose is a screen, not the operations behind it. You end up with an AI that can narrate your platform and not operate it, which is the tab problem again with better manners.

Reaching further goes all the way down. At Brikl it meant consolidating roughly twenty backend services into four, so that every action available in the interface could be exposed as a tool cleanly and consistently. I'm describing our engineering choice, not making a claim about anyone else's. But it's the reason "add AI later" and "build for AI" produce genuinely different products, and why the difference isn't visible from a feature list.

If you want the specifics of what that looks like — the protocols, the supplier side, the review path — I wrote them up separately in Your AI Should Reach Your Systems. This piece is the argument; that one is the mechanics.

An open door still needs a doorman

Every time I make this case, someone hears "let the robots in," and they're right to flinch. Access without governance isn't a feature, it's a liability.

So the same three things have to be true of an AI client that are true of any other connection. It authenticates for real — no anonymous access. It works inside scoped tools, where you decide what it can see and what it can do. And every write it makes lands in the same review queue as a REST call, a webhook or a human edit, with a payload diff, before anything goes live.

That last one is the part I'd push hardest on if you're evaluating anybody's version of this. An agent that can act without leaving a reviewable trace isn't advanced, it's unaccounted for. The door being open and the door being watched are not in tension. They're the same design.

The economics quietly flip

There's a commercial detail here that I think gets missed, and it favors the buyer.

When you use your own AI client, that client runs on your own AI subscription. The tokens are already paid for. The platform's job in that arrangement is to provide the door, not to run the meter — nobody has to price, resell or mark up AI usage, because the value isn't the model. It's the access.

I find that clarifying. It means a platform's incentive is to be reachable, not to keep you inside its own chat window.

And for suppliers, the work disappears

The supplier side of this is the one I'd have expected to be hardest and turned out to be the opposite. On Brikl, each of a supplier's services answers over four protocols — SOAP, REST, MCP and PromoStandards — from the same data, under the same rules, all of it generated, hosted, versioned and maintained for them. There's nothing to build and nothing to run. An AI client reads the same catalog and places orders against the same state machine as a distributor on PromoStandards.

Which is roughly the point. The standard only pays off if being reachable stops being a project.

Where the series lands

Three pieces, one argument, and it's smaller than it sounds.

Bolt-on AI suggests and a human executes; AI-native executes and a human decides. That only becomes possible if intent can be an interface. And intent can only be an interface if the platform's real work is reachable — openly, from the tools you already have open.

Brikl for AI, which lets you run the business from your own chat, is coming soon; it ships after v3.0. I've deliberately spent three pieces on the principle rather than the product, because the principle is the part you can evaluate today, in any platform you're considering, including ours. Ask what an AI can actually do in it. Ask what it's allowed to do. Ask whether the answer arrives in the tool you already use, or requires you to go somewhere else and come back carrying it.

The industry spent a decade deciding how to describe a product. The next one is about who — and what — can reach it.