AWS and WSO2 outline the architecture for building and governing an agentic enterprise
AI is moving deeper into software engineering, but AWS says the transition does not require developers to surrender control of what gets built.
At WSO2Con Africa 2026 in Nairobi, AWS Senior Solutions Architect Joseph Mutua outlined an AWS agentic software development model in which AI takes on more of the planning, task decomposition, implementation and infrastructure work, while humans remain responsible for validating plans, steering the process and approving what reaches production.
Mutua’s argument was less about replacing software engineers than changing where their time is spent. AI can handle more of the work surrounding software creation, he said, allowing developers and other technical teams to concentrate on requirements, decisions and verification. “Not necessarily get humans out of the way,” Mutua said, but make them more efficient so that human review does not become the bottleneck as AI takes on more tasks.
That idea sits behind the AI-Driven Development Lifecycle, or AI-DLC, framework that Mutua presented as an open-source approach to organising software development around AI agents. The model sits between AI-assisted development, where a developer uses an AI tool inside an existing workflow, and AI-managed development, where a user could provide a high-level objective and allow an automated system to handle much of the work. AI-driven development occupies the middle ground, with agents orchestrating substantial parts of the lifecycle while people remain accountable for the outcome.
AI takes on more of the development lifecycle
The starting point in Mutua’s model is the ambiguity that surrounds most software projects. A business leader might ask for a customer relationship management system, but that request does not explain the industry’s requirements, user journeys, architecture, databases, programming languages or operational constraints that developers need before implementation can begin.
AI can help turn that broad request into a structured plan, but the quality of the result depends on the context supplied to it. Mutua described an insurance example in which the organisation tells the system which line of insurance it operates in, what languages and frameworks its teams use, what databases are standard, and whether the organisation favours microservices, serverless systems or other architectural approaches.
The resulting workflow is deliberately iterative. AI creates a plan, humans verify it, the AI refines the plan based on that feedback, and only then does implementation begin. Once software has been produced, people return to assess the result against organisational requirements, including design standards, marketing guidelines and other expectations that may not be captured by the code itself.
That places the first human checkpoint before the first line of production code is generated. It also changes the role of the development team because business analysts, architects and developers can contribute to the specification rather than waiting until after an AI agent has produced an implementation.
The approach has parallels with WSO2’s own engineering work presented at the conference. WSO2 has described giving AI agents product-specific knowledge, repository rules and engineering workflows so they can handle parts of documentation, maintenance and security work while engineers retain review and approval responsibilities.
The common thread is that an enterprise agent needs more than access to a powerful model. It needs organisational context, explicit constraints and a mechanism through which people can inspect and correct its work.
Kiro brings specifications into AI-powered coding
AWS is using Kiro to put that model into a developer-facing environment. Mutua described Kiro as an agentic IDE designed to take software from product requirements towards production, with spec-driven development providing the structure around the AI’s work.
Rather than moving directly from a prompt to generated code, Kiro can turn a high-level request into structured requirements, a design and implementation tasks. AWS documentation similarly describes Kiro as an AI-powered development platform that converts natural-language ideas into requirements, architectural designs and sequenced implementation tasks.
That structure addresses one of the central problems with rapid AI coding. A model can generate working code from a short description, but working code is not automatically production-ready software. Production systems have requirements, architectural constraints, testing requirements, security expectations, operational considerations and maintenance obligations.
Mutua described spec-driven development as a way to carry those considerations through the lifecycle. Requirements and design become inputs to implementation, while testing, quality assurance, deployment and maintenance form part of the same development process. The specification effectively gives the agent a persistent reference for what the team is trying to build.
Kiro is also intended to involve people beyond the developer sitting at the keyboard. Mutua said business analysts can use the environment to verify requirements and user stories, while development teams can connect it to version-control systems, pipelines and tools such as Jira and Microsoft Teams.
The objective is to give an AI agent enough context to produce software that reflects how a particular organisation actually builds systems. That is a more demanding proposition than asking an AI assistant to generate a function or fix an isolated bug.
AWS Transform takes the model into legacy systems
The presentation then moved from new software to a problem that is particularly relevant to large enterprises: what happens when the software that needs to change was built long before today’s AI tools existed.
Mutua positioned AWS Transform as the complementary capability for migration and modernisation. The platform uses specialised agents to analyse complex environments, extract business logic and develop transformation plans for legacy applications, including mainframe workloads and large monolithic systems.
AWS describes Transform as an agentic service covering infrastructure, applications and code, with specialised capabilities for migration and modernisation. Its current documentation also describes continuous analysis of source repositories for technical debt, security vulnerabilities, modernisation opportunities and readiness for AI agents.
Mutua’s description of modernisation was deliberately incremental. For a bank running a complex monolithic system, the objective is not to dismantle the entire platform in one operation. Instead, individual business capabilities can be identified, separated and exposed through integration layers while new services are developed alongside the existing system.
That creates a bridge between the old and new environments. A bank, for example, could continue operating its existing core system while gradually extracting capabilities into newer services and connecting those services through APIs. Mutua specifically pointed to WSO2 API Manager as part of that integration layer.
The approach matters because modernisation is often constrained by the business logic embedded in legacy systems. Replacing the infrastructure does not automatically reproduce the rules, processes and dependencies that have accumulated inside an established application. AWS Transform’s role, as described by Mutua, is to help identify those components and provide a path towards a more distributed architecture.
AWS also describes Transform as a collaborative workbench with specialised agents for migration, application modernisation and continuous technical-debt reduction. Its documentation says the platform can connect modernisation work to Kiro and other development environments, allowing human review and refinement as transformation progresses.
Where WSO2 fits into the agentic enterprise
The AWS presentation became particularly relevant to WSO2Con Africa when Mutua moved beyond software development and into the systems that surround an application once it is deployed.
AWS can help organisations build and modernise software, but enterprise applications rarely operate in isolation. They need to communicate with other applications, expose capabilities through APIs, authenticate users and machines, enforce permissions and increasingly provide controlled access to AI agents.
That is where Mutua positioned WSO2.
The stack he described puts AWS on the build and transformation side, while WSO2 contributes integration, API management, identity and agent orchestration. WSO2 Choreo and API management provide mechanisms for connecting applications and capabilities, while Identity Server addresses authentication and access for people, systems and agents.
This connects directly with TechTrends’ earlier reporting from WSO2Con Africa on the changing role of APIs in enterprise AI. APIs give agents structured access to business capabilities, but an enterprise also needs to control which agent can invoke which operation and under what conditions.
The distinction becomes important when agents move from retrieving information to taking actions. An API that allows an agent to read a customer record presents a different risk profile from one that allows the agent to initiate a payment, alter an account or delete information. Identity, permissions, API policy and auditability therefore become part of the architecture around agentic systems.
Interoperability presents another problem. Enterprises are unlikely to build every agent on the same platform or use a single model for every task. Mutua pointed to agent-to-agent protocols and the need for agents built on different platforms to communicate, making standards such as MCP and A2A relevant to the broader architecture.
Governance then sits above those interactions. Mutua argued that visibility cannot stop at conventional logs and events. Enterprises need to understand what an agent did and, where possible, why it took a particular action. That is the territory WSO2’s Agent Manager is designed to address, alongside identity, controls, observability and lifecycle management.
The infrastructure around AI matters as much as the model
The presentation’s final discussion on hallucinations brought the argument back to the reliability problem. Mutua acknowledged that agents can produce incorrect outputs or act on assumptions that were not intended by the user, then pointed to evaluation as one mechanism for improving their behaviour.
His description was straightforward: give the agent a defined task and an evaluation mechanism that it cannot alter, allowing it to iterate against a clear measure of success. The evaluation process becomes another control around autonomous work rather than leaving the agent to determine for itself whether its output is acceptable.
That principle extends beyond software engineering. An enterprise agent needs a defined objective, access to appropriate information and tools, permissions that match its role, and mechanisms for evaluating the actions it takes. When those pieces are connected, human oversight becomes part of the system design rather than a manual intervention added after the fact.
The same infrastructure challenge is appearing outside private-sector software teams. Kenya’s government is working on a unified backend platform intended to connect public institutions through secure APIs as it prepares for AI agents in public service delivery. The proposal puts system interoperability, secure data exchange and backend coordination alongside the country’s existing digital-service infrastructure.
That provides a useful regional context for the discussion at WSO2Con Africa. Building an agent is only one part of deploying agentic technology in an enterprise or public institution. The harder engineering questions concern what the agent can access, how it interacts with existing systems, how its actions are authenticated and controlled, and how an organisation can verify what happened after an automated workflow runs.
Mutua’s presentation therefore offered a view of the agentic enterprise that goes beyond the coding assistant. Kiro addresses the development lifecycle, AWS Transform extends agentic capabilities into legacy modernisation, and WSO2 provides the integration, identity and governance infrastructure needed when those systems have to operate across an enterprise.
The common thread is control through structure. Requirements give agents direction, specifications constrain implementation, evaluation provides a way to assess results, APIs expose defined capabilities, identity determines who or what can use them, and governance provides visibility over what happens afterward. AI can take on more of the work, but the architecture determines whether that work can be trusted in a production environment.
Why digital government needs an operating layer
The practical problem is familiar. A citizen’s information can be spread across several government agencies, each responsible for a different part of the record. A birth registry may hold a person’s name, an immigration authority may hold entry and exit information, while another agency maintains vehicle ownership or tax records. When one piece of information changes, the state needs a way to propagate that change to the systems that legitimately depend on it.
Careem used a passport application to illustrate the problem. A name recorded at birth belongs to one government institution, passport information belongs to another, immigration records sit elsewhere and vehicle ownership can involve another agency. Without a data exchange mechanism, a citizen can end up repeating the same update across multiple systems.
That makes interoperability more than a technical convenience. It determines whether digital government can operate as a connected service or remains a collection of separate digital departments. Careem’s proposed architecture places government data exchange alongside identity and citizen services as one of the three main components of the operating system.
JOIN OUR TECHTRENDS NEWSLETTER
Identity becomes the first foundation
The identity layer extends beyond issuing a digital version of a national ID card. Careem broke government identity into several functions, including foundational identity, citizen access management, workforce access and government-to-government or government-to-business access.
He also described three broad approaches to digital identity. Some countries use centralised systems, while others rely on federated models in which different national systems recognise one another. Wallet-based decentralised identity adds another model, allowing citizens to hold verifiable credentials and present selected information to a service when required.
The wallet model changes how information can be shared. Careem gave a healthcare example in which a patient could hold medical credentials in a wallet and provide a clinic with selected information, such as previous surgeries or allergies, without handing over an entire identity record. The receiving institution can verify the credential without having to connect directly to the central government system for every transaction.
That architecture also introduces an important requirement for governments operating across areas with uneven connectivity. Careem argued that digital services need fallback mechanisms for people who cannot maintain a real-time internet connection, including the ability to return to paper-based processes where necessary.
Government data needs a common exchange layer
The second foundation is the Government National Data Exchange, or NDX, presented as a way to let agencies exchange information through a governed infrastructure rather than relying on isolated point-to-point connections.
The slide architecture places several functions inside the exchange layer: a metadata registry and catalogue, an access-control and data-orchestration layer, an API gateway, a consent and authorisation registry, unified authentication and IAM, and audit and logging. The presentation describes the model as GraphQL- and API-based, with support for data custodianship, consent, asynchronous data, versioning and federation.
That matters because government data is not simply a pool of information waiting to be connected. Different agencies remain responsible for different datasets, and access can depend on legal authority, consent and the purpose for which information is being requested.
Careem returned repeatedly to that question of custodianship. If one agency provides information to another, the architecture needs to establish who controls the data, what permissions apply and whether a citizen’s consent is required. Those controls become even more important once software agents can make requests without a person manually initiating every interaction.
The presentation pointed to open-source approaches including X-Road, GovStack and an OpenNDX implementation from the Lanka Software Foundation as examples of the broader ecosystem around government data exchange. WSO2’s own proposal uses APIs and GraphQL as the mechanism through which agencies can expose and consume services.
Sovereignty goes beyond where data is stored
Careem’s definition of digital sovereignty is broader than keeping government data within national borders. He described sovereignty as a question of control over the technology and the ability to decide how that technology operates.
His simplest explanation was a light switch. If a country owns the switch, it controls whether the system operates. Resilience asks whether another switch exists when the first one fails. Sustainability asks whether the country has the people and capability to repair or operate the system when something goes wrong.
That distinction is important for governments considering cloud and AI infrastructure. Keeping a workload inside a country can address one part of the sovereignty question, but it does not automatically give a government control over the software, skills, operational processes or ability to change providers.
Careem therefore placed open source alongside sovereignty, resilience and sustainability. He argued that governments should be able to inspect the technology, modify it, maintain it and operate it without becoming permanently dependent on an external party. He also stressed that open source does not mean free software; in his framing, its value lies in transparency and freedom to control the technology.
For African governments, that question sits alongside a broader digital infrastructure challenge. Kenya, for example, is building out data-centre capacity and digital public infrastructure while also dealing with questions around interoperability, data governance and sovereign control. The broader African digital-government conversation therefore extends well beyond the AI model itself.
AI agents add a new identity and governance problem
The architecture becomes more complicated once AI agents are given permission to act.
Careem’s Sovereign AI framework puts an agent’s identity alongside citizen and workflow identity. An agent would have its own identity, scoped delegation and audit trail, while access to government APIs would be governed by policy and consent. The presentation also calls for traceable AI-assisted decisions, controlled model traffic and safeguards around sensitive information.
This builds directly on a problem already emerging across enterprise AI: an agent needs to be identifiable when it calls an API, retrieves information or performs an action. In government, the stakes are higher because the systems involved can contain identity records, tax information, health data, immigration records and other sensitive information.
Careem gave the example of an agent acting on behalf of a taxpayer. If software can eventually perform a government transaction for a person, the system needs to establish which agent acted, what authority it had and who delegated that authority. Agent identity therefore becomes part of the government’s access-control architecture rather than an optional feature of an AI application.
The same principle applies to human oversight. The Sovereign AI framework presented at WSO2Con Africa calls for agents to operate within delegated authority while keeping officers involved in high-impact decisions. That creates a boundary around agentic action: software can perform authorised work, but the government retains control over which actions require human intervention.
What the model means for African governments
The presentation’s relevance to Africa comes from the way these components fit together. Digital identity, government data exchange, APIs, citizen services, cloud infrastructure and AI governance are often discussed as separate technology projects, but Careem’s model treats them as parts of one public-sector architecture.
Uganda provides one example discussed during the presentation. Careem described work with the country’s National Information Technology Authority around a data interoperability use case involving multiple government agencies, with questions around data access, consent, privacy and custodianship.
The approach also reflects a wider African digital infrastructure conversation in which interoperability and trusted data exchange are becoming central to public services. Kenya’s digital public infrastructure agenda, for example, includes digital identity, secure data exchange and interoperability alongside AI, data protection and data governance. That creates a policy and infrastructure environment in which the architecture Careem described is directly relevant to how governments think about connected services.
WSO2 is also presenting the model as part of a broader government technology offering. Its slides describe the company as supporting a sovereign government architecture built around identity, data exchange and citizen services, with sovereign cloud and sovereign AI beneath those layers. The presentation states that 42 national governments run on WSO2, a figure that should be understood as the company’s own positioning rather than an independently verified industry measure.
The commercial context is important because Careem was presenting a technology architecture as well as a public-sector philosophy. WSO2’s government proposition includes an index-based pricing model that the company says links public-sector fees to national income classifications, alongside its emphasis on open-source technology and government control. The presentation positions that approach as a way of making digital infrastructure more accessible while reducing dependence on proprietary systems.
The central idea, however, goes beyond one vendor’s products. As governments move from digitising individual services toward systems that can coordinate work across agencies, the underlying architecture becomes part of the AI question. An agent cannot safely operate across government simply because a model is capable of reasoning; it needs identity, permissions, access to governed data, reliable interfaces and a record of what it did.
That leaves the sovereign government operating system as a useful way to describe the layer underneath agentic government. Identity establishes who can act, data exchange determines what information can move and between whom, citizen services provide the interface to the public, while infrastructure and governance determine who controls the system and how its actions can be accounted for.
For African governments preparing to use AI agents in public services, that architecture may prove just as important as the models sitting on top of it.
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
