ai/agents ai/enterprise enterprisearchitecture casestudies wso2 conference
Core idea
Agents expose architectural gaps that humans have been bridging informally. Vidura Gamini Abhaya argues that enterprise systems must become legible to a new class of caller: autonomous, nondeterministic software that can act at scale. The answer is not to rebuild the estate or wait for a better model. It is to add shared capabilities for discovery, delegated identity, controlled execution, reversibility, and end-to-end observability.
Video
1. The case: a fast demo, a slow production path
The talk uses “Kinda Insurance,” a fictional composite based on organizations the speaker says he has encountered. The example company has 11 million customers, four core platforms, and about 2,000 APIs. Its architects and prior modernization efforts are not presented as failures.
Four engineers built a claim-status agent in nine days. It could answer nuanced questions that the existing IVR could not. After the board approved more agent use cases, however, the speaker says that 11 months later only the original agent was in production.
The bottleneck was not the model. Teams found four gaps in the enterprise around the agent:
| Gap | What the teams encountered | Production consequence |
|---|---|---|
| Discovery | Several customer APIs existed, but teams could not tell which was current or appropriate. Specifications had drifted from running code. | A lending team spent six of its 12 weeks investigating APIs and finding people with the needed knowledge. |
| Identity and authority | Security could not identify the agent as a distinct actor or assign a bounded authority. | The safe choice was read-only access, so agents could answer questions but not perform useful actions. |
| Safe action | Downstream systems lacked idempotency, compensating actions, and reconstructable decision records. | A 94%-accurate adjudication agent was not enough to justify action: errors could affect customers, and the risk committee could not inspect a trace. |
| Operational sprawl | Six teams built separate stacks; some model contracts had unclear authorization. | When asked what customer data left the estate and who received it, teams took nine weeks to answer, and their answer began “we believe.” |
The speaker’s diagnosis is that the architecture was designed for people. Humans supplied missing context, chose the right API, corrected duplicate actions, and explained past decisions. Agents do not reliably fill those gaps. They combine software-scale execution with person-like decisions.
2. Five capabilities for an agent-ready architecture
The proposed approach is to extend existing enterprise disciplines, not replace the whole architecture.
| Capability | What to put in place | Why it matters |
|---|---|---|
| Catalog and contracts | Catalog capabilities with named owners, lifecycle and version information, and contracts generated from running code. Project governed APIs as tools for agents. Put a contract layer in front of systems without APIs rather than rewriting their core. | Teams and agents can discover what the enterprise can do and which interface to use. |
| Agent identity and delegation | Give each agent a first-class identity, owner, lifecycle, and defined blast radius. Exchange the requesting customer’s token for a narrower, short-lived token with only the needed scopes. | An agent acts for the requester and cannot exceed that person’s authority. The speaker says delegation moved agents beyond read-only access. |
| Gateway and control points | Route model and capability calls through a gateway. Track cost, data leaving the estate, model outputs entering enterprise systems, and which model is in use. | Central control supports policy enforcement and model changes without rebuilding each application. |
| Reversible actions and approvals | Use idempotency keys, compensating actions, and explicit rollback paths. Require approval above defined risk or value thresholds, and retain approval evidence. | Retries and errors do not silently create duplicate or unrecoverable outcomes. The speaker argues that reversibility and evidence let organizations raise autonomy safely. |
| End-to-end observability | Trace intent, reasoning, tool calls, decisions, and resulting system changes. Test prompts and agent behavior in deployment pipelines, and define behavioral service levels. | Successful HTTP responses do not prove the agent did the right thing. Risk review needs evidence of behavior and effects. |
The speaker recommends placing these capabilities behind a shared paved road: a platform that lets teams build on common controls rather than create six separate agent stacks. A practical measure is how long a team that has never built an agent takes to put one into production safely without direct assistance.
3. Outcomes described and what they mean
In the composite story, the speaker says that after seven months the company could autonomously handle 80% of approvals. He attributes the ability to handle the remaining 20% with evidence to the approval process. He also says the company shipped nine agents in the last quarter, after the shared catalog, identity, gateway, and traces were in place.
These are outcomes reported by the speaker for the fictional composite, not independently verified results or a guarantee for other organizations. The nine-day build was a demo; the first production agent took 11 months. The later nine-day figure describes the speaker’s measure of time to a safe first agent for a new team, after the platform capabilities existed.
The first agent pays for the architecture
The speaker’s business case is that the first production agent carries much of the cost of building shared capabilities. The return compounds across later agents, so evaluating only the first use case can miss the value of the platform.
Key takeaways
- Treat agent readiness as enterprise legibility. Make capabilities, ownership, contracts, and policies discoverable to both people and software.
- Design authority around the user’s request. Use delegated, scoped, short-lived identity instead of shared, broad credentials.
- Design for failure and reversal. Autonomous actions need idempotency, compensating paths, and approval thresholds.
- Observe behavior and side effects, not only uptime. Preserve traces that connect the request to the system changes.
- Build one paved road and start with one valuable capability. Measure safe production time for a new team, not the speed of a demo.
- Fund reusable capabilities, not only individual use cases. The speaker argues that later agents benefit from the architecture established for the first.
Related vault notes: Building Governed Integrations and AI Agents for the Enterprise details agent-aware integration governance; Managing the Agent Lifecycle at Scale and Abstractions for the Agentic Enterprise extend the architecture discussion to lifecycle control and workflow abstractions.
LLMs and AI Agents