For about thirty years, "using a product" meant the same thing: you opened its app, or you went to its website. That assumption is quietly coming loose. More and more people now start the day inside an AI assistant — ChatGPT, Claude, Le Chat — and simply ask it to fetch things, reason over their stuff, get things done. Which raises a question every product owner should be sitting with: when your customer's first instinct is to ask an assistant, can the assistant actually reach your product?

For Makuri — my AI tutor for immigrant kids — I decided the answer had to be yes. So Makuri now runs two small servers that speak a protocol called MCP. They do two very different jobs, and together they're a bet on where all of this is heading.

A quick word on MCP, because it sounds more intimidating than it is. The Model Context Protocol is just a common language that lets an AI assistant plug into an outside service — a universal adapter between assistants and the apps you already use. Anthropic released it in late 2024 and then handed it to a neutral industry foundation in 2025; by that point there were already more than ten thousand of these servers running in the wild. It went from curiosity to plumbing in about a year.

It's already happening

And not among hobbyists tinkering in garages. In June 2026, Strava — the fitness app with roughly 195 million users — shipped an MCP connector that lets its subscribers ask an AI assistant about their own training. Instead of squinting at a dashboard, an athlete can just ask, in plain language, which workouts actually improved their fitness, and get an answer drawn from their live data. Coinbase released a payments MCP so AI agents can work directly with crypto wallets and stablecoin transactions. Block — the company behind Square and Cash App — was an early backer of the protocol and helped stand up the foundation that now governs it, alongside Anthropic and OpenAI, with AWS, Google, Microsoft and Cloudflare in the room.

When that many serious companies converge on the same plug, it stops being a trend and starts being infrastructure. That's the backdrop. Here's what I did with it.

Door one: the product, explained to AI

The first server faces outward. It lives at mcp.cogniledger.eu, and its only job is to answer questions about Makuri — accurately, from the source. What does it cost? Which languages does it support? How does it handle children's safety and data? When someone asks their AI assistant about Makuri, the assistant doesn't have to guess or invent; it can pull the real answer straight from us.

It is deliberately boring and deliberately safe: read-only, public, and containing exactly zero user data — no child's information ever touches it. For a platform built around children, that line isn't up for negotiation. Think of this server as Makuri's fact sheet, written for machines: the layer that makes the product legible to AI. (I documented building this first server in an earlier three-part series on this blog, so I won't rebuild that story here.)

Door two: your data, in your assistant

The second server faces inward, and it's the more interesting one. Inside Makuri, every student has a notebook — the explanations the tutor generated for them, saved to come back to. This second server lets a student carry that notebook into whatever assistant they already use, and study from it right there: quiz me on my notes, explain the one about inertia more simply, what should I review today?

This is, at heart, the exact move Strava just made for 195 million athletes — give people their own data inside the assistant they already live in. The notebook stops being trapped inside one app. The learning follows the student.

And because this is a child's data, the how matters as much as the what. Access runs through a single, revocable key that is read-only and scoped to one student — it can read that child's notes and nothing else. No login, no account takeover, no reach into anyone else's data, and no subscription required to use it: the notes belong to the student, and so does the right to take them elsewhere. If a key ever leaks, one click retires it. Built for kids has to mean built carefully.

Why I started small on purpose

Let me be honest about scale: this second server is a first stroke of the pen. Today it does one modest thing — read a notebook. But the feature was never the point. The point was the pattern: a clean, authenticated, tightly-scoped doorway through which an outside AI agent can talk directly to Makuri. Once that doorway exists, widening it is a known quantity — more capabilities, richer tools, new kinds of access — added deliberately, as they're earned, rather than bolted on in a hurry later. I built the small version on purpose, because the architecture is the asset, not the demo.

The bet

Here's the wager underneath all of it. For most of computing history a product had one front door: its own screen. That assumption is loosening. People will increasingly reach products through assistants of every kind — chat, voice, agents acting on their behalf — and a product built only for its own app is quietly betting that its screen stays the center of the universe. I'd rather not make that bet. Makuri is being built to be reachable both ways: directly, through its app, and indirectly, through the assistants people already trust. The two servers are the first concrete proof that the second path is open — outward, here is the product, and inward, here is your data.

If I built it for myself, I can build it for you

Which is why this matters well beyond one tutoring app. I run CogniLedger, an AI consulting practice, and Makuri is where I build the things I then bring to clients. These two moves — make your product legible to AI, and give your users a safe channel to bring their own data into the assistants they use — aren't EdTech-specific. They apply to almost any company whose customers are starting to live inside AI assistants. Strava did it. Coinbase did it. A solo-built tutor for immigrant kids did it. The size of the company is not the gate; the decision is.

So the honest pitch is also the simplest one. I didn't read about this and write a deck. I shipped it — into a live product built around children's data, as a non-developer directing AI to write the code, with compliance treated as a starting constraint rather than an afterthought. If I could build it for myself, I can build it for you. That's the whole bet, and it's already paying off for companies far larger than mine.

_If your customers are starting to ask AI assistants about you — or to do things on your behalf — that's the moment to make sure the assistant can actually reach you. That's the work I do at CogniLedger. Let's talk →