Pawel Rzeszucinski is Senior Director of Data and AI at WebPros.
Most businesses ask some version of the same question when AI enters the agenda: where should we use it? Which workflows, which products, which teams? It is a reasonable question. But as the AI landscape changes, more urgent questions are coming into view from a business continuity perspective: what happens if customers begin interacting through agentic interfaces rather than human ones, which parts of our product remain reachable in that world and what risks do we face if they do not?
The Feature Trap
The first wave of AI investment inside most mature SaaS businesses follows a predictable pattern: a copilot here, an AI-generated summary there, a chatbot added to the support flow. These are not wrong moves. But they share a common frame: AI as a layer added on top of an existing product for human users to interact with. They don’t address a parallel question, which becomes more pressing every quarter: what happens when your customers stop navigating your product directly and start delegating tasks to an AI agent instead?
As agents become embedded in how people work through coding assistants, productivity tools and autonomous workflows, the products that agents can reliably and programmatically reach become the defaults. Products that require human navigation get routed around. Not because they are inferior, but because a system designed for human interaction cannot be plugged into an automated pipeline without significant friction. In that world, distribution through agent ecosystems will matter more than the product’s own feature set. The question of discoverability, i.e., whether an agent can find and invoke your software at all, becomes a competitive moat or a competitive gap.
The Protocol That Changed The Stakes
The Model Context Protocol (MCP), originally introduced by Anthropic in late 2024 and now stewarded by the Linux Foundation under the Agentic AI Foundation, changed the economics of agent-centric communication from custom to standardized. MCP gives any compliant AI agent a standardized way to discover, connect to and invoke external tools and data sources.
The adoption rate has been faster than most anticipated. Research published in April 2026 found that 78% of enterprise AI teams have at least one MCP-backed agent in production, and 67% of CTOs surveyed named MCP their default agent-integration standard within 12 months. This is no longer a protocol worth watching. It is becoming the infrastructure of the upcoming agentic layer.
What Legacy Platforms Get Wrong About This
For companies with mature, established software platforms that have been in production for a decade or more, MCP creates a specific and underappreciated challenge. These products typically have broad, stable API surfaces. But those APIs were designed for developer discovery and assume a human in the loop. AI agents do not depend on traditional prose documentation in the same way developers do; they work best with structured, machine-readable descriptions such as tool metadata, schemas and API specifications. They infer capability from how operations are described, and many fail ungracefully when interfaces are ambiguous or were not designed with autonomous agents in mind.
The MCP specification’s own 2026 roadmap addresses this gap directly. Enterprise deployments are now surfacing a predictable set of problems: audit trails that don’t exist, authentication schemes tied to developer flows rather than machine identity, and configuration that breaks when moved between environments. These are not edge cases—they are the structural consequences of exposing APIs that were never designed for autonomous invocation. Companies that treat introducing MCP layers into their ways of doing business will very soon find themselves behind organizations that treated it as a strategy.
Making Your Product An Agent Target
Shifting from “where do we use AI?” to “can AI use us?” requires a different set of questions at the planning stage. Here are four ways to make that transition concrete:
Audit your API surface for agent readiness, not developer readiness. Developer-readiness assumes someone who reads docs, experiments and iterates. Agent-readiness means structured metadata (tool names, descriptions, input schemas), predictably scoped and safe to invoke without human supervision.
Build your first MCP server before your next AI feature. The instinct is to add AI capabilities to your product. The higher-return investment is making your product a capability that AI can call. A well-scoped MCP server covering your two or three highest-value operations will compound in value as the agent ecosystem grows.
Test with an agent, not a developer. When validating your MCP implementation, don’t evaluate it by having a developer read the tool definitions and confirm they make sense. Give an agent an unscripted task that requires using your tools, observe where it fails and improve based on the outputs.
Raise this in product strategy, not engineering planning. The question of whether your software is an agent target belongs in the same conversation as your roadmap priorities, not the sprint backlog. Frame it explicitly: in a world where customers increasingly delegate tasks to AI assistants, does your product sit inside the workflows those assistants can execute or outside them?
Conclusion
The companies that will define the next phase of infrastructure SaaS are the ones whose products agents can find, invoke and trust. For mature platforms, this is simultaneously a risk and a structural advantage: the integration surface already exists, the domain logic runs deep and the customer trust has been earned over the years. Until now, the question has been where AI fits into our products. The more important question, right now, is whether our products fit into AI.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
