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.