(Image credit: IIR.)
For many years, when CIOs evaluated a new insurance core platform, one of the important questions we asked was: “Is the platform API-first?”
There was a good reason for that. Insurers were trying to move away from tightly coupled legacy architectures in which systems were connected through custom integrations. APIs offered a better way to connect policy, billing and claims platforms with digital channels, data platforms, third-party providers and the growing InsurTech ecosystem.
APIs will continue to be an important foundation of modern insurance architecture. But with the emergence of agentic AI, CIOs need to start asking another question: “Is the platform agent-ready?”
That is where Model Context Protocol (MCP) becomes interesting. MCP is an open protocol designed to standardize how AI applications connect with tools, data and enterprise services. It is still relatively new, and we should be careful about declaring any emerging technology the next industry standard too early. We have seen enough technology cycles in insurance to know better.
But the architectural concept behind MCP is significant. We are beginning to contemplate an enterprise in which the consumer of a technology service may not always be another application or a human. It could be an AI agent—and that changes the conversation.
From API-First to Agent-Ready
APIs helped transform insurance technology. Instead of creating a custom integration every time one system needed something from another, insurers and their technology providers could expose clearly defined business services. That enabled more flexible architectures and helped carriers introduce specialized capabilities—property data, fraud detection, geospatial intelligence, payments and digital communications—without necessarily rebuilding their core systems.
APIs effectively became the connective tissue of the digital insurance enterprise. AI agents may create another shift.
Most enterprise integration architectures assume that developers know in advance which systems need to communicate. A developer defines which API will be called, what data will be passed and what will happen after the response. The workflow is largely predetermined.
With an AI agent, we increasingly define an objective and allow the agent to determine how to pursue it within established boundaries. Consider an underwriter evaluating a homeowners’ risk. The decision may require policy information, prior claims, property characteristics, replacement cost, geospatial information, catastrophe exposure, underwriting guidelines, pricing information and external data.
Today, insurers typically integrate and orchestrate those capabilities through applications and workflows designed in advance. An AI underwriting agent could determine which approved information it needs, identify the appropriate enterprise tools, retrieve and analyze the information, and recommend a next action. Where explicitly permitted, it might also execute an action.
This is not simply another application calling an API according to a fixed workflow. The agent is being asked to help determine which capabilities should be used to achieve an objective. That makes the openness, description and governability of enterprise services increasingly important.
Where MCP Fits
MCP is sometimes described as an “API for AI,” and there has been speculation that it could replace APIs. I do not believe that is the right way to look at it.
MCP does not replace the API layer. It can make capabilities exposed through APIs and other enterprise resources usable by a new class of consumer: the AI application or agent.
An MCP server can describe the approved tools and resources available to an AI application and provide a standardized mechanism for accessing or invoking them. The underlying APIs continue to expose business capabilities and the core platforms remain the systems of record. In one possible architecture, the pattern looks like this:
AI agents → MCP servers or agent gateways → enterprise services and APIs → core systems
The precise design will vary. MCP is not necessarily a single enterprise layer, and it does not by itself
supply the intelligence, workflow orchestration, security or governance required for an insurance use case. Those responsibilities are shared across the agent platform, identity and authorization services, MCP implementation, underlying APIs, application business rules, logging and human-approval controls.
The more meaningful evolution, therefore, is not API-first versus MCP-first. It is:
API-first + MCP-enabled = agent-ready
That is architectural shorthand rather than a complete definition, but the distinction is useful. An API-first architecture asks: “How can another application interact with my platform?” An agent-ready architecture adds: “How can an AI agent discover what my platform can do and safely use those capabilities?”
Early Insurance Examples
We are beginning to see versions of this architecture emerge in the insurance technology market.
Guidewire (San Mateo, Calif.) describes an agentic framework incorporating MCP servers and Cloud APIs. Its developer assistants also use MCP to connect AI coding tools with Guidewire knowledge and development capabilities. The noteworthy point is not that MCP replaces Guidewire’s APIs, but that an agent-oriented mechanism is being added to an existing platform and API architecture.
Socotra (San Francisco) has introduced an MCP server intended to connect agentic AI with its core insurance platform. ACORD Solutions Group (ASG; Pearl River, N.Y.) has also announced MCP-enabled architecture intended to support insurance data exchange and business transactions.
These developments do not establish MCP as the insurance industry standard. They are signals that the industry is beginning to think beyond embedding AI features in individual applications. The larger question is how AI agents will participate in the insurance technology ecosystem.
The Agent as an Orchestrator
Insurance is particularly suited to this conversation because it is data-driven, workflow-intensive and highly interconnected. A property claim may require policy and coverage information, prior claims, photographs, documents, weather data, property characteristics, repair estimates, vendor information and fraud indicators. Much of that information resides in different systems.
An AI claims agent could retrieve information from approved sources, assemble and analyze it, and give an adjuster a summary and recommended next action. The claims platform would not have to own every capability. The agent could orchestrate activity across the enterprise while the policy, billing and claims platforms retained their roles as systems of record.
That distinction will matter. The competitive question for an insurance software provider may move beyond “How much functionality resides inside your platform?” to “How readily can an insurer’s AI ecosystem securely use the capabilities inside your platform?”
Platform openness will no longer be measured only by the availability of APIs. It will also be measured by whether agents can discover and use capabilities without compromising the authority of the underlying systems.
Capability and Governance Must Evolve Together
It is relatively easy to demonstrate an AI agent retrieving information and completing a task. It is much harder to deploy that capability in a regulated insurance environment.
If an agent can interact with a core platform, insurers must determine what information it can access and which actions it can perform. Can it change a policy or coverage? Generate a quote? Recommend a claim settlement? Approve the settlement? Initiate a payment?
Most important: Who gave the agent the authority to do that?
Insurers will need to address identity, authorization, privacy, model bias, explainability and auditability, as well as determine where human judgment remains mandatory. Regulators and customers will not accept “the AI made the decision” as an explanation for a price, coverage or claims outcome. The insurer remains responsible for explaining and governing the result.
MCP provides standardized mechanisms that can participate in authorization and tool discovery, but adoption of the protocol does not automatically produce insurance-grade controls. Insurers will still need granular permissions, least-privilege access, human-approval thresholds, complete activity logs and the ability to revoke an agent’s access immediately.
Agentic capability and AI governance have to evolve together.
A New Section for the Core RFP
For CIOs that have spent years building APIs and modernizing integration architectures, the emergence of MCP does not make those investments obsolete. It may make them more valuable. Well-designed APIs exposing policy, billing, claims, customer and other enterprise capabilities provide an important part of the foundation for agentic architecture.
The evolution can be summarized as:
Core systems → APIs and enterprise services → MCP-enabled access → agents
Each element builds on the previous one. If I were evaluating a core insurance platform today, I would therefore add a section to the RFP called “Agent Readiness.” In addition to functionality, configurability, APIs, cloud architecture, security, data access, implementation, upgrades, scalability and total cost of ownership, I would ask:
Does the platform support MCP or other open agent protocols?
Which tools, data and transactions can agents access?
Can the insurer use its own models and agent platforms?
How are agents authenticated, authorized and monitored?
How granular are permissions and human-approval requirements?
Are all agent activities logged, and can the insurer reconstruct why an action occurred?
Can access be revoked immediately?
Can agents operate across policy, billing and claims while respecting the rules and authority of each system?
The industry should also avoid recreating the proprietary integration environments of the past. If every technology provider creates its own method for agents to interact with its platform, carriers may face another generation of custom integrations—this time for AI.
Whether MCP ultimately becomes the dominant standard remains to be seen. Standards evolve. But open agent interoperability should matter to insurance CIOs regardless of which protocol prevails. Carriers should retain the freedom to change models, agent platforms and specialized agents without redesigning the underlying core architecture.
The Next CIO Question
Ten years ago, asking whether a platform was API-first revealed a great deal about whether its provider understood the future of digital architecture. Today, I would add another question:
“How will my AI agents interact with your platform?”
Initially, agents will assist people. They will increasingly orchestrate workflows and, within carefully established authority, execute selected transactions. Our technology platforms need to be ready for a world in which the user of a system may be a human, an application—or an AI agent.
APIs connected the digital enterprise. MCP and other open agent protocols may help connect the agentic enterprise. For insurance CIOs making platform decisions that may last 10 or 20 years, agent readiness could soon become a strategic requirement rather than an interesting AI feature.