When somebody asks how to add AI to an existing product, the conversation usually starts with features: a chatbot, intelligent search, document summarisation, recommendations, generated content or an agent embedded in the interface. Any of those might be useful, but a more fundamental shift is beginning.
For the past couple of years, we have mostly asked how to put an agent into a piece of software. Increasingly, we also need to ask how to let a user’s agent operate the software that is already there. That changes who, or what, we design the product for.
A web app may still be used primarily by people, but some of those people will arrive with an AI agent acting on their behalf. Instead of opening several screens, applying filters and working through a series of forms, they might ask:
Show me everything that needs attention, explain why, and prepare the necessary updates for me to review.
The application still owns the data, permissions, business rules and workflow. The agent provides a new way to use them.
Adding AI now means two different things
There are two broad ways to add AI to an existing web application.
The first is to put AI capabilities inside the product. A model might classify information, extract data from documents, generate a first draft or help a user make a complex decision. The product controls the experience, supplies the context and applies AI at a chosen point in the workflow.
The second is to make the product usable by an external AI agent, whether that is provided by ChatGPT, another general-purpose assistant, an organisation’s internal AI platform or a specialised agent. The application exposes a clear, safe way for that agent to understand its capabilities and act on the user’s behalf. Some products will eventually need both approaches.
How can an AI agent use a web app?
There are currently three main ways for an agent to interact with a web application: general browser or computer use, a backend integration using the Model Context Protocol, and an in-browser integration using WebMCP.
Each works at a different layer.
Browser and computer use
Browser use means an agent reading pages, clicking links, filling in forms and navigating between tabs. Computer use extends the same idea to native applications, windows and files. In both cases, the agent operates a graphical interface much as a person would.
The advantage is reach: a browser agent can work with almost any existing website without a dedicated AI integration. Modern agents can navigate unfamiliar applications, interpret forms and recover from some errors, making this a useful fallback for legacy systems and occasional tasks.
The trade-off is that browser automation remains indirect. Every label, click and loading state has to be interpreted, while a visual redesign or ambiguous validation message can change the route through a task. The agent is working through frosted glass: it can make out the controls and operate them, but it cannot access the application code behind them, even when that code could perform the same operation more directly.
MCP and backend integrations
The Model Context Protocol, usually shortened to MCP, provides a standard way for AI applications to connect to external data and tools. An MCP server can expose named capabilities such as searching records, retrieving a report, creating an item or updating a status. The agent receives structured descriptions of those tools and calls the relevant function directly.
This is a much better fit for tasks that need to run independently of the application’s human interface. An MCP integration can work while no browser tab is open. It can support background processes, recurring workflows, bulk operations and actions involving several systems.
MCP has evolved quickly. Earlier versions required an initialisation handshake and protocol-level session state. The July 2026 version of the MCP specification makes its protocol core stateless and closer to ordinary HTTP. For an existing Django web application, an MCP endpoint can therefore sit more naturally alongside established permissions and business logic instead of becoming a parallel system.
WebMCP and the live web application
WebMCP is a proposed browser standard that allows a web page to expose its capabilities as structured tools. The agent and user work with the same live application, signed-in session and page state, but the agent can call an action directly instead of inferring it from buttons and forms.
This makes WebMCP a middle ground between browser automation and a backend MCP integration. The agent still visits the web application that the person uses, while the page provides a machine-readable description of useful actions such as finding a record, submitting a form or updating the item currently on screen.
As of September 2026, WebMCP is a Community Group draft rather than a W3C standard. Chrome is running an origin trial, while OpenAI exposes WebMCP-powered Site tools in its built-in browser. It is real enough to prototype with, but early enough that it should be treated as an experiment rather than a dependency for core functionality.
MCP vs WebMCP: which should you use?
Start with one valuable task rather than trying to expose the entire application. A good first task is frequent, currently requires several interface steps and produces an outcome that is easy to verify. Read-only questions such as “what needs my attention?” are particularly useful because they demonstrate value without introducing much operational risk.
Think in terms of outcomes rather than reproducing the existing interface for agents. An agent does not particularly benefit from a machine-readable version of every button and tab. A capability such as “show me the things that need attention” is much more useful than exposing a sequence of “open screen”, “select filter” and “click next” operations.
Then decide where the capability belongs. Use WebMCP when the agent should collaborate with the user inside the current page. Use MCP when the capability should remain available independently of the website. Use an embedded AI feature when the intelligence itself is part of the product experience.
Whichever route you choose, enforce the application’s existing permissions at the action boundary, require human confirmation for consequential changes and keep an audit trail of what the agent did.
Does agentic software mean the end of SaaS?
There has been plenty of speculation that general-purpose agents will replace conventional software products. A more plausible outcome is that they will change how people consume software.
Applications still own data, identity, permissions, workflow, specialist business rules, integrations and real-world fulfilment. People will still need visual interfaces for exploration, review and exceptions, but may spend less time navigating routine processes. The product’s interface expands to include both the visual experience and a structured capability surface for the agent working alongside it.
Build for people and their agents
The exact WebMCP APIs and patterns will continue to evolve. Designing software around explicit capabilities, narrow actions and understandable outcomes is valuable regardless of which browser or protocol becomes dominant.
Adding AI to an existing web application may involve an embedded model, an MCP server, WebMCP tools or a combination. The right approach depends on the user’s goal, the context the agent needs and where the work should take place. Increasingly, a good web product will be judged both by how well a person can use it and by how safely their agent can use it for them.
Is there an even simpler option?
I’ve been developing the Hypermedia Agent Protocol, or HAP. The premise is deliberately boring: the web was already a protocol for user agents, so perhaps an AI agent does not always need a large tool schema. A HAP application exposes an agent-oriented hypermedia interface as Markdown over normal HTTP, explaining what the agent can see, do and visit next.
As a practical integration for mainstream cloud-hosted agents, however, HAP is currently something of a non-starter for a fairly mundane reason: authentication. The major agent platforms have built good mechanisms for users to delegate access to MCP servers, but those mechanisms are tightly bound to MCP itself. They have relatively little incentive to generalise them simply to make alternative approaches easier.
I would very much like to see that change. Authentication and credential delegation are not intrinsically MCP concerns. If agent providers exposed a generic way for a user to grant an agent access to an arbitrary HTTPS service, without handing long-lived credentials to the model, it would open up a much wider range of possible agent integrations. HAP is one example, but it certainly would not be the only one.
At DabApps, we help teams decide where AI belongs in existing products and build the product, interface and engineering around it. That includes AI-enabled features, MCP integrations, WebMCP prototypes and agent-ready web application architecture.