Your AI or Mine?

I’ve lost count of the launch videos. A product tour, some upbeat music, and then the reveal: our AI companion now has superpowers. Every software vendor seems to be asking the same question at the same time. How do we monetize this AI thing? What can we charge for?

Working on the product and engineering side of a software platform, I see two very different answers.

The first is to put a language model inside the product, wrap it in your interface, and charge for it. An assistant in the corner, an add-on on the price list. In practice, it often becomes an AI-assisted WYSIWYG editor. The model gets pointed at the shiniest part of the product, usually design: describe the store of your dreams and watch it appear. It demos beautifully. It also leaves the harder, less visible parts, like the data model and daily operations, mostly where they were.

The second is to open the platform up. Publish an MCP server, write down how your platform is meant to be used as skills, and share them with the world. Let your customers bring their own AI to your product, instead of only the one you’ve built in.

The first path is the easy one, and I understand why boards like it. The margin is easy to calculate: for every token a customer burns, we make this much. It’s a new revenue line, and somewhere a presentation with a hockey-stick chart always appears. And to be fair, it looks like a real opportunity. Others are doing it, and the potential is there.

What’s rarely shared is what it turns you into. A reseller of someone else’s model, with a user interface on top. The AI providers set the price of what you’re reselling, the models change every few months, and your customers can buy the same intelligence directly. I don’t think rebuilding a software business around reselling tokens is a good idea. The platform is what you’re good at. The model isn’t yours.

I use Miro a lot. Last year I was apparently among their top 5% of users, and they reached out to interview me. At some point, they asked about their AI features and whether I would use them.

I answered with a question, mostly thinking out loud. I’ve spent a lot of time and effort getting to know my own AI. By that, I mean the assistant I chose and pay for myself from one of the big AI providers, Anthropic, OpenAI, or Google, which I’ve since given memory, context, and access to my tools. It knows a lot about me. It has access to parts of my work and my life that I don’t want to share with every software vendor I use. So why can’t you let my AI work on your platform instead of making me use yours? In other words: why your AI and not mine?

I don’t think I’ll be unusual in this for long. People are getting smarter about AI, and many have already put real time and effort into their own way of working with it: their assistant, their context, their tools. It took work to get there. They know how it works now, and they don’t want to start over in every product they use. Being pushed into a built-in assistant with guardrails that don’t fit how I work feels like a step backward. As an organization, I wouldn’t want my colleagues doing that either.

By "my AI" I don't mean everyone building their own personal setup. That doesn't scale beyond a handful of people. In an organization, it means one AI the company has chosen, say Claude, with the orchestration done once and shared: which tools and platforms it connects to, which skills it uses, what context it gets, and which guardrails it runs with. Everyone has their own account, but they all plug into the same setup, and when it improves, it improves for everyone. It's "my AI" because it's the one I work in every day, not one that each vendor hands me.

Sure, some organizations will happily pay for the AI add-on in every tool they use, essentially buying the same tokens again with each vendor’s margin on top. It’s easy to buy and easy to roll out. But it feels short-sighted. It’s not clear what it actually changes, and every built-in assistant is one more place where the company’s context gets split up.

Picture two organizations using two different platforms.

The first works on a platform that publishes its skills openly, keeps them updated, and shares them for free. There’s a free tenant to experiment in before anything goes live. Their own AI connects over MCP, reads the skills, and gets to work. When it makes a decision, the reasoning behind it is right there to read, question, and improve.

And because it’s their own AI, it isn’t limited to that one platform. It can reach out and pull in information from other sources and third parties. It gets the latest features from the AI provider the day they ship. They choose the model that fits the job. Nobody in between has to update or implement anything first.

The second works inside a built-in interface, where the AI makes many decisions for them out of sight. It’s fast, and it demos well. But it’s built for a set of predefined use cases, and it can only reach what the vendor has connected. New capabilities arrive when the vendor gets around to them. It also creates a strange kind of dependency. The vendor earns a margin on every token; sometimes that may even mean they opt out to a cheaper model that’s maybe good enough, but not always the one that’s best for your problem. And every new use case becomes something new to price. Who knows what the next one will cost?

Both delegate decisions to AI. The difference is who sits in the middle and what they optimize for.

A skill is really just experience, written down. Years of doing something, turned into instructions an agent can follow. So why not charge for it? It’s a fair question. It took years to build, and it’s valuable.

I think you can, right up until someone shares the same thing for free. And someone always does.

That isn’t an accident. It’s how our field has always worked. Open source. Communities where experts answer strangers’ questions for nothing. Talks, blog posts, and best practices written up and handed over. Not because people are naive about money, but because most of us share a simple ambition: we want good, sound products to get built. Sharing what we know is how that happens.

Skills are just the newest format for that culture. If one vendor keeps its knowledge behind a paywall, a community somewhere will write it down and give it away.

Maybe it’s naive, but I believe knowledge is meant to be shared, not fenced in. Having been part of these communities, and trying to share what I know as openly as I can, I’ve learned that sharing best practice doesn’t leave you with less. It leads to more. More trust, more people building on what you made, more reasons to come back.

Remember the assistant in the corner from the beginning? That’s where it stays. In the corner of one product, knowing only what that product knows.

Meanwhile, the setup I’ve built for myself keeps getting better. My assistant, the context it has about me and my work, the tools it can reach, the way I’ve learned to work with it. Every week I add something, and every week it gives a little more back. It’s worth more than it looks from the outside, because nobody else could have built it. My work, my habits, and my mistakes shaped it.

No software company can replace that. Not because they aren’t trying, but because it isn’t theirs to build.

So if I get to give one piece of advice, do what Johnny Castle does. Don’t leave your AI sitting in the corner of a token reseller’s tool. Take it out onto the dance floor of your daily work: your own setup, your workflow, the context you give it. The time and effort you put into building a way of working with AI that fits you, your team, your department, or your whole organization never goes to waste. It’s yours, and it keeps paying back long after the next built-in assistant launches.