The Golden Path to the Agentic Enterprise is WSO2’s proposed roadmap for organisations moving from general-purpose AI use towards systems that can act across business processes, applications and eventually on behalf of customers.
Presented by WSO2 CTO Asanka Abeysinghe at WSO2Con Africa 2026 in Nairobi, the framework sets out 10 steps that gradually increase what AI can access, what it can do and the degree of authority an organisation is prepared to delegate.
The sequence starts well before an AI agent is allowed to take meaningful action. Employees first need sanctioned access to AI, followed by controls around data and usage, access to enterprise knowledge, central governance and governed software development. Only after those foundations are established does the framework move towards exposing business capabilities, automating processes and delegating authority to agents. The final step considers a more mature commercial model in which agents themselves become products or services.
But Abeysinghe’s argument extends beyond completing the 10 steps. At every point in the journey, he says, organisations should ask what business outcome and value a particular step creates. The technology matters because it enables that outcome, while the value provides the reason for making the investment.
The agentic enterprise starts with control
Abeysinghe described the Golden Path as a reference methodology rather than a rigid prescription. WSO2 developed it from conversations with customers and prospects, and the company expects the model to evolve as agentic technologies and enterprise practices mature. The methodology has also been released as a public paper under a Creative Commons model, with the company inviting changes and contributions.
Its first four steps establish the basic operating environment. The first is sanctioned access, where employees use enterprise-approved AI through appropriate identity rather than turning to personal accounts that leave the organisation with little visibility over who accessed what. The second introduces controls around prompts, models, data movement, security and compliance, while keeping enterprise information out of the general-purpose AI environment.
The third step brings enterprise knowledge into the picture. AI can retrieve information from approved sources, with access controls applied before information is returned, giving employees a way to use organisational knowledge without turning the entire data estate into an unrestricted AI resource. The fourth introduces central governance, allowing policies to be defined centrally while enforcement takes place across different parts of the enterprise.
The progression is deliberate. An organisation first establishes an identifiable user, then controls the interaction, then gives AI access to relevant information and finally creates a governance layer capable of applying consistent rules across those interactions.
That pattern also reflects the wider identity discussion at WSO2Con Africa. Once an agent can retrieve information, call an API, update a record or trigger a workflow, an enterprise needs to distinguish the agent itself, the authority under which it operates and the person or system that authorised the action.
Coding agents bring autonomy into the engineering workflow
The fifth step applies the same discipline to software development. Instead of allowing coding agents to operate as unrestricted assistants with access to source code and development environments, the Golden Path places them inside an established application lifecycle.
The architecture presented at the conference moves from a developer to a scoped coding agent, then to a branch and pull request, automated scanning, human review and finally a protected branch. Direct pushes to the main branch are blocked, while source code, secrets and tool permissions remain within defined boundaries.
That approach mirrors how WSO2 is already applying AI inside its own engineering organisation. Its engineering teams have described systems in which agents are given repository-specific instructions, product knowledge and engineering rules so they can work across complex software environments while human engineers retain review and approval responsibilities.
Access to source code does not automatically give an agent an understanding of how an organisation expects software to be designed, secured or maintained. The agent needs context, scoped permissions and a workflow that makes its changes visible before they become part of production software.
This also places coding agents within the same governance model as other enterprise agents. Their permissions can be limited, their actions recorded and their outputs subjected to existing engineering controls rather than creating a separate route into production.
APIs and MCP become the bridge to enterprise capabilities
The sixth step changes the direction of the framework. The enterprise has established internal controls, and it can now begin exposing business capabilities to other agents, whether those agents belong to another team, another organisation or an external partner.
Model Context Protocol, or MCP, is one mechanism for doing this, but Abeysinghe’s presentation made clear that he does not regard MCP as the only interface architecture enterprises will use. His broader point is that organisations need governed ways to expose capabilities, with authentication, authorisation, ownership and scope attached to each tool.
That is consistent with the API discussion at WSO2Con Africa. APIs were presented as a key action layer between AI systems and enterprise applications, allowing agents to retrieve records, initiate workflows and interact with business services. But an agent-facing API estate needs more than connectivity because an agent may select tools dynamically and combine them in ways a conventional application would not.
The architecture shown for the sixth step places systems of record and knowledge bases behind a governed MCP layer and an agent-facing catalogue, with the enterprise boundary sitting between internal capabilities and external agents. Each tool needs an owner, defined scope and access policy, while external calls need authentication and authorisation.
Abeysinghe also pointed to where this architecture could go next. As agents operate across devices, partners and environments with intermittent connectivity, asynchronous APIs, streaming and edge architectures could become relevant alongside today’s synchronous interfaces. MCP therefore sits inside a broader question about how enterprises expose capabilities to software that can decide what to call and when to call it.
Turning capabilities into measurable value
The seventh step introduces the economic dimension of the framework. Once an organisation can expose capabilities safely, those capabilities can become reusable assets that are shared internally or offered to partners and customers.
Abeysinghe used the traditional API economy to explain why this matters. A technology team asking for more infrastructure can describe the number of APIs it operates or the volume of calls passing through them, but those measurements may mean little to a business decision-maker. The stronger argument is to connect the technology to the value carried through it and express that value in terms the business can understand.
He applies the same thinking to agents. An organisation should be able to explain how much value an agent creates, what outcome it delivers and how the underlying technology contributes to that result. That changes the conversation from the number of agents deployed to the business impact those agents produce.
The idea also explains WSO2’s description of a composable enterprise. A large organisation could allow teams to reuse capabilities across business units, while external partners could consume selected services through governed interfaces. Metering, entitlements, quotas and rate plans then become part of the architecture because access to an enterprise capability can carry commercial value.
The hospitality example presented at the conference illustrates the model. A hospitality business can expose capabilities to a partner network that brings reservations into the business, allowing partners to build their own agent experiences around those services. Once those interactions cross the enterprise boundary, API security becomes part of the commercial model rather than a purely internal technology concern.
Automation is where agents begin to carry real operational authority
The eighth step moves from exposing capabilities to automating business processes. An agent can receive a case, authenticate with its own identity, check permissions at the parameter level, make a scoped change and produce a replayable trace of what happened.
The architecture still allows human approval where the consequences are high, irreversible or regulated. That creates a tiered model of autonomy in which routine actions can proceed automatically while consequential actions are routed through an approval mechanism.
This is important for long-running enterprise processes, where an agent may need to wait for another system, an external event or a human decision before continuing. WSO2Con Africa also examined durable workflows designed to preserve process state across these interruptions, providing a practical foundation for agent-driven processes that do not fit into a single uninterrupted execution.
The result is a more realistic picture of enterprise automation. An agent does not need unrestricted freedom to be useful. It needs enough authority to complete a defined task, together with a mechanism for pausing, escalating and recording what it has done.
Delegating work means creating an identity for the agent
The ninth step is where the Golden Path reaches a more consequential form of autonomy. The user grants authority, a token exchange establishes the delegation, and the agent acts on the user’s behalf while the delegation chain remains intact.
That becomes important when an agent touches sensitive resources or personally identifiable information. The organisation needs to preserve the relationship between the person who authorised an action, the agent that executed it and the systems that ultimately processed it.
An agent should not simply inherit every permission available to a human user. Its authority can instead be scoped to a particular task, made short-lived and revocable, with a human sponsor and an audit trail that records the delegation.
The organisational implications extend beyond security infrastructure. Abeysinghe compared agents that become part of the workforce to employees who need to be managed. That raises questions around registering agents, assigning ownership, evaluating their behaviour, changing their permissions and eventually removing them from service.
The analogy also exposes a practical tension inside enterprises. The people building agents want them to be useful, while security and compliance teams remain accountable for the systems, data and customers those agents can affect. The agent therefore has to cross an organisational control boundary before it can become a production actor.
Monetising agents is the final destination in the current model
The tenth step moves from agents performing work for an organisation to agents becoming commercial products or services. That could include agents offered directly to customers, agent marketplaces or services priced around the outcomes an agent delivers.
Abeysinghe was clear that many organisations are unlikely to be at this point yet. The step represents where the model can lead as enterprises become comfortable packaging agent capabilities, isolating customer environments and attaching commercial measures to outcomes.
The architecture shown for this stage reflects those requirements. Customer tenants are separated into isolated environments, agents are packaged around defined tasks or outcomes, and metering is applied per tenant while policies, budgets, identity, delegation and evidence remain traceable.
That makes the final step more than a matter of putting an agent behind a subscription. The commercial model depends on the controls established much earlier in the path because an agent sold as a service still needs defined authority, isolation, accountability and evidence.
The Golden Path is really a progression of enterprise authority
Taken together, the 10 steps describe a progression in what an organisation is prepared to let AI do. The journey begins with identifying employees who use approved AI, then introduces controls around models and information, connects AI to enterprise knowledge and establishes central governance. From there, coding agents receive bounded access to development environments, business capabilities become available to agents, and those capabilities can eventually be monetised.
Only then does the framework give agents meaningful authority over business processes and allow them to act on behalf of people. Commercialising those agents comes last because the enterprise first needs confidence that the underlying identity, governance, integration and observability mechanisms can support the model.
That interpretation also connects the Golden Path with another issue raised at WSO2Con Africa: the gap between an AI pilot and a production system. Successful demonstrations do not automatically resolve problems involving legacy systems, usable data, business workflows, security controls and measurable outcomes.
The Golden Path addresses that problem through architecture and business discipline. It gives an enterprise a way to add the infrastructure around AI progressively, while requiring each step to justify itself through the outcome and value it creates.
Africa provides a practical context for the architecture
The relevance of this approach extends beyond private-sector technology teams. At WSO2Con Africa, Kenya’s government outlined plans to connect public institutions through a unified enterprise platform and secure APIs as it considers the use of AI agents in public service delivery. The government also identified Zero Trust, data access controls, authorisation, audit trails, error handling and human escalation as requirements for autonomous AI in government.
That context illustrates why agentic AI cannot be separated from the condition of the underlying digital infrastructure. An agent operating across fragmented systems inherits the complexity of those systems, while the consequences of incorrect access or action can become greater once software is able to act without a person directing every individual step.
For banks, telecom operators, healthcare organisations, governments and other institutions managing sensitive information, the same architecture questions apply. Which identity does the agent use? Which data can it access? Which APIs can it call? Who approved its authority? Which actions require human intervention? How can the organisation reconstruct what happened afterwards?
These are infrastructure questions as much as AI questions, which explains why identity, APIs, integration and governance have occupied so much space alongside agentic AI at WSO2Con Africa. The conference has treated the agentic enterprise as an architecture problem involving several interconnected systems rather than a single AI deployment.
Architecture before autonomy
The reference architecture behind the Golden Path reflects that broader view. Inbound channels can include web and mobile applications, IoT devices, third-party applications and other AI agents. A control and ingress layer handles AI and MCP traffic, while the platform core brings together APIs, MCP and agent catalogues, enterprise data, identity, observability and agent management.
The egress side then connects agents to large language models, enterprise APIs, third-party SaaS platforms and partner systems. Around those components sit governance and identity mechanisms that determine which actors can access which capabilities and under what conditions.
Abeysinghe described this as an extension of existing enterprise architecture rather than an instruction to rebuild the enterprise from scratch. The Golden Path allows organisations to add the required components as their use cases and maturity develop.
WSO2 packages that approach through what it calls the Agentic Enterprise Fabric, spanning agent management, API management, integration, identity and engineering. The underlying proposition is that enterprises can choose the relevant technology according to their architecture and requirements rather than treating one product or component as the entire answer.
The technology surrounding agents will also continue to evolve. The interfaces, standards and deployment models used today may not remain the dominant mechanisms as enterprises move deeper into agentic computing, which is another reason Abeysinghe presents the Golden Path as a methodology that can change rather than a fixed implementation checklist.
The outcome matters more than completing the 10 steps
Abeysinghe’s closing argument puts the framework in a wider business context. The Golden Path is a route towards an agentic enterprise, but each step has to be connected to an outcome and a measurable form of value.
That value can exist at different levels of an organisation. Developers, architects, project managers and business stakeholders may look at the same technology from different perspectives, but the organisation ultimately needs a way to understand how those forms of value connect and whether the investment is producing the intended result.
This is why the number of agents deployed, API calls processed or workflows automated cannot by themselves demonstrate the success of an agentic transformation. Those metrics can describe activity, but they do not necessarily explain whether the technology has improved a business process, reduced a cost, increased revenue, improved customer experience or delivered another defined outcome.
The Golden Path therefore ends with a commercial horizon but begins with something much more basic: control. An organisation has to know who is acting, what that actor can access and which actions it is authorised to perform before it can responsibly delegate more work to software.
The progression can be reduced to four ideas: direction, path, foundation and control. The direction comes from the business outcome an organisation wants to achieve; the path provides a sequence for getting there; the foundation consists of identity, data, APIs, integration and engineering controls; and governance provides the control required as authority is delegated.
That makes the Golden Path less a checklist for deploying agents than a framework for deciding how much authority an enterprise is ready to give them. AI access comes first, meaningful authority comes later, and each layer has to support both the technical operation and the business value of the next.
Asanka Abeysinghe’s closing message at WSO2Con Africa captured the idea through his marathon analogy: becoming an agentic enterprise requires a direction, a path, the right foundation and control along the way. His final principle was simple: pace beats speed.
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
