Agents are turning software capabilities into an interface of their own. The next enterprise design problem is deciding what should be callable, by whom, and under which boundaries.
We spent decades designing software for people to operate. Agents are forcing us to design software that can be operated on our behalf.
I started working on the web in 1998. For most of my professional life, an interface meant the place where a person met a system.
We obsessed over what the user could see, understand and do: navigation, labels, forms, feedback, error states. The quality of the software was inseparable from the quality of that visible layer because the human being was the one interpreting what was happening and deciding what to do next.
That assumption is starting to break.
An AI agent does not necessarily need to click through the same application an employee uses. It can increasingly call the underlying service directly: retrieve the customer record, check inventory, create a ticket, update a campaign, issue a request, start a workflow.
The important interface is moving behind the screen.
A lot of enterprise software was never designed for that.
Human users are extremely forgiving integration layers.
We learn that one field is badly named but actually means something else. We know which dropdown option everyone chooses even though none of them is quite right. We notice that a result looks strange and stop before pressing confirm. We understand that an action which is technically available should not be used in this particular situation.
None of that necessarily exists in the software contract.
It exists in the person operating it.
That distinction matters much more when software begins acting through tools rather than through people.
A tool exposed to an agent has to describe, with much greater precision, what the action is, what inputs it needs, what it changes and what should happen when the situation does not fit the happy path. The model can reason, but it should not have to reverse-engineer years of undocumented organizational convention from a vague function called update_customer.
This is why the current movement around agent protocols matters beyond engineering.
The Model Context Protocol's August roadmap describes the July 2026 specification as a substantial move toward stateless, horizontally scalable servers, stronger authorization and cacheable discovery. It also identifies agent identity, delegation and progressive tool discovery as active priorities. The maintainers explicitly note that connecting a model to a server with a hundred tools imposes cost before a user has asked a question and that tool selection tends to worsen as the surface grows.
The Linux Foundation's Agent2Agent project is moving in the same broad direction from another layer. In April it reported support from more than 150 organizations, stable version 1.0, cloud-platform integrations and production use across several industries.
The protocols will keep changing. The structural shift is more important.
Software is acquiring a second audience.
Not another kind of user.
Another kind of operator.
This changes what an application boundary means.
For years, enterprise software vendors competed partly by owning the screen. The application was where the employee went to do the work. More users meant more seats, more workflows inside the product and usually more value captured by the vendor.
Agentic systems weaken that relationship.
Gartner estimated in July that as much as $234 billion in enterprise application spending could be exposed to what it calls "agentic arbitrage" by 2030: agents completing work across multiple systems while reducing the need for people to operate every application directly. The estimate is Gartner's forecast, not an observed market outcome, but the mechanism is already legible.
If an agent becomes the layer through which work is initiated, the visible application can become less important in some workflows than the quality of the capability it exposes underneath.
That is a product shift, not merely an integration trend.
A CRM may still matter enormously. But an agent may not care about its navigation, dashboard hierarchy or button placement. It cares whether it can reliably retrieve the right account, distinguish a lead from an existing customer, understand which fields are authoritative and perform a narrowly defined action without damaging something else.
The same is true for finance systems, content platforms, service tools, internal databases and operational software.
The question stops being only:
Is this application easy for a person to use?
A second question appears:
Is this organizational capability safe and intelligible enough for a machine to call?
Many companies will discover that the answer is no.
It is tempting to reduce this to integration work.
We already have APIs. Connect the agent. Done.
But APIs were usually designed for deterministic software written by developers who already knew which endpoint they wanted to call. Agent tools are consumed differently. The model may be choosing among many possible actions, deciding which one fits the situation and assembling a sequence dynamically.
That makes the design of the callable surface part of the reasoning environment.
A large, technically complete API can be a terrible agent interface.
Imagine exposing an entire order-management system with hundreds of operations. Somewhere inside it are the four actions the agent actually needs. The rest is not free capability. It is additional ambiguity, additional permission surface and additional opportunity for the system to choose badly.
The better abstraction may be much smaller:
These are not merely API endpoints. They are business capabilities with boundaries.
Recent standards and security work keeps converging on the same problem from different directions. NIST opened a dedicated 2026 effort around software-agent identity and authorization because agents increasingly need to access multiple resources while acting with delegated authority. Microsoft's security guidance argues for least privilege, explicit tool binding and scoped identities rather than giving an agent broad standing access simply because it may need that access eventually.
The interesting work is not adding more tools.
It is deciding what deserves to become a tool at all.
This is where many agent projects become unexpectedly multidisciplinary.
The technical team can expose an action.
Someone still has to answer what that action means.
If an agent can "create a customer", what is the minimum valid customer? Which source owns the identifier? Can it create duplicates? Does creating the record trigger downstream workflows? Can the action be undone? Which fields may be inferred and which require explicit input? What should happen when two systems disagree?
Those are product, operational, data and policy questions hiding inside what looks like an integration task.
The quality of an agent experience will depend partly on whether those questions were answered before the model arrived.
This also explains why some organizations will get surprisingly little value from very capable agents.
The model may be excellent. The systems around it may still present the company as a pile of screens, undocumented conventions, shared credentials, brittle integrations and giant APIs whose meaning lives mostly in the heads of experienced employees.
In that environment, the agent has intelligence but very little clean leverage.
Giving it browser access can bridge some of the gap. Computer-use systems are useful precisely because they can operate software that was built only for humans. But treating browser automation as the permanent architecture would be like deciding that every system integration should work by controlling a mouse.
Sometimes that is the practical answer.
It should not automatically become the destination.
I would add a layer to the way organizations think about AI readiness.
Not just model readiness.
Not just data readiness.
Capability readiness.
Take one workflow that matters and map the actions required to complete it. Then ignore the existing application boundaries for a moment.
Which actions are real business capabilities? Which can be exposed cleanly? Which are read-only? Which create side effects? Which need a person in the loop? Which can be reversed? Which require delegated identity rather than a shared service account? Which still depend on a human knowing something the system has never represented?
That exercise will tell you more about agent readiness than another demo.
It will also reveal architectural debt that has very little to do with AI: poorly defined ownership, duplicate data, business rules embedded in interfaces, manual workarounds, permissions inherited from old org structures, operations that cannot be safely undone, systems that expose technical objects rather than meaningful business actions.
Agents simply make these weaknesses harder to ignore because they remove the human being who used to compensate for them.
This is also why evaluation has to follow the runtime rather than the model label. As I argued in The benchmark needs a runtime address, the system being qualified increasingly includes routes, tools, harnesses and operating conditions. The callable surface is part of those conditions.
For a long time, digital transformation meant making organizations legible to people through software.
We turned processes into screens. Policies into forms. Business rules into buttons and validation messages. We made increasingly complicated systems operable by humans.
Agentic AI creates the inverse challenge.
Now organizations have to make their capabilities legible to machines without making those capabilities dangerously broad.
That is not mainly a chatbot problem. It is not solved by buying the model with the highest benchmark score. And it will not be solved by connecting every internal API to an agent and calling the result transformation.
The next important interface may be invisible: the carefully designed contract between an intelligent system and the organization it is allowed to act upon.
For most of my career, interface design asked what a person should be able to see and do.
The next question is different:
What should the organization make callable?
Berk Bayri
Creative Technology & Innovation Leader
Designing and building for digital environments since 1998, across strategy, product, design, technology and organizational innovation.
About Berk →New essays by email, when they are published.