An enterprise AI agent needs access to more than a large language model. At WSO2Con Africa 2026 in Nairobi, a hands-on session showed how enterprise data and existing systems can be connected to AI agents through tools, APIs, Model Context Protocol (MCP) and Retrieval-Augmented Generation (RAG), giving models access to information and business capabilities they would not have on their own.
The session, “Making Existing Systems and Data AI-Agent Accessible,” was led by Anupama Pathirage, Director & Head of Product Management – Integration BU at WSO2, and Lashan Sivaganeshan, Lead Sales Engineer at WSO2. The presentation used a hypothetical insurance environment to demonstrate the architecture, moving from an existing claims API to MCP tools, policy knowledge and an AI agent capable of combining that information.
Why Enterprise AI Needs More Than an LLM
The starting point was a familiar problem. A general-purpose AI model may understand insurance concepts, but that does not mean it knows the latest wording of a particular company’s policy, the status of an individual claim or the information held inside its operational systems. It also has no inherent ability to request missing documents, escalate a claim or record a settlement decision.
The Amani General Insurance example illustrated the gap. A raw model could be asked whether a particular loss is covered, yet without access to the insurer’s own policy information it may lack the evidence needed to answer accurately. The presentation identified three limitations: the model’s knowledge can be frozen at its training boundary, it has no direct ability to perform business actions, and it can produce a plausible answer when the required context is missing. The proposed architecture therefore gives the model access to both knowledge and tools.
That changes the engineering question. Instead of asking only which model an enterprise should use, architects also have to consider how that model will reach the organisation’s data, understand available capabilities and interact with systems that already run the business.
How MCP Connects AI Agents to Existing Systems
The presentation used Model Context Protocol as the interface between an AI application and enterprise capabilities. In the architecture shown, the AI application acts as the host, an MCP client handles communication from within the host, and an MCP server exposes resources and tools that the AI application can use.
Those tools can represent actual business operations. In the insurance example, an MCP service could expose claim assessment, customer information, document requests, escalation and other capabilities. The AI application can inspect the available tools and their descriptions, giving it information about what a capability does and how it can be invoked.
This creates an important distinction between an API designed primarily for developers and an interface intended for AI consumption. A conventional API can provide the underlying operation, but the developer normally determines which endpoint to call and how to construct the request. The MCP model presented at WSO2Con Africa allows an AI application to discover available tools and work with their descriptions dynamically.
The practical implication is that MCP can sit over existing enterprise capabilities rather than requiring the underlying systems to be discarded.
Turning Existing APIs Into AI-Ready Tools
The live demonstration made that point concrete. The presenters began with an existing claims API and its OpenAPI definition, then used that specification as the basis for creating an MCP service. The API remained a standard service that could be deployed through conventional means, while its resources were converted into tools that AI applications could consume.
The demonstrated claims environment included operations for retrieving claims and customer information, examining claim history, requesting additional documents, recording decisions, escalating claims and settling them. This gave the AI layer access to recognisable business capabilities while leaving the underlying service architecture intact.
The distinction becomes important when deciding how much of an existing API should be exposed to an agent. During the session, the presenters described a direct REST-to-MCP conversion alongside an approach in which additional logic and data mapping can be introduced between the underlying service and the AI-facing tool. That gives developers room to shape the capability an agent receives instead of simply exposing every backend operation as a separate tool.
The MCP Inspector demonstration showed the resulting interface in operation. After connecting to the MCP server, the presenter listed the available tools and inspected individual capabilities, illustrating how an AI application could discover what the server exposes before invoking a particular operation.
For enterprises with substantial API estates, this provides a practical route toward AI accessibility because the work can happen around existing services. The underlying systems still contain the business data and logic; the integration layer determines how those capabilities are presented to an AI application.
Where RAG Fits Into Enterprise AI
MCP addresses the action side of the problem, while Retrieval-Augmented Generation addresses the knowledge side. The session demonstrated RAG using policy documents that were ingested, divided into smaller sections, converted into embeddings and stored in a vector database for semantic retrieval. When an AI application receives a question, the query can be embedded and matched against the stored material so relevant sections can be supplied as context.
The insurance example made the distinction easier to follow. If an agent needs to determine whether accidental damage to an electronic device is covered, it needs the actual policy wording rather than a general understanding of insurance. In the demonstration environment, the RAG layer retrieved relevant policy material from Amani’s documents, allowing the model to work with specific coverage information.
The session showed Pinecone as the vector store in the demonstration, while the WSO2 environment also presented other vector database options. The technology choice is therefore separate from the underlying architectural idea: enterprise documents and other knowledge sources can be indexed so an AI application can retrieve relevant context when it needs it.
Why MCP and RAG Work Better Together
The more useful enterprise architecture emerges when the two approaches are combined. RAG can provide the knowledge required to answer a question, while MCP can provide access to the systems and actions required to do something with that knowledge.
The session illustrated the sequence with an insurance claim: an MCP tool can retrieve the claim, RAG can retrieve the relevant policy provisions, the AI agent can consider the two sources together, and another MCP tool can record the resulting decision. The architecture therefore connects information retrieval, reasoning and system action rather than treating them as separate AI features.
That combination also explains why enterprise AI agents need a broader architecture around the model. The model provides the reasoning capability, but its usefulness depends on the quality and availability of the context it receives and the capabilities it is permitted to invoke.
During the session’s discussion, the presenters described the agent as connecting both a knowledge base and MCP tools. In the insurance scenario, the agent could receive a structured representation of a claim through an MCP tool while using the knowledge base to retrieve the relevant policy information, giving it the two inputs needed to reason about what should happen next.
From Enterprise Data to AI-Driven Actions
This architecture has implications beyond the insurance demonstration. Enterprises already have databases, APIs, applications, documents and integration services containing the information and capabilities that AI agents need. Making those assets accessible to AI therefore becomes an integration problem involving interfaces, context, tool design and the boundaries placed around each capability.
WSO2’s own conference agenda describes the session in similar terms, focusing on connecting AI agents to enterprise systems, tools and data, then making existing APIs and integrations available as agent tools and exposing MCP servers that provide standardised access to enterprise capabilities.
The demonstration also shows why simply connecting an AI model to a database is an incomplete approach. An enterprise agent may need structured access to a claim, relevant policy context, the ability to request additional documents and a controlled mechanism for recording a decision. Those capabilities can sit across different systems, which means the architecture has to determine how they are exposed and combined.
For organisations working with established enterprise systems, that leaves a practical path toward agentic applications. Existing APIs and data sources can remain part of the architecture while integration layers expose selected capabilities to AI applications, and RAG provides the organisational knowledge needed to ground their reasoning.
The central challenge is therefore making the enterprise understandable and actionable to the agent without handing the model unrestricted access to everything the organisation owns. The WSO2Con Africa demonstration offered one architecture for that problem: APIs and enterprise systems underneath, MCP tools for controlled interaction, RAG for organisational knowledge, and an AI agent connecting the two.
Real ESG impact doesn’t happen in panels alone, it happens in the rooms where financiers, operators, and policymakers actually align. Our GreenShift Forum 2026 cuts the noise, bringing together the people rewiring Africa’s sustainability and energy frameworks for one focused day in Nairobi. Secure your seat.
Go to TECHTRENDSKE.co.ke for more tech and business news from the African continent and across the world.
Follow us on WhatsApp, Telegram, Twitter, and Facebook, or subscribe to our weekly newsletter to ensure you don’t miss out on any future updates. Send tips to info@techtrendsmedia.co.ke
