How WSO2 is encoding engineering knowledge so AI agents can work across its software stack

WSO2 is giving AI agents more than access to its code. At WSO2Con Africa 2026 in Nairobi, Senior Vice President and Head of Engineering Amila Mahaarachchi described how the company is giving Claude product-specific knowledge, repository rules and engineering workflows so AI can handle parts of software maintenance, documentation and security work. The approach has already been applied to hundreds of documentation issues, while WSO2 says one automated documentation workflow has reduced the time spent on a particular task from about 30 minutes to roughly five.

The distinction is important because WSO2 did not begin by building a collection of specialised software-engineering agents. Mahaarachchi said the company uses Claude itself for much of its engineering work, then supplies the model with the context that its engineers need to work effectively on WSO2 products. The problem WSO2 encountered was that different engineers could get different results from the same underlying model because the quality of an answer depended heavily on the prompt, context and product knowledge supplied by the individual engineer.

WSO2 responded by codifying that knowledge into reusable skills and repository instructions. Instead of relying on each engineer to know what information Claude needs, the company is building a common layer of product-specific context that can be used across engineering teams. That changes the role of the AI model inside the workflow because the organisation is effectively packaging parts of its own engineering practice into instructions and tools that an agent can use repeatedly.

Making large software repositories readable to AI agents

The challenge becomes more pronounced when an AI agent has to work across a large enterprise software codebase. WSO2 maintains mature products such as API Manager, Identity Server and Integrator across multiple versions, and Mahaarachchi said some of these environments can involve more than 50 repositories. An agent examining one repository can therefore miss important authentication, data access or API context that exists somewhere else.

WSO2 has been adding repository navigation information and rules to make that landscape easier for an agent to understand. Those rules can contain information about how repositories relate to one another, as well as engineering conventions such as REST API design and security requirements. For newer products such as WSO2 API Platform, which uses a monorepo structure, the navigation problem is simpler, and Mahaarachchi pointed attendees to the project’s .claude directory as an example of how repository-specific instructions can be provided to Claude.

That work addresses a problem that sits underneath many discussions about AI-assisted development. Giving an agent access to source code does not automatically give it an understanding of how an organisation expects that code to be changed. The repository has to carry enough context for the agent to identify relevant components, follow engineering conventions and understand constraints that might otherwise exist only in the heads of experienced developers.

Turning bug fixing into a repeatable workflow

WSO2 has applied the same idea to software maintenance. The company supports close to 1,000 customers across roughly 40 product versions, according to Mahaarachchi, which means fixing a reported defect can require engineers to understand a particular product, version and customer environment before making a change.

WSO2 has therefore codified its bug-fixing process into a sequence of skills. The workflow can cover reproducing the problem, planning the fix, assessing risk, implementing the change, verifying the result, creating tests and submitting the fix for review. Product teams can then provide versions of those skills that reflect the characteristics of their own products.

The value WSO2 is pursuing is consistency. An engineer who knows exactly how a particular product should be maintained may naturally provide Claude with the right context, while someone less familiar with that product may provide much less. By embedding the relevant procedures into the workflow, WSO2 can give the model a common operating context before it begins working on a task.

A 30-minute documentation task now takes about five minutes

One of the clearest examples came from documentation. WSO2 does not have a dedicated technical writing or QA team handling this work; developers are responsible for documentation and quality assurance alongside their engineering duties.

Mahaarachchi described a documentation issue that could take about 30 minutes because an engineer had to work through JavaScript and pull-request changes, check the relevant product version and verify that the documentation remained correct across versions. WSO2 connected GitHub Actions to Claude so that when a suitable documentation issue is created, the workflow can assess whether it can handle the task, make the change, verify it and submit a pull request.

The reported time for that particular workflow has fallen from roughly 30 minutes to about five minutes. Mahaarachchi also said WSO2 had used the approach to resolve more than 300 documentation issues over an eight-to-nine-month period, while the company was using the system to help create about 40 updates per month at the time of his presentation.

Those figures describe WSO2’s reported experience with specific workflows; they should not be read as a general productivity measurement for software engineering. The more significant point is that the company has taken a repetitive process with defined inputs and outputs and made it suitable for machine execution, while retaining an engineer at the point where the change enters the codebase.

Human review remains part of the engineering process

WSO2 has deliberately kept a boundary around what the AI can do. The agent can work through the task and prepare a pull request, but an engineer remains responsible for reviewing and approving the change. Repository rules provide additional constraints around areas such as security and API design, while tools such as CodeRabbit can provide another layer of AI-assisted pull-request review.

That boundary becomes particularly relevant when the same approach is applied to core products. Mahaarachchi described different levels of AI adoption across WSO2, with internal application development able to move faster in some cases because the consequences of an error are lower. The company is more cautious with core products, where an incorrect change can affect customers and production systems.

This is a practical example of bounded autonomy. The AI can perform work inside a defined workflow, but responsibility for accepting the resulting change remains with a human engineer. That approach also fits a wider theme running through WSO2Con Africa 2026, where identity, permissions, auditability and human intervention have been recurring requirements as AI agents move from answering questions to taking actions. TechTrends’ reporting from the conference has examined the same issue in the context of agent governance, APIs and enterprise data.

From software maintenance to security and customer support

WSO2 is applying the same model beyond code maintenance. Mahaarachchi said the company is using Claude with WSO2-specific skills to scan its open-source repositories for potential security issues, while the same skills can help process customer security reports and findings from scanning tools.

He was careful about the limits of that approach. The security work gives WSO2 what he described as some additional breathing space, but the company does not consider itself fully secure because security work remains continuous. The agent therefore becomes another layer in the security process rather than a replacement for security engineering.

Customer support presents another application. WSO2’s Novera assistant sits inside the customer portal and attempts to resolve a customer’s question before a support ticket is created. The company’s target is a 30% reduction in support tickets, while Mahaarachchi said the current reduction was about 5%, showing a significant gap between the target and the result achieved so far.

A separate customer-related engineering initiative places an agent alongside customer reliability engineers to help investigate problems and identify root causes. WSO2 has a target of reducing mean time to resolution to 10 days through that work, although Mahaarachchi said the team had not reached that target yet.

The same architecture is being used in other internal functions. An SRE initiative is designed to consolidate multiple incident alerts into a single incident, while an employee-facing Novera assistant can work with internal policies and applications through Google Chat. Marketing teams are also using customer profiles to identify potential ideal customer profiles for targeted campaigns.

WSO2 is building an agent-ready enterprise around the same principle

These engineering initiatives fit into a broader pattern visible across WSO2Con Africa 2026. Earlier TechTrends coverage examined how APIs can provide the action layer through which agents interact with enterprise systems, while another report looked at how MCP and RAG can give agents access to enterprise data and the ability to act on it. A separate session on identity focused on the question of how agents authenticate, receive permissions and remain accountable when they interact with enterprise resources.

Mahaarachchi’s presentation applies the same architectural idea to software engineering itself. APIs and enterprise data have to be made understandable and usable by agents; in the engineering environment, source repositories, product knowledge and maintenance procedures have to be made understandable and usable by agents as well.

That helps explain why repository instructions and product-specific skills are central to WSO2’s approach. The company is effectively converting organisational knowledge into machine-readable operating context. A senior engineer might know which repository to inspect, which historical decision affects a particular component, which security rule applies to an API and which tests must be run before a pull request is submitted. WSO2 is attempting to put that knowledge into the environment where the AI operates.

The wider company architecture is also moving toward dedicated governance infrastructure. WSO2 launched its Agent Manager in September as an open platform for managing agents across models, frameworks and deployments, with capabilities covering identity, MCP governance, runtime controls, lifecycle management and observability. That provides a broader control layer around the kind of agentic workflows Mahaarachchi described at the engineering level.

The next step is connecting agents to other agents

WSO2 is now looking beyond individual workflows. Mahaarachchi described a future in which a bug-fixing agent could complete its work and hand the result to another agent responsible for creating a product update. The company is already revamping its update-creation process with that kind of interaction in mind.

That would turn separate engineering automations into a connected workflow. A defect could move from identification to reproduction, remediation, testing and update preparation through several specialised capabilities, with human review remaining at defined points. WSO2 has also discussed durable workflows at the conference, where long-running processes can preserve state while waiting for systems or people to act.

The company is also considering spec-driven development, although Mahaarachchi presented that as an experiment rather than an established company-wide engineering practice. The same applies to other emerging agent capabilities: WSO2 is evaluating how they fit into its engineering environment rather than claiming that every proposed workflow is already operational.

Cost and observability are becoming part of that equation as well. WSO2 is using the Claude Team plan and its own AI Gateway to manage usage and gain better visibility into how AI is being consumed. Mahaarachchi said this approach had allowed the company to avoid the much higher cost associated with moving to Claude Enterprise, while an AI Gateway dashboard shown during the presentation displayed a snapshot of usage including 3,569 requests, 3.3 million tokens and an estimated cost of about $491. The presentation did not establish the measurement period or scope of that dashboard, so those figures should be treated as a snapshot of the environment shown rather than company-wide AI expenditure.

For WSO2, the engineering question is therefore becoming broader than which model produces the best code. The practical question is how much of an organisation’s accumulated engineering knowledge can be made available to an AI system in a structured, reusable and governed form.

That is also where WSO2’s wider agentic enterprise work connects with its engineering strategy. The company is working on the layers that allow agents to access data, call APIs, establish identity, follow durable workflows and operate under governance; inside the engineering organisation, it is applying the same principle to repositories, product knowledge and development procedures. The result is an environment where Claude can work with WSO2-specific context rather than relying entirely on what an individual engineer happens to put into a prompt.

Mahaarachchi’s advice to organisations pursuing similar projects was straightforward: choose problems with meaningful impact, define measurable results, start with small teams, establish weekly or biweekly milestones, ship quickly and use feedback to improve the workflow. That execution model may ultimately matter as much as the choice of AI model, because the harder organisational work lies in identifying useful processes and encoding the knowledge required to perform them safely.

WSO2’s engineering experiment offers a concrete example of what that can look like. AI is being placed inside existing repositories, maintenance procedures, documentation pipelines, security processes and support operations, with controls around what it can do and humans retaining responsibility for consequential changes. The company’s next challenge is connecting those individual capabilities into larger workflows without losing the context, governance and review mechanisms that make them useful in the first place.

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