You know users, right? People. Any size, shape, race or religion… users are those human people who use a software engineer’s application once it pushes to live production. Okay, yes, this has changed a little throughout the evolution of the Internet of Things (IoT) and we do talk about machine identities now as well, but a bigger and wider change has happened. Users are now agents too. But are our enterprise software architecture stacks ready for this next era?
A growing share of “users” are AI agents. They don’t log into an application or software suite dashboard, they don’t read application tooltips, and they don’t care how beautiful the user interface is. They call APIs, orchestrate workflows, and act on behalf of people – often while those people are doing something else entirely.
Rania Khalaf, chief AI officer at WSO2 has witnessed this change, primarily because WSO2 is known for its open source enterprise integration, API management, and identity/access management software designed for cloud-native software development.
“This shift from humans at the screen to agents in the fabric is not theoretical,” Khalaf specifies. “It’s already happening in customer support agents, IT automation, and domain‑specific copilots. Yet many organisations are still applying deterministic, UI‑first thinking to a non‑deterministic, agent‑driven reality. If you’re a CIO, head of engineering, or digital leader, you’re in the middle of a fundamental change in who actually ‘uses’ your software – and whether your architecture is ready for that world.”
There are three “shifts” we need to focus on here:
- Dashboards are shrinking and API surfaces are becoming the new UX.
- Every software product (or data entity) now needs an ‘agent‑visible surface’ to operate.
- Non‑deterministic behaviour is breaking traditional UX and SDLC assumptions.
APIs are now the UX
Consider a simple thought experiment. Take a favourite product demo. Replace the human clicking buttons with an AI agent that receives a goal in natural language, decides which APIs and tools to call, chains those calls into a workflow, and then executes actions that change data or move money.
In that scenario, beautiful user interfaces never enter the picture. The “user experience” has moved down a layer, into the capabilities and APIs that the agent can see, understand, and safely combine.
“That shift has very practical consequences,” says Khalaf. “The centre of gravity moves away from polishing every pixel and toward clean, well‑structured capabilities. Dashboards still matter – for oversight, exception handling, and human‑in‑the‑loop review – but the critical UX work is now about the clarity, consistency, and safety of APIs and tools. Ambiguous behaviour, which a human might tolerate or work around, becomes a risk rather than a minor annoyance. When a human misreads a label, they get confused; when an agent misinterprets a loosely defined API, it can loop, retry, or trigger the wrong workflow at scale.”
Next, then, product thinking has to follow.
Instead of treating UI journeys as the primary design artefact, teams need to think in terms of modular skills: clearly defined capabilities such as “create_invoice,” “update_policy,” or “provision_resource” that agents can reuse and compose on demand. Dashboards haven’t disappeared, but they are no longer centre stage – the capability surface is.
Every product needs an agent‑visible surface
In a human‑only world, being “user‑friendly” was enough. In an agentic world, a product must also be machine‑readable.
“By an ‘agent‑visible surface’, I mean a structured view of what a software system can do that is consumable by agents, not just people. This usually includes explicit tools or skills with clear inputs, outputs, and side effects; shared protocols and schemas that allow agents to discover and invoke capabilities reliably; and agent definitions expressed as code or specifications so that their tools and guardrails are independent of any single runtime or vendor,” explained Khalaf.
At WSO2, the team created an open specification to define agents and their tools in a framework‑agnostic way, with a reference implementation that can be compiled into multiple agent frameworks. The motivation was: no developer wants an “agent UX” trapped inside one vendor’s stack.
Before long, the question: “Do you have an agent‑visible surface?” will be as basic as “Do you have an API?” If the answer is no, a product will effectively be invisible to a growing class of users: enterprise copilots, assistants, and automation agents orchestrating work across systems on behalf of your human customers and employees.
Non‑determinism breaks old UX & SDLC assumptions
Traditional software engineering assumes determinism: given the same input, users should expect the same behaviour. A developer writes unit tests around that assumption, then debug around that assumption and ultimately plan releases around that assumption.
Foundation models and agents break it.
“At their core, these models are probabilistic,” explained Khalaf. “They produce distributions of likely outputs, not fixed answers. When we wrap them in agents, they don’t just generate text; they decide what to do next – what tool to call, with what parameters, and when to stop. That is exactly what makes agents powerful, and exactly what makes them risky.”
For Khalaf, three areas in particular are being reshaped and she details them as follows.
#1 Testing
First, testing evolves from pure unit tests to “evals.” Developers still need unit and integration tests, but they’re no longer sufficient. Developers have to introduce systematic evaluations of model and agent behaviour across curated scenarios, where they look for statistical thresholds instead of exact string matches.
“Because models, prompts, and tools all change over time, these evals must be continuous. We are not testing a static code path; we are assessing the behaviour of an evolving system,” said Khalaf.
#2 Observability
Second, observability has to move from system health to agent behaviour. Traditional observability tells developers whether APIs are up and how they are performing. In an agentic world, developers also need to understand which tools an agent called and in what sequence, where it hallucinated or entered a loop, and how its plan evolved as it interacted with systems.
“We’ve seen real‑world examples where revoking an agent’s access tokens successfully stopped it from touching sensitive systems – but the agent continued thrashing in an infinite loop, trying to ‘reason’ its way out of the failure and burning through compute. Without agent‑level observability, all developers see are failed requests, not the underlying pattern of behaviour,” clarified Khalaf.
#3 Guardrails
Third, guardrails must move from the UI into control planes. Most of today’s safeguards – confirmation dialogues, disabled buttons, warning banners – live in the interface. Agents skip all of that and go straight to APIs.
“The guardrails that matter now live in a control layer: identity and access control for agents (who they are, on whose behalf they act, and what systems they can touch); policies that constrain which tools they can use under which conditions; and runtime controls that allow developers to pause, throttle, or terminate misbehaving agents. The agents themselves can run anywhere – on a laptop, in the cloud, or in a vendor’s environment – but their identity, policies, and lifecycle need to be managed centrally,” detailed Khalaf.
If we accept that agents are becoming first‑class users of systems, the next 12–18 months should be about laying the groundwork.
Khalaf says this starts by inventorying system capabilities from an agent’s point of view. Ask what actions a software system can perform today, which of those are exposed via APIs, and how clear their contracts really are. She says that this exercise often reveals gaps between what a product can do and what an agent can safely discover and combine.
Don’t boil the ocean
From there, define an initial agent‑visible surface. We don’t need to boil the ocean. Choose a small set of high‑value tools, describe them declaratively so they’re portable across frameworks, and treat that surface as a first‑class part of the product.
“At the same time, developers need to expand their testing strategy to include evals around first agent use cases,” urged Khalaf. “Build a modest but representative suite, run it regularly, and use it to inform changes to prompts, models, and tools. Introduce agent‑level observability, so the team is logging tool calls, reasoning traces where feasible, and outcomes – not just HTTP status codes.”
Finally, says Khalaf, developers should stand up an initial agent control plane, even if it’s simple at first. They should centralise around how they define agent identity, attach policies, manage lifecycle and make sure they can revoke access quickly and, just as important, they should stop misbehaving runtimes rather than letting them burn tokens in the background.
“Above all, resist the urge to ‘do AI’ for its own sake. Use agents where they create real value, where the technology is mature enough for the use case, and where the cost of being wrong is manageable. AI on its own is just an algorithm. The real power comes when agents can safely act within the digital fabric,” concluded Khalaf.
The question is no longer whether agents will use enterprise systems… they already are, so the question is whether we are designing – and architecting – for that world.