ai/agents ai/enterprise ai/governance integration casestudies wso2 conference

Core idea

Treat agents as another consumer of the enterprise integration layer, but govern their non-deterministic decisions with explicit boundaries and oversight. Tharik Kanaka uses a loan-approval scenario to compare human, digitized, and agent-assisted work. Existing integrations remain useful; agents add a need for their own identity, bounded tool access, evaluation, traceability, and the ability to stop or revoke actions.

1. From human judgment to agent-assisted decisions

The talk follows Alice, a hardware-shop owner who applies for a business loan. Across each era, the bank must establish three things:

  1. What it knows: Alice’s history and relevant financial information.
  2. What it will do: Whether to approve, reduce, or escalate the requested amount.
  3. What it did: The decision and its record.

In the physical model, a loan officer gathers context from files and systems, applies approval limits, and escalates decisions beyond those limits. In the digital model, integrations connect applications to core banking, credit bureaus, and scoring systems. Rules can automate some decisions while routing others to a person.

The agent-assisted model can also process unstructured documents, such as invoices and statements, and prepare a recommendation. The speaker describes human approval as remaining available for decisions outside an agent’s allowed boundary. This is a proposed operating pattern, not evidence that the full loan process has been deployed.

2. Why agents change integration governance

Traditional integration flows define their paths in advance. Agents can choose tools and actions at runtime, so their paths are less deterministic. The speaker says this adds uncertainty to familiar integration concerns such as latency, throughput, and failures. An agent may also continue trying to complete a task unless its behavior is bounded and evaluated.

ConcernExisting integration practiceAdded concern with agents
Paths and actionsDevelopers define the flow.The agent selects tools and actions during execution.
ContextStructured fields can drive rules and scores.Unstructured records and user context may also shape decisions.
ControlRules and approval limits govern known paths.Boundaries must constrain which actions the agent can take.
AccountabilitySystems record integration activity and outcomes.Traces must explain the agent’s tool use and decisions.

3. A governance model built around context, action, and evidence

The speaker proposes three complementary capabilities:

  • Context: A context engine or data layer can assemble relevant information from existing integrations, rather than leaving the agent to search systems without guidance. This is positioned as a way to approximate the contextual knowledge a human officer may have.
  • Action control: Guardrails and human-in-the-loop approval limit what an agent may do. The speaker also points to evaluation during development and runtime, and the ability to stop agent actions.
  • Evidence: Observability and traces show what the agent did, so teams can inspect execution and learn from it.

The talk’s core governance properties are that agent activity should be traceable, bounded, and revocable. These controls are presented as requirements for safe operation, not as measured outcomes from a deployed bank system.

4. Extend the integration layer, do not replace it

The speaker argues that enterprise agents belong within the integration landscape, rather than in a separate parallel system. Core systems can remain in place. Existing integrations continue to serve applications and can also expose capabilities to agents through tools, including MCP tools.

WSO2 describes an “agentic fabric” that brings together integration, agent building, evaluation and management, and agent identity. The speaker mentions a context engine as work in progress. These are WSO2’s product and architecture claims, not independent evaluations of the platform.

Key takeaways

  1. Agents change who chooses the integration path. Governance must account for runtime tool selection, not only designed flows.
  2. Give agents useful context. Structured data and unstructured documents may both affect a decision.
  3. Bound and evaluate actions. Define what an agent can do, when it must escalate, and how teams assess behavior.
  4. Keep decisions inspectable and stoppable. Traces support review; revocation and human oversight preserve control.
  5. Build on existing integrations. The talk positions agents as another consumer of enterprise capabilities, not a reason to discard core systems.

Related vault notes: Designing APIs & MCP for AI Readiness covers agent-facing interfaces, while Modernizing Enterprise Architecture to Unlock Agents and Abstractions for the Agentic Enterprise connect integration governance to enterprise architecture.