Everyone is still arguing about which model to pick. That’s the 2023 conversation. The 2026 product fight is about where the model is allowed to operate, what it’s allowed to touch, and how you expose that surface area without turning your product into a security incident generator.
The mistake I keep seeing: teams ship “AI” as a chat tab, bolt on retrieval, and call it done. Users get a pleasant demo and an unusable workflow. Meanwhile, the actual opportunity is hiding in plain sight: turning your product into a set of typed, permissioned capabilities that any assistant can call—inside the user’s existing interface—without you rebuilding the world for every model vendor.
This is why protocols like Model Context Protocol (MCP) landed so hard with builders. MCP (introduced by Anthropic as an open protocol) is not a new model, and it’s not “another agent framework.” It’s the missing product abstraction: a standard way for a model client to discover tools and fetch context from servers—so the assistant can act, not just chat.
Shipping a chatbot is UI theater. Shipping a tool surface is a product.
The real product shift: from “chat” to “capability surfaces”
“Chat with your data” had a short half-life because it ignores the real work: approving changes, creating tickets, updating records, kicking off runs, generating diffs, and routing decisions. People don’t want answers; they want outcomes with auditability.
Look at what won: products that turned LLMs into actions inside existing workflows. GitHub Copilot didn’t win because it chatted; it won because it sat in the editor and produced code where code is made. Microsoft pushed Copilot across Microsoft 365 because the value is inside Word, Excel, Teams—not in a separate AI app. Atlassian rolled “Atlassian Intelligence” across Jira and Confluence because the work is already structured there.
MCP-style thinking generalizes this. Your product should expose a tool catalog with:
- Explicit tools (create_invoice, update_pipeline_stage, open_pull_request) instead of “ask me anything.”
- Context endpoints (fetch customer record, fetch run logs) instead of dumping raw databases into embeddings.
- Permissions that map to real roles and scopes, not “the model can see everything.”
- Human checkpoints where the blast radius is high (money movement, production deploys).
- Observability so operators can answer “what did it do, and why?”
MCP isn’t “agent hype.” It’s an API product decision
Founders hear “protocol” and think standards politics. Engineers hear “protocol” and think more plumbing. Product leaders should hear: distribution and interoperability.
If you build a proprietary “AI tool API” that only your own assistant can call, you’ve created the worst kind of platform: one with a single client, locked to a single model strategy, and expensive to maintain. MCP’s pitch is simple: expose tools and context once, and let multiple compatible clients use it.
That matters because the client layer is fragmenting fast:
- Enterprise users are already standardizing on assistants embedded in suites (Microsoft Copilot, Google Gemini for Workspace).
- Developers live in IDE assistants (GitHub Copilot, JetBrains AI), terminals, and code review workflows.
- Power users run local or semi-local model stacks for privacy, cost, or latency—and still want tool access.
Interoperability is the product wedge. If your tool surface can be reached from the assistant the user already prefers, you stop fighting a UI adoption battle you’re unlikely to win.
Contrarian take: “agentic” UX is mostly a permissions problem
People love to argue about tool planning, reflection, and agent loops. In real products, the blocker is almost always permissions and safety. Users want the assistant to do things, but only within guardrails that match their org’s operating model.
MCP pushes you to model that explicitly: what tools exist, what inputs they accept, what scopes they run under, and what the user must approve.
Table 1: Comparison of common “AI integration” approaches teams are choosing in 2026
| Approach | What you ship | Strength | Risk / Cost |
|---|---|---|---|
| Chat tab + RAG | One assistant UI + vector search over docs | Fast demo; low initial integration | Weak workflow fit; hard to govern; “answer” ≠ “done” |
| Vendor assistant plug-in | Integration to a specific ecosystem (e.g., Microsoft 365/Teams, Slack apps) | Distribution via existing user habit | Platform dependence; limited control over UX and model behavior |
| Tool API (proprietary) | Your own tool-calling schema + endpoints | Tailored to your product; strong internal alignment | Single-client trap; reinvents standards; brittle across model clients |
| MCP server (tool + context surface) | Standard tool/context endpoints discoverable by MCP clients | Interoperability; clear permission boundaries; faster multi-client support | Requires disciplined tool design; new operational surface to secure |
| In-product copilots (embedded actions) | Assistant embedded in key screens (editor, CRM record, PR view) | High workflow fit; measurable outcomes | Higher product effort; must avoid feature sprawl |
Designing tools like product primitives (not endpoints)
If you treat MCP as “we’ll expose some endpoints and let the model figure it out,” you’ll ship chaos. Tool surfaces need product design. Each tool is a public promise: stable, documented, and safe to call repeatedly.
Rules that separate serious tool surfaces from toys
1) Tools must be boring. “Do what I mean” tools are the fastest path to accidental damage. Prefer narrow tools that compose: find_customer then create_quote then send_quote_for_approval.
2) Inputs must be typed and validated. If a tool takes “notes” and you later parse it to figure out amounts, you’ve built a prompt injection vector into your own product. Treat tool input like any external API input.
3) Every write needs an audit trail. If your system can’t answer “who/what changed this field,” you’re not ready for agentic behavior.
4) The UI must expose the plan. Users will not trust invisible tool calls. Show the proposed actions, the diffs, and the reason. GitHub’s pull request diff is the gold standard for “show your work.” Your domain needs an equivalent.
Security: prompt injection is your product problem now
Once you connect a model to tools, every untrusted string becomes a potential instruction. This is not theoretical; prompt injection has been widely demonstrated against tool-using systems (e.g., malicious text embedded in web pages or documents that tries to override the assistant’s instructions). If your assistant can read it, it can be attacked by it.
The bad response is “we’ll tell the model to ignore malicious content.” The good response is product and architecture:
- Separate data from instructions: treat retrieved content as untrusted context, never as system-level directives.
- Gate tool execution: high-risk tools require explicit user confirmation with a clear diff (money, access, deletes, prod changes).
- Minimize scopes: the assistant shouldn’t have the same permissions as the user by default. Issue short-lived, scoped tokens per action.
- Log everything: tool calls, parameters, results, and the originating user/session.
- Rate limit and anomaly detect: not as a nice-to-have—tool abuse looks like normal traffic until it doesn’t.
Key Takeaway
If your “AI feature” can write to production data, it’s part of your security boundary. Treat it like a public API with an untrusted client—because it is.
Table 2: Tool-surface checklist for MCP-style integrations (what to decide before you ship)
| Decision | Good default | What to document | Red flag |
|---|---|---|---|
| Tool granularity | Small, composable tools | Inputs/outputs, examples, error cases | One mega-tool: “update_anything(notes)” |
| Write controls | Preview + explicit confirmation for writes | Which tools require approval and why | Silent background writes |
| Permissions model | Scoped tokens; least privilege | Role mapping, scopes, token lifetime | Assistant inherits full user access |
| Context sources | Explicit whitelisted sources | What is considered untrusted input | “It can browse everything” |
| Audit + observability | Tool-call logs + user-visible history | Retention, export, incident workflow | No way to reconstruct actions |
Interoperability is the new distribution
For a decade, the distribution playbook was integrations: Slack app, Salesforce app exchange, Chrome extension, Zapier connector. Those still matter. But assistants are becoming the new integration hub. Users increasingly expect: “Ask the assistant, it calls the right systems.”
If your product exposes capabilities through a standard tool surface, you can ride that behavior instead of fighting it. The alternative is expensive: building and maintaining bespoke plug-ins for every assistant UI and every model vendor.
What this changes for product strategy
Roadmaps should shift from features to verbs. Users don’t want 30 AI buttons. They want a set of reliable verbs: summarize, draft, compare, reconcile, triage, route, approve, execute. You should be able to point to the tools that implement those verbs and the screens where the results land.
Your “API product” becomes your “AI product.” If your existing API is inconsistent, under-documented, and permission-sloppy, assistants will expose that immediately. MCP-style tool surfaces force you to clean it up, because the caller is nondeterministic and will try weird combinations. That pressure is healthy.
It also changes partnering. The more your product can be safely controlled through tools, the more it becomes a component in larger systems: an assistant in Microsoft Teams that can open a Jira ticket, query Confluence, and post to Slack is not magic—it’s tool interoperability plus identity and permissions.
# A practical starting point: model your tools like a public API
# (pseudo-OpenAPI-ish outline; keep it typed and explicit)
POST /tools/create_ticket
{
"projectKey": "ENG",
"summary": "...",
"description": "...",
"priority": "P2",
"labels": ["customer"]
}
POST /tools/update_ticket_status
{
"ticketId": "ENG-1234",
"status": "In Progress"
}
GET /context/ticket
?ticketId=ENG-1234What to build this quarter (and what to stop building)
If you’re a founder or product leader, the best move is not “add an agent.” It’s to carve out a small set of high-frequency workflows and expose them as tools with strong guardrails.
Start with one workflow where the outcome is unambiguous
- Pick a narrow job: “create a customer support escalation,” “open a PR from a bug report,” “generate an invoice draft,” “reconcile a subscription mismatch.”
- Map it to 5–10 verbs that your system already supports (or should support) with clean inputs.
- Build tool endpoints for those verbs with strict validation and explicit errors.
- Add preview and approval for any write; show diffs where possible.
- Instrument tool calls like payments: logs, tracing, alerting, and a rollback story.
Stop shipping these three things
- Standalone chat UIs that duplicate your app’s navigation and state.
- “AI settings” pages full of toggles nobody understands, instead of clear permission scopes tied to roles.
- Giant tools that accept free-form text and mutate core records without previews.
A prediction worth arguing with
By the time this cycle matures, “AI product” won’t mean “we picked the best model.” It’ll mean: your product is controllable through a safe, auditable tool surface that assistants can call. Teams that get this right will look boring—until you realize their users are completing work in half the clicks because the assistant is operating inside real permissions, real workflows, and real interfaces.
Concrete next action: open your product and list the five most common writes users do every day. If you can’t express each one as a typed tool with a preview and an audit log, your “agent” roadmap is fantasy. Build that surface first.
