BYOB: Bring Your Own Bot
Stop stuffing a chatbot into your product. Start building for the agent your user already has.
Every product is racing to add a chatbot. Most shouldn’t.
The pitch is always the same. AI is changing everything, so we added an AI feature. Then companies ship a sidebar with a chat input, slap their logo on it, and call it product strategy.
The problem isn’t that built-in AI is bad. It’s that the user already has a primary AI they use daily, and that AI knows more about them than any vendor ever will.
Most Built-In Chatbots Don’t Get Used
Priceline launched an AI travel agent earlier this year. The press release framed it as a leap in customer experience, but the actual experience is a chat window on the side of the same booking flow that’s been there for two decades. Instead of filling out a form, I chat in my trip details. Woo.
Quick question. The last time a product you use rolled out an AI feature, did you click on it once and forget it existed, or did it become a daily habit?
For most products, the honest answer is the first one.
The current race to slap a chatbot on a product is the same panic that produced “we need an iPhone app” fifteen years ago. Every company “needed” an app for some reason. Most of them shouldn’t have built one. The ones that did burned engineering cycles maintaining a worse version of their mobile website for a decade. The current AI bolt-on is the same thinking on repeat.
Built-In AI Is Context-Poor
Last month, we ran into this issue on our podcast. We use a tool called Descript, and one of its coolest features is that it will identify and pull shorts out of the longer video for YouTube and other socials. They use their built in AI agent, called Underlord, to ID and pull these shorts.
As a test, we pointed Claude Cowork at it from inside the Design Language project via MCP. It had the same instructions, but it was able to pull far better shorts from the larger video.
Underlord knew the audio file. Claude knew us, our show, our brand, and eighteen months of editorial decisions Underlord had no access to. The same gap shows up everywhere a vendor tries to own the AI layer.
The Priceline agent knows about Priceline’s hotel inventory. It does not know that you travel with two kids who get carsick on long drives, that you prefer ground-floor rooms because of an old injury, that you only fly direct, or that you’ve stayed at this same chain three times and they always upgrade you. Your Claude or your ChatGPT knows that. Or it could, if Priceline let it in.
This is not a Descript problem. Built-in AI is always going to be context-poor.
The New Moat Isn’t AI. It’s API.
If the user’s AI is going to outperform the vendor’s AI on context, then the product’s actual job is to be the cleanest, most legible context source the user’s AI can find. That’s not glamorous work. CFOs don’t put “great MCP surface” on the press release. But that’s where the value is.
Concretely, this means:
clean and normalized data
well-named entities
a sensible API
an MCP server that exposes the right tools at the right permissions
None of those are “AI features” in the fun press release way that leadership often wants. But all of them are the actual moat in a world where the user brings their own agent.
The companies that get this will look boring for a while. They’ll be the ones investing in data quality and developer experience instead of shipping a sidebar chatbot. They’ll also be the ones still here in ten years.
Bring Your Own Agent Is Already Here
There’s a publication called Every that runs an AI-focused magazine and also builds products. One of them is a markdown editor called Proof.
Proof does not have a built-in agent. Instead it gives you a command to paste into Claude Code. That command installs an MCP connector plus a small package of plugins, and suddenly Claude is collaborating with you inside the editor. The editor isn’t pretending to be an AI, but instead the editor is exposed cleanly enough that the AI you already use can act inside it.
The smart products aren’t building chatbots. They’re building surfaces that the user’s existing AI can read.
If this sounds familiar, it should. The same pattern played out with mobile fifteen years ago. Companies built proprietary apps for their devices, then bring-your-own-device killed proprietary corporate phones. People had a better device in their pocket than IT could issue. The bring-your-own-agent shift is identical. People already have a better AI on their machine than any vendor can match for context.
Token Economics Make the Choice Even Worse
There’s also a financial argument here that we don’t seem to hear very often. When Descript ships Underlord, every interaction burns tokens that Descript pays for. We pay $35/month for Descript, and there’s no usage cap on Underlord (or if there is, we have never hot it or even know what it is). The unit economics are nobody’s friend.
When Jeremy connected his own Claude to Descript over MCP, he was burning his own token budget. Descript paid nothing for that session. The product got used, the work got done, and the vendor didn’t subsidize a single inference.
Built-in AI is an inferior experience at eight times the price.
For the user, BYO is cheaper too. One subscription to a primary AI is cheaper than five subscriptions to products that each charge a premium for their bolted-on chatbot. The math works in everyone’s favor except the vendor selling a built-in agent that nobody asked for.
Where Built-In Still Wins
This argument has limits, and pretending otherwise would be dishonest.
Meta is one of the exceptions. Facebook and Instagram know things about you that no external AI can match, because the data lives inside their walls. If Meta builds an agent that acts on that data, it’s going to outperform anything you bring.
Epic is another. Health records sit behind strict privacy boundaries for good reasons, and patching in a personal Claude isn’t a real option there. Same logic applies to Salesforce inside an enterprise. Your work bot and your personal bot probably shouldn’t be the same.
The other limit is reach. Most users don’t have a primary AI yet. Ninety percent of the people on the internet aren’t running Claude or ChatGPT every day. For them, a built-in chatbot might be the only AI they ever talk to. Serving those users is still part of the job, and the Priceline bot might be doing exactly what it should be doing for that audience, for now.
So the rule isn’t “never build an agent.” The rule is be honest about why you’re building it. If the answer is “because the CEO said we need AI,” it might be time to rethink some things.
The authentication pattern we’ve seen before
There’s a historical parallel - identity. Every product built its own proprietary login, complete with password reset emails and security questions about your first pet. Then Sign in with Google killed proprietary login over the course of a decade. Now you can’t ship a serious consumer product without supporting at least one major identity provider.
Identity used to be a feature. Then it became a protocol. AI is on the same path.
In five years, asking a user to learn your product’s chatbot is going to feel like asking them to make a new password. The user already has an AI they trust. The product that respects that fact wins. The product that tries to own the AI layer is fighting Google and Anthropic and OpenAI on their home turf, and that’s a losing battle for almost everyone who isn’t already a platform.
The deeper reason this matters is sovereignty. The user already has a primary AI relationship, and that relationship contains things the user does not necessarily want to share with every vendor they encounter. You might want your Claude to know how you actually feel about your boss. You probably don’t want Priceline to know that, or HubSpot, or Descript.
What Builders Should Do Now
If you’re building a product, treat the agent as a user. Put it on the persona list. Give it a row on the service blueprint. Design for what it needs the same way you design for any other user type. Not as a chatbot, as a consumer of your data and your surfaces.
Then invest in the unglamorous foundation. Clean and normalized data. Well-named entities. A sensible REST or GraphQL API. An MCP server that exposes the right tools at the right permissions. Documentation aimed at the agent, not just the human developer. The bot is the new user, and bots read documentation differently than humans do.
The companies that get this will be the ones that don’t show up in any “best AI features” listicle this year. They’ll be the ones whose products quietly become the default citation when someone asks Claude or ChatGPT to do something in their category. That’s the new top-of-funnel. Not search rank. Agent rank.
Taste Is Knowing What Not to Add
Stop building agents. Start building surfaces.
The companies that figure out “use with my agent” in a commercially viable way will be the ones still here a decade from now. The ones racing to ship their own AI feature because everyone else is racing will be remembered the same way we remember the corporate iPhone apps of 2012. A lot of money spent. Very little user value produced. A product strategy that confused activity with motion.
Taste is knowing what not to add. Right now, the most tasteful move a product can make is to not build its own AI. Open the surface. Let the user bring the agent.
About Us
Design Language is a newsletter for all product builders (PMs, Engineers, Founders, etc) who want to improve their design literacy, hone their sense of taste, and improve their craft when building products.
Jeremy Belcher is a 15 year product and design veteran. He has designed UX/UI for products used by tens of millions for brands like Google, Salesforce, Saturday Night Live, DirecTV, BMW, Emirates, Visa and in the past several years has focused on new enterprise workflow products. He runs the product studio Robot Heart, which designs, builds, and validates 0 → 1 B2B workflow tools for teams and founders.
David Issa is a digital strategy and product design leader with over 15 years of experience guiding companies through transformation. He has helped scale products and teams across healthcare, fintech, and enterprise software, translating complex systems into human-centered experiences. David runs a strategic design practice focused on aligning purpose, architecture, and execution—bridging design, AI, and organizational strategy to help teams build with clarity and intent.