What an AI agent actually does to your product

You've probably heard the buzz. Everyone's talking about adding an AI agent to their product, promising it will revolutionize user experience, slash support tickets, and basically do everything short of making coffee. But beneath all the hype, there's a more interesting question worth asking: what does an AI agent actually do to your product once it's in there?

Not in theory. In practice.

Because the reality is more nuanced than the sales pitch suggests. An AI agent doesn't just sit quietly in a corner answering questions. It changes how users interact with your interface, shifts their expectations, and sometimes creates entirely new behaviors you never anticipated. Some of those changes are genuinely exciting. Others can catch you off guard if you're not paying attention.

In this post, we're going to break down the real impact an AI agent has on your product, covering user behavior shifts, technical considerations, and the subtle ways it reshapes your overall product experience. Whether you're evaluating your first integration or already knee-deep in one, this analysis will give you a clearer picture of what you're actually working with.

What an AI agent is

An AI agent is software that perceives its environment, decides what to do next, and acts. Then it perceives again, decides again, and acts again. It runs this loop without a human confirming each step, which is the property that makes it genuinely different from every AI tool that came before it.

The contrast with a chatbot is worth being precise about. A chatbot responds to a prompt: you send a message, it sends a reply, the interaction ends. An agent pursues a goal across multiple actions and tools, and when something fails it adapts rather than stopping. The chatbot answers the question "what flights are available on Friday?" The agent books the cheapest one, checks the hotel, and sends you a confirmation. One retrieves; the other executes.

The contrast with a script or RPA bot is equally important, and often glossed over. RPA automation executes a fixed, pre-defined sequence of steps. It is auditable and deterministic, which is genuinely valuable, but it breaks the moment anything unexpected appears on screen. An AI agent reasons about which steps to take, based on what it observes. Its path through your product is not predictable in advance. That distinction matters enormously for anyone designing or testing a product: a script will always click the same button in the same order; an agent will take whatever route its reasoning suggests, including routes you never anticipated.

"Environment" is doing real work in that definition. For most deployed agents in 2026, the environment is the web: pages, forms, APIs, and the text currently visible on screen. Not a structured database. Not a clean JSON feed. The raw, inconsistent surface that a human browser session encounters, copy changes, modal interruptions, slow-loading price tables and all.

A concrete example makes this land. A user asks their agent to book a flight, compare hotel prices, and confirm the itinerary. The agent opens tabs, reads copy, fills forms, and clicks confirm. That behaviour is not metaphorical. The agent is acting as a user: generating the same page loads, the same form submissions, the same checkout events that a human would. It is, for every practical purpose, a visitor to your product. The question product and design teams now face is whether their product actually works for that visitor.

Why this is happening now, not in 2028

The numbers being cited in board decks right now are not projections for a market that might exist. They describe a market that already does. The agentic AI market sits at $19.33 billion in 2026, on a trajectory to $205.88 billion by 2033 at a 40.2% CAGR. That is current enterprise spend, not a baseline assumption. Organisations have moved past the pilot stage and are deploying agents across customer service, IT operations, software engineering, and finance. The question product and design teams are actually facing is not whether this happens, but whether their products work when it does.

The infrastructure signal worth watching is MCP: Model Context Protocol. MCP is the plumbing that lets agents authenticate, access tools, and operate within enterprise governance without bespoke integrations for every system. Firecrawl recorded a 35% uplift in MCP usage in a single month in early 2026. MCP public server adoption has crossed 9,400 servers. A 35% monthly increase does not describe gradual adoption; it describes standardisation happening fast. Two years ago, agents needed custom access arrangements for every tool they touched. Now there is a shared protocol, and enterprises are converging on it at pace. That compression of integration friction is one of the concrete technical reasons deployment is accelerating in 2026 rather than 2028.

For product teams specifically, one figure from Firecrawl reframes the roadmap conversation: 20% of e-commerce tasks are expected to be agent-handled. One in five checkout, search, or product-discovery interactions will be initiated or completed by an agent acting on behalf of a person. That is not a niche automation case for enterprise procurement. It includes the flows that most product teams have spent years optimising for human behaviour: the address form, the filter panel, the cart summary, the confirmation screen. An agent navigating those surfaces does not scroll, does not read microcopy, and does not recover gracefully from an ambiguous error state. If a product team has not yet asked how those flows perform for a non-human actor, that is the gap.

Gartner's 2028 projections are the destination that current build cycles are targeting. Thirty-three percent of enterprise software will feature agentic AI by 2028. Sixty percent of brands will use agents for one-to-one customer experience by the same date. With median payback on agent deployments sitting at 5.1 months, according to enterprise adoption data compiled by Digital Applied, the products that will meet those milestones are entering design or redesign cycles now, not in 2027.

The consumer signal arrived in January 2026, when OpenClaw went viral. The significance was not the technical sophistication of the product; it was the audience. A personal agent capable of acting on the web with real permissions became a mainstream conversation. When that happens, the pool of people who will encounter agent-driven interactions in their daily digital life extends well beyond enterprise IT departments. Product teams building for human users in 2026 are, whether they have designed for it or not, also building for the agents those users will increasingly send in their place.

How agents experience products differently from humans

The gap is not about intelligence. It is about perception: agents and humans look at the same page and see fundamentally different things.

Agents do not hover. A significant share of UI affordances exist only as interaction states: the tooltip that appears when a cursor rests on an icon, the label that surfaces on hover, the dropdown that reveals itself when a pointer moves close. An agent reading a page works from what is present in a persistent, readable state. It does not simulate a cursor. If the only label for a button lives in a hover tooltip, the agent operates without it. That is not an edge case; it is a structural blind spot built into products designed for mouse-driven human behaviour. Forty percent of enterprise apps are projected to embed task-specific agents by end of 2026, up from under five percent in 2025. A meaningful share of those agents will encounter hover-dependent affordances and simply skip past them.

Agents read copy literally. A human seeing "Continue" on one screen and "Confirm" on the next infers from visual context which action does what. An agent acts on what is written. "Next" and "Submit" are not interchangeable when an agent is deciding whether to advance a step or finalise a transaction; they describe different operations, and if the copy does not distinguish them clearly, the agent either stalls or takes the wrong path. The shift from command-based to intent-based interaction that Nielsen Norman Group calls the first new UI paradigm in 60 years cuts both ways: if the agent operates on intent, the product must express intent without ambiguity. Vague microcopy that a human resolves in half a second becomes a hard disambiguation failure for an agent.

Agents have no patience for interruptions. A cookie consent banner mid-flow takes a human two seconds to dismiss. An agent that was not designed to expect that modal may halt, loop back to the previous step, or exit the flow entirely. The same applies to upsell interstitials, GDPR overlays, and re-authentication prompts. These are not minor friction points; they are hard blocks. The emerging discipline of agentic experience design (sometimes called AX) specifically identifies interruption handling as one of the structural patterns that must be rearchitected for agent compatibility. Products built around interruptive consent flows are building invisible walls into every agent-driven journey.

Agents do not recover silently. When a human hits an unexpected state, a broken redirect or an ambiguous error message, they look around and adapt. Agents, as a mid-2026 review of autonomous task horizons notes, "drift, miss implicit constraints, and sometimes compound small errors into large ones." More problematically: an agent that reaches an unexpected state often fails without surfacing it. No error log entry, no support ticket, no session recording. The product team sees nothing. The failure is invisible to the business, which makes it structurally worse than a human complaint. At least a complaint is signal.

Session behaviour differs structurally. Products are designed around a single continuous session with predictable start and end points. Agents operate on a different rhythm. They may return to a page mid-task after a pause, hold sessions open across intervals no human would sustain, or run the same flow multiple times in rapid sequence as part of a larger orchestrated workflow. Claude Mythos Preview reached a 16-hour autonomous task horizon in March 2026. Products built around session timeouts, single-use tokens, or the assumption that one session maps to one human intent will behave unpredictably under these conditions.

The pivot question is this: if agents are already traversing your product, are you building for them? The answer matters now, not in 2028.

Four things agents do in your product, and where things break

Agents are goal-directed. MIT Sloan's overview of agentic AI puts it plainly: they evaluate their environment against an objective and abandon any path that does not appear relevant. That single behaviour has consequences your analytics dashboard was never built to catch.

Discovery

The first thing an agent does is scan your product to decide whether it is worth entering. It reads headings, navigation labels, and page descriptions, then maps what it finds against the goal it has been given. If that mapping fails, the agent exits. No error, no bounce event you can act on: it simply moves on to the next candidate.

The failure condition here is specific. It is not that your site is unclear to humans. It is that your information architecture is written in brand language rather than task language. A page labelled "Our Solutions" gives the agent almost nothing to work with. A page labelled "Compare pricing plans" gives it a direct signal. The agent is not reading between lines or inferring intent from visual hierarchy. It is matching text to a task. If the text does not match, the page does not qualify.

The business consequence is blunt: the agent never enters the funnel. Not a drop-off at step three, not an abandoned basket. It never arrives.

Information retrieval

Once the agent is inside a relevant page, it extracts specific data points to satisfy a requirement: price, availability, specification, policy. IBM's reference on AI agents describes this as perception and tool-calling: the agent constructs an internal model of your product from what it can actually read. When retrieval mechanisms are blocked, that internal model becomes inaccurate, and the agent carries the inaccuracy forward into every subsequent action.

Three things reliably block retrieval. Data locked in a PDF, because the agent cannot parse an unstructured document the way a browser renders HTML. Data rendered inside an image, because there is no machine-readable text to extract. Data placed behind a login the agent cannot navigate, because the credential flow either fails silently or is never designed for non-human actors. In each case, the failure does not produce an error state. The agent reports the data as unavailable, which may not be true, and the user receives incorrect information about your product.

That last point matters more than it looks. Retrieval failure is not a lost session. It is a wrong answer attributed to your product.

Task completion

This is the stage product teams are least worried about, because a human can complete the task. That reasoning does not hold for agents. The agent fills forms, selects options, and submits, but it cannot hover to reveal a tooltip-blocked button. It cannot infer from visual context that "Proceed" means confirm rather than go back. It cannot recover gracefully from a multi-step wizard that renders an ambiguous back-button state mid-flow.

The failure mode here is silent completion: the agent reaches an apparent end state, but the transaction has not gone through. No error is thrown. The agent's internal log records success. The user believes the task is done. The product has no record of a completed transaction, and no monitoring alert has fired.

Confirmation dialogs with non-standard labels are a reliable source of this failure. If your "confirm" button says anything other than "confirm" or a direct equivalent, the agent's probability of selecting the correct option drops. This is not an edge case in agent behaviour. It is a predictable consequence of training on patterns, and standard interface copy does not produce those patterns consistently.

Delegated access

The fourth mode is categorically different from the first three. Here, the agent is not acting as an anonymous visitor or an unauthenticated browser. It is acting on behalf of a specific human who has granted it permission to do so. Onboarding flows, OAuth screens, and account permission dialogs are written for humans who understand what delegation means and can read contextual cues that explain why they are being asked for consent. Many of these screens are navigable by an agent. Many are not.

The ones that are not cause the delegated task to abort before it starts. Not mid-flow, not at confirmation: before the agent has taken a single action on the user's behalf. The user granted permission, the agent attempted to exercise it, and the product's access flow produced a state the agent could not parse. The user cannot use the agent with your product at all, not because the agent failed, but because the onboarding screen was never designed for a non-human actor exercising delegated rights.

Why none of this shows up in your monitoring

No JavaScript error is thrown. No 4xx or 5xx HTTP status code is returned. The agent stops, or proceeds incorrectly, and standard monitoring records nothing unusual. Session analytics show a completed session or a quiet exit. Error logs are clean. Conversion dashboards reflect the drop, if it is large enough to be visible, but attribute it to nothing.

This is the monitoring gap. It sits underneath every failure type described above, and it means that products can be systematically hostile to agents for months before any signal reaches the team responsible for fixing it.

What multi-agent systems and MCP mean for product surfaces

The previous sections covered what a single agent does inside your product. This section is about what happens when several agents arrive at once, coordinated, each with a specific job.

Multi-agent architectures split complex goals into sub-tasks and assign each to a purpose-built agent. A travel booking workflow might involve a research agent that queries availability, a booking agent that completes the reservation form, and a payment agent that handles checkout. Each touches a different part of your product, potentially within the same session, and none of them were anticipated when your flows were designed. The practical consequence is that a single user intent can now produce multiple authenticated sessions across multiple surfaces in quick succession. Your analytics will not group them together. Your session state may not survive the handoffs between them.

MCP (Model Context Protocol) is the standard that defines how agents authenticate and call external tools. It lowers the integration cost for an agent to reach a product reliably, without bespoke per-integration engineering on either side. Analysts tracking real-time context in multi-agent systems are explicit: the infrastructure decisions that underpin agent-to-product access are no longer theoretical. The 35% monthly MCP usage uplift reported by Firecrawl in early 2026 is the operational signal that matters here. It means more non-human authenticated sessions arriving at products that were built for human visitors. Not gradually. Quickly.

Persistent memory compounds this. Agents with cross-session memory do not start from the beginning on re-entry. They arrive mid-task, carrying stored state from a previous visit, and expect to continue from where they left off. A product that assumes a fresh session on every visit will present that agent with a context it cannot resolve: a checkout that requires address details already supplied two sessions ago, or an onboarding step that the agent completed last Tuesday. Builders working directly with agent systems frame persistent memory as a database problem, not an AI problem. The session design decisions that work for humans do not transfer automatically.

Orchestration failures introduce a further failure class that product teams have not had to account for before. When Agent A hands off to Agent B mid-task, the handoff carries state. If your product does not maintain consistent state across that interval, the second agent begins from an inconsistent position: partial data, incomplete flags, or a step counter that does not match the actual progress of the task. This is not an edge case for complex deployments. It is the default risk of any multi-step agent workflow that crosses product boundaries.

The reframe this requires is structural. Your product surface is one node in a larger agent workflow, not the destination of a user journey. Designing for that means asking different questions: what state does an agent need to reconstruct context on re-entry, what signals does your product expose that confirm a task was completed, and which flows will break silently when the session arrives mid-step rather than at the beginning.

The readiness gap: QA with AI is not QA for agents

77.7% of quality engineering teams have adopted AI-first approaches in 2026, according to ThinkSys data. That number has moved fast: PractiTest's State of Testing report shows the figure climbing from roughly 40% in 2024 to 76.8% in 2026. Most of those teams are using AI to generate test cases, speed up scripted tests, and reduce the hours spent on manual coverage. The tooling has genuinely improved. Test case creation that used to take days now takes hours. That is a real gain.

The problem is what that gain does not cover.

Using AI to write tests is not the same as testing what an AI agent does. A generated test script still follows a fixed path. It executes a predetermined sequence of actions, checks the expected state, and reports pass or fail. An AI agent navigating your product does not follow a fixed path. It perceives the interface, reasons about it, decides what to do next, and acts. No script author anticipated the sequence it will take, because no script author wrote one.

This is not a variation of the same problem. It is a different class of problem entirely.

AI-assisted QA improves coverage of known paths: flows a human mapped out, edge cases a tester anticipated, regressions on journeys the team has already documented. Agent simulation tests emergent behaviour on unknown paths: what the agent does when a label is ambiguous, when a form validation message is written for a human reader, when a multi-step checkout flow holds implicit state the agent has no way to infer. These two disciplines do not overlap. More of one does not produce any of the other.

The framework proliferation data makes the gap more visible. 74.6% of QA teams now use two or more automation frameworks. That is a lot of tooling. But additional frameworks extend coverage of scripted scenarios: they do not add coverage of unscripted agent behaviour. A team running Playwright alongside Cypress has more scripted paths covered. It has zero agent simulation runs. The frameworks are solving for the wrong surface.

Agentic QA and AI-assisted testing are increasingly distinguished in engineering discussions in 2026, but the distinction has not yet translated into a measurable adoption curve for agent-specific simulation. Almost every product team has incorporated AI into QA in some form. Almost none are testing how an AI agent actually experiences their product. The adoption curve for agent-specific testing has not started. That is the readiness gap: not a technology gap, not a budget gap, a category gap. Most teams do not yet have a name for what they are not doing.

What agent simulation requires is different in kind. You send an agent through the product with a goal: book this, retrieve that, complete this form. You observe what it does. You capture where it stalls, where it misreads a label, where it exits without completing the task. The output is not a pass/fail on a known path. It is a record of emergent behaviour, a log of what the agent did and where the product stopped making sense to it. In film terms, this is a take, not a script. The agent is the actor. The product is the set. What you are watching for is the moment the scene breaks down.

What an agent-ready product looks like

The gap between "works for humans" and "works for agents" is not abstract. It shows up in six specific places, and each one is a decision your team can make.

Microcopy first. Agents do not interpret brand tone. A button labelled "Let's go" tells an agent nothing about what will happen when it activates that element. "Submit payment" does. The shift is not about stripping personality from your product; it is about reserving literal language for interactive elements and confirmations, where ambiguity causes agents to stall or misfire. Before/after is straightforward: "Proceed" becomes "Confirm and submit order." "Get started" becomes "Create account." Every label should answer one question: what does this action do?

Information architecture follows the same logic. Navigation built around internal brand categories ("Solutions," "Platform," "Resources") assumes a human who browses and infers. An agent queries: it arrives with a goal, looks for a match, and either finds one or fails silently. Navigation and heading structure written around task language ("Find a flight," "Manage your subscription," "Download invoice") gives an agent a legible map. It also gives humans one, which is the point: task-language IA is not a concession to machines. It is better architecture for everyone.

Interstitials are where agents abandon. A cookie consent banner that blocks the viewport, a mid-checkout upsell modal, a re-engagement overlay at minute two: each was designed assuming eyes that scan and fingers that tap. An agent following a primary goal has no mechanism to "close" a modal that lacks a clear, reachable dismiss control. The fix is not to remove interstitials. It is to ensure every blocking element has a programmatically dismissible route, clearly labelled, that does not require interpreting visual context.

Delegated access flows deserve particular care. OAuth screens designed for humans lean on context: the user already knows what app they connected, what they were doing, and what grant they are approving. An agent arriving at a permission screen mid-task has none of that prior context. The screen needs to explain the grant in plain terms, state the scope, and offer a clear confirm action. "Allow access" is not enough. "Allow [product name] to read your calendar and create events" is.

Session consistency matters more as agent tasks get longer. A human returning to an abandoned basket tolerates a prompt to log in again. An agent resuming a delegated task after a session interruption needs to re-enter the same state it left. Products that handle re-entry gracefully, storing task progress and restoring it on return, are products agents can complete work inside.

Observability closes the loop. Without the ability to detect that a session is agent-driven and trace what that agent did, where it paused, and whether it finished, failures stay invisible. No error is logged. No alert fires. The task simply does not complete. This is the capability most products currently lack entirely, and it is the one that makes every other improvement testable.

How to start testing your product for agent behaviour

Before writing a single test, map which of the four agent behaviours are most likely to occur in your product: discovery, information retrieval, task completion, and delegated access. Most products surface all four, but they do not surface them equally. A travel booking product is primarily a task completion surface. A documentation portal is primarily an information retrieval surface. Starting with that map tells you where to direct your first tests, and it tells you what a failure actually looks like in your specific context.

Start with task completion. It produces the most visible failures because the outcome is binary in a way the others are not: either the booking exists or it does not, either the form submitted or it did not. Discovery failures are harder to observe because an agent that cannot find a feature simply stops rather than erroring. Task completion failures surface as abandoned sessions, incorrect confirmations, or completed-but-wrong outcomes. Those are the failures that cost real money, and they are the ones worth finding first.

Define a goal, not a script. This is the single biggest adjustment teams make when moving from traditional QA to agent testing. A script specifies steps: click this, fill that, submit here. A goal specifies an outcome: "book a return flight to Edinburgh for next Friday under £200." The agent determines its own path. The test measures whether the goal was achieved. Anthropic's evaluation framework makes this distinction explicit, noting that frontier models can find creative paths through tasks that a scripted eval would score as failures even when the outcome was correct. Goal-based criteria catch what scripted criteria miss.

Run the test against your real product, not a staging stub. Agents encounter the same modal windows, cookie notices, session timeouts, and live data states that a real user encounters. A clean staging environment has none of those. A cookie banner that blocks the price comparison row is a product surface problem, but it only appears in production. Session timeouts mid-task cause agents to restart or stall, and that behaviour only surfaces under real load conditions. Results from staging do not transfer, and the failures staging hides are often the most consequential ones.

Capture what the agent did, not just whether it passed. A binary pass/fail tells you the outcome. It tells you nothing about the path: where the agent paused, which element it misread, which step it attempted twice before abandoning. The diagnostic artefact is the trajectory: the full record of what the agent did, annotated with the points where it changed course. A pass with a convoluted path is a warning. A fail that pinpoints the exact modal window that broke the session is a brief.

Stunt Double sends AI agents through your product to simulate exactly this: discovery, information retrieval, task completion, and delegated access. The findings it produces name what the agent did and identify where the product surface caused it to fail. Running a first take is where you start.

Agents are already in your product

The shift already happened. The agentic AI market sits at $19.33 billion in 2026, MCP adoption jumped 35% in a single month earlier this year, and one in five e-commerce tasks is expected to be handled by an agent. These are not projections for a market that might arrive. They describe traffic that is already moving through your product.

The problem is not that product teams are ignoring AI. 77.7% have adopted AI-first quality engineering, and that number climbed fast. But testing with AI and testing for AI agents are different activities, and most teams are doing the first without knowing they need the second. Using AI to write or accelerate test scripts does not tell you how an autonomous agent traverses your checkout, reads your policy page, or hands off a delegated task. Those are separate questions, and right now most products have no answers for them.

Agent failures do not surface in error logs. An agent that abandons a basket at the address form does not throw a 500. A delegation that never starts because the form label was ambiguous does not appear in your monitoring dashboard. The failure is silent: a goal that quietly went unmet, a session that closed without resolution. Standard observability was not built to see this class of problem.

The starting point is narrow. Pick one flow: checkout, onboarding, or search. Run an agent through it with a defined goal. Observe what it does, where it stalls, and what it misreads. That observation is the gap between what your team built and what an agent experiences.

Agents are using your product now. The question is whether your team knows what they are finding.

Conclusion

An AI agent is not a simple feature drop. It is a fundamental shift in how users experience, navigate, and form expectations around your product.

The key takeaways are clear: user behavior will change in ways you did not plan for, your technical infrastructure needs to be ready for the load, and the overall product experience will be reshaped whether you guide that process or not. Most importantly, the teams that win are the ones who treat AI integration as an ongoing practice, not a one-time launch.

So start with intention. Map your use cases, monitor user patterns closely, and build feedback loops that help you adapt quickly.

The products that will define the next few years are not just the ones that added AI. They are the ones that understood what AI actually does once it is inside.