Bring Your Own Bot: Why Users Should Control Their AI
User-owned AI agents that work across all services, not fragmented assistants locked in vendor silos
Every major app is racing to integrate AI. ChatGPT in your email client. Claude in your calendar. Gemini in your photo editor. Each service building its own assistant, collecting your data, training on your behavior, locking you into their ecosystem.
What if we got this backwards?
Instead of every service building AI into their app, what if users brought their own AI to every service? Call it BYOB: Bring Your Own Bot. Not as a novelty, but as the fundamental architecture for how AI integrates with software.
The Problem with Embedded AI
Today’s AI integration model mirrors the early internet’s walled gardens. AOL and CompuServe weren’t just services — they were entire ecosystems that controlled your experience, your data, your connections. Each company built its own interpretation of “the internet,” fragmenting the digital landscape.
We’re doing the same thing with AI.
When Slack integrates GPT-4, Gmail integrates Gemini, and Microsoft embeds Copilot across Office 365, they’re not just adding features. They’re creating fragmented AI experiences where:
- Your email AI doesn’t learn from your project management AI
- Your coding AI can’t help with your writing AI
- Each service processes your data differently, with different privacy policies
- You can’t choose the AI model that works best for your needs
- Training and customization happens in silos
The result? Users manage multiple AI personalities, each with different capabilities, different training, different blind spots. We optimize for vendor lock-in, not user benefit.
BYOB: The User-Controlled Alternative
Bring Your Own Bot flips this model. Instead of services embedding AI, they expose interfaces that your AI can interact with.
Here’s how it works:
You choose an AI agent — Claude, GPT, Llama, or a specialized model you’ve trained yourself. That agent becomes your interface to digital services. When you need to draft an email, your AI uses Gmail’s API. When you’re managing projects, your AI uses Notion’s API. When you’re coding, your AI uses your IDE’s extension framework.
The AI doesn’t belong to the service. It belongs to you.
This isn’t speculative. The infrastructure already exists. Services have APIs. AI models can call them. Tools like Claude Code demonstrate this pattern — offering both terminal-based interaction through APIs and native IDE integrations, giving users flexibility in how they deploy their AI rather than locking them into a vendor-specific assistant. Anthropic’s Model Context Protocol (MCP) takes this further, allowing any AI to interface with services like Notion through standardized connections.
What’s missing is the intentional design choice: building services for user-controlled AI first, embedded AI second.
The 5 Benefits of User-Controlled AI
1. Privacy by Architecture
When your AI runs locally or in your chosen environment, sensitive data doesn’t leave your control. Email drafts, medical records, financial planning — all processed by your AI, using service APIs only for the final actions you authorize.
Compare this to embedded AI, where every interaction sends data to the service’s AI infrastructure. You’re trusting not just their current privacy policy, but every future version, every acquisition, every data breach.
2. Unified Training and Memory
Your AI learns from everything you do across all services. The coding decisions that worked. The writing style you prefer. The project management patterns you follow. This knowledge transfers across contexts.
With embedded AI, each service trains separately. You teach Gmail’s AI your communication style, then teach Slack’s AI the same thing, then teach Discord’s AI again. The learning never compounds.
Example: When scheduling an important meeting in Google Calendar, your AI knows from your health tracker data that you struggle with focus in the mornings, so it suggests afternoon slots. That same insight — learned from one service — improves decisions across all your scheduling tools. With embedded AI, each calendar service would need to relearn your preferences independently.
3. Model Choice and Flexibility
Different tasks need different models. You might want Claude for writing, GPT for analysis, Llama for coding, or a specialized model for legal review. BYOB lets you choose the right tool for each job.
Get Alexander Zanfir’s stories in your inbox
Join Medium for free to get updates from this writer.
Embedded AI locks you into whatever model the service chose. If they picked wrong, or if better options emerge, you’re stuck.
4. Portable Customization and Tools
You can train your AI for your specific needs. Medical professionals can add medical knowledge. Lawyers can add legal reasoning. Engineers can add domain-specific best practices.
Beyond training, all the tools you build come with you — custom agents for specific workflows, automation scripts, specialized skills. Build a contract analysis agent once, use it across every document platform. Create a code review workflow, apply it to any repository host.
This entire ecosystem of customization stays with you across all services, not trapped in one vendor’s silo.
5. Open Systems and Interoperability
BYOB forces services to expose clean, well-documented APIs. This benefits everyone — not just AI users, but anyone building automation, integrations, or alternative interfaces.
It’s the same principle that made the web dominant over AOL. Open protocols beat walled gardens when users can choose their own tools.
The Counterargument: Isn’t Embedded AI Easier?
Yes. For now.
Embedded AI is simpler to implement and simpler to use. Click a button, AI appears. No setup, no configuration, no thinking about APIs or authentication.
But “easier” isn’t the same as “better.” Email clients were easier when they came from your ISP. Search engines were easier when they came from your portal site. Social networks were easier when they were part of AOL.
The pattern repeats: convenience-driven integration creates lock-in, which creates friction, which creates demand for open alternatives. We’re in the convenience phase of AI integration. The lock-in phase is already visible — try moving your ChatGPT conversation history to Claude. The friction phase is coming.
BYOB is the open alternative. It’s harder today because we haven’t built the tooling, the standards, the user interfaces that make it seamless. But those are solvable problems, not fundamental limitations.
Freedom, Not Control
Here’s the critical distinction: BYOB isn’t about forcing users to manage their AI. It’s about ownership and freedom of choice.
Your AI agent will handle most of the work autonomously — interfacing with services, executing tasks, learning from your patterns. You don’t need to micromanage it any more than you micromanage your embedded AI today.
The difference is ownership. With BYOB, you own the agent. You can inspect its decisions when something goes wrong. You can switch to a different model when a better option emerges. You can take your trained AI to new services without starting over.
This isn’t control as burden. It’s freedom as capability — the option to intervene when you want to, not because you have to.
This Connects to Larger Principles
BYOB isn’t just about AI integration. It’s an instance of a broader pattern in software architecture: who controls the intelligence in the system?
This relates to three concepts I’ve explored in other articles:
Agentic vs. Programmatic Systems: When we embed AI into services, we’re still thinking programmatically — the service controls the AI’s behavior. BYOB is agentic — the AI operates on behalf of the user, using services as tools. The locus of control shifts from the service to the agent.
Open Systems vs. Walled Gardens: The internet succeeded because it was open. Email succeeded because it was federated. The web succeeded because it was decentralized. AI integration will follow the same pattern if we let it. BYOB enables this openness by treating services as interoperable endpoints rather than complete solutions.
Interpretability and Intelligence: In embedded systems, the AI’s reasoning is mediated by the service. You see outputs, not decision-making. BYOB makes AI interpretable by default — you choose the AI, you audit its reasoning, you understand its limitations. This isn’t just a transparency benefit; it’s a safety requirement as AI becomes more capable.
These aren’t separate ideas. They’re facets of the same architectural choice: do we build AI systems that serve users or serve vendors?
The Path Forward
BYOB won’t replace embedded AI entirely. Some users will always prefer the simplicity of integrated solutions. Some contexts require service-controlled AI for compliance or security reasons.
But BYOB should be the default architecture, not the alternative.
Services should expose AI-friendly APIs as a first-class design priority. AI developers should build agents that interface with multiple services rather than single-purpose bots. Users should expect their AI to work across their entire digital life, not be fragmented by service boundaries.
The infrastructure is ready. The models are capable. What we need is the intentional design choice: build for user-controlled AI, and let the ecosystem flourish.
Because the real power of AI isn’t in helping you draft better emails or summarize documents faster. It’s in having an intelligent agent that knows you, learns from you, and operates on your behalf across everything you do.
That agent should belong to you, not to every service you use.
This article represents the original ideas and writing of Alexander Zanfir, edited and refined through an agentic editorial process.
