When Your Customer Stops Opening Your App: Marketing in the Agent-Owned Web

At 8:47 on Monday morning, a head of growth gives her agent an objective:

Keep acquisition cost below £58 this week. Protect branded search. If demand weakens, move no more than 10% of prospecting budget without asking me. Prepare the launch plan for Friday.

Then she closes the conversation.

She does not open Google Ads, Meta Ads Manager, GA4, the CRM, the ecommerce dashboard or the project-management app. Her agent already knows the account structure, campaign history, margin limits, brand rules and approval policy. It checks performance through the day, investigates a conversion drop, asks a specialist agent to test three explanations, drafts a budget change and returns when human judgment is required.

The applications still matter. Their interfaces no longer organise the work.

That distinction captures the next stage of the agentic web. We have already examined two parts of it. In Marketing to the Machines, we explored the personal agent as a gatekeeper between brands and consumers. In WebMCP: The Bridge to an Agent-Ready Web, we looked at websites exposing structured actions so agents could use them without guessing their way through the interface.

Both pieces described part of the system. The more consequential picture appears when we add a persistent agent that can remember, schedule, learn and act across many products.

Lovable is turning applications into capabilities. WebMCP and MCP make capabilities callable. Persistent agent systems add memory, skills and continuity. Together, they point towards a web organised around human goals rather than application sessions.

If customers stop opening SaaS applications and delegate outcomes to persistent agents, who owns the customer, the workflow and the margin?

WebMCP Is The Access Layer

WebMCP makes a website callable. Instead of making an agent interpret pixels, locate controls and simulate clicks, a site can declare structured actions: search inventory, change a date range, add a comment, configure a product or update an itinerary.

That solves access. It does not provide agency. The protocol cannot decide what the customer wants, remember their preferences, choose between competing services, manage a budget or continue working after the page closes.

Those responsibilities belong to the agent system surrounding the model. In this article, agent means that complete operating system: model, memory, skills, tools, schedules, permissions, budgets and feedback. Engineers may call parts of it the harness or runtime.

This separation creates the business problem. A SaaS product may still supply valuable data, logic and execution while another system carries the customer context, chooses the capability and decides when the product enters the workflow. The application can remain essential while losing the customer relationship.

One Application, Two Interfaces

The missing business idea comes from Lovable.

Lovable became known as a way to create applications by describing them. Its newer direction is more disruptive to the idea of an application itself. In an interview with Latent Space, Lovable CTO Fabian Hedin described a capability as a useful part of an application that an agent can call directly. A published application can expose selected functions through a hosted MCP server, producing one product with two interfaces: a visual interface for people and a tool interface for agents. Latent Space

This changes the unit of software consumption.

A person once bought access to an application and learned its navigation. An agent can request the capability it needs: grant a customer credit, produce a forecast, reconcile an invoice, configure a campaign, retrieve inventory or initiate a return. The application remains behind the capability, providing data, domain logic, permissions and execution.

Lovable’s larger concept is a company brain with enough organisational context to use capabilities across many applications. It can also work asynchronously: schedule itself to resume a task, monitor a process and return to the same conversation later. Hedin expects people to keep fewer software tabs open while the specialised capabilities supplied by those products remain valuable.

This is already more than a slideware architecture. Lovable’s app-user connectors let each user connect services such as Google Workspace, Salesforce, Slack and HubSpot with their existing source permissions. Lovable’s connector gateway holds the credentials and passes the user’s identity through to the connected system. Lovable

The product is therefore being separated into four things:

A human interface for inspection, judgment and exception handling.
A set of capabilities an agent can invoke.
A permission model that decides what those capabilities may touch.
An execution system that produces real effects.

Once those pieces separate, the application stops being the natural centre of the customer relationship.

A Small Working Version: Conversion Lab

What does that separation look like inside a working product?

For the OpenAI WebMCP Challenge, we built Conversion Lab, a commerce prototype that tests this architecture. A merchant uses its visual workspace and storefront. Through WebMCP, the same application exposes ten structured capabilities to an agent.

The agent can read verified product facts, audit whether a product is easy for buying agents to understand, create a clearer representation, test it against buyer intent and stage the result for human review. The merchant and agent work on the same application state, each through the interface suited to them.

Conversion Lab demonstrates the first layer of the agent-owned web: the application still holds the data and business logic, while its functionality becomes callable without navigating its screens. The open-source project stops at page-level WebMCP. The next layer is an agent that can preserve the customer’s intent and reuse those capabilities over time.

The Agent Between The Customer And The App

Conversion Lab ends at page-level capabilities. Above them sits a different kind of system: a persistent agent that represents a person or organisation across many services.

This is a question of role, not hosting location. The agent may run on a laptop, a self-hosted server or a computer operated in the cloud. It sits on the customer side because it carries the customer’s goals, memory, preferences, permissions and budgets. It decides which capabilities to use and when to use them.

The website or SaaS product sits on the service side. It supplies data, domain logic and actions through WebMCP, MCP, APIs or other interfaces. A company may also run its own agents for sales, support, fulfilment or optimisation. Those agents represent the service provider. They respond to demand; the customer’s agent brings it.

Several emerging systems show different ways to build that customer-side layer.

Hermes Agent is a self-hosted persistent personal agent with memory, reusable skills, scheduled automation, messaging channels and browser control. OpenClaw similarly gives the user an agent gateway they can run on their own infrastructure, connecting durable sessions, memory, skills, messaging and scheduled work.

Grok Bot occupies the same logical position with a different operating model. Its persistent computer is managed in the cloud. The user creates specialised bots, connects accounts and gives them recurring work; the product hides more of the underlying infrastructure. It still sits on the customer side of the interaction because it carries the user’s context across services.

Pi sits one layer lower. It is a minimal harness for building a customised agent runtime through extensions, skills, prompt templates, session history, RPC and an SDK. Pi omits MCP from its default core, which exposes an important separation: the model, the persistent harness and the protocols used to reach services are independent choices.

The model supplies reasoning. The harness supplies continuity. WebMCP and other interfaces supply access.

CUSTOMER SIDE
Human or organisational goal
              ↓
Persistent agent and harness
memory · skills · schedule · budget
identity · policy · feedback
              ↓
selects and composes capabilities

──────── interaction boundary ────────

SERVICE SIDE
WebMCP · MCP · APIs · CLI · browser
              ↓
SaaS products and web applications
data · domain logic · execution
              ↓
Transactions and real-world effects
              ↺
Results return to the customer’s agent

The browser organised the web around pages. The agent organises software around goals.

From Sessions To Standing Intent

Most digital measurement assumes a session. Someone arrives, views, clicks, converts and leaves. Even complex customer journeys are reconstructed from a sequence of these bounded visits.

A persistent agent weakens that structure.

The user may express an objective once: find a better energy tariff, keep a campaign within its pacing limits, reorder household goods when prices fall, or watch for a suitable flight. The agent can preserve that intent, wake on a schedule, observe changing conditions and act when the user’s rules are satisfied.

Search, evaluation, purchase and service may happen hours or weeks apart without another human prompt. The customer journey becomes an ongoing delegated process.

This changes the commercial meaning of retention. A SaaS company currently tries to bring the user back into its interface. In an agent-owned web, the stronger position may be becoming the trusted capability that the customer’s agent reuses automatically.

The visit matters once. The remembered relationship matters repeatedly.

The Customer Relationship Moves Up The Stack

The remembered relationship sits one layer above the application. The SaaS product may execute the work, but the persistent agent receives the objective, retains the customer’s context, chooses a provider, requests approval and explains the result. The application becomes one capability inside a workflow whose continuity lives elsewhere.

That is what it means for the relationship to move up the stack. Commercial control shifts towards the layer that holds intent and orchestrates demand. The agent can decide which providers enter consideration, when their capabilities are invoked and how their results are presented. The SaaS provider still controls the supply: proprietary data, regulated execution, specialist logic, inventory or real-world fulfilment. Its power increasingly depends on how difficult those capabilities are to replace.

Software economy organised around apps	Software economy organised around agents
Distribution wins an app install or site visit	Distribution wins an agent connection, permission or remembered default
Retention brings the user back into the interface	Retention makes the capability reliable enough for automatic reuse
Pricing follows seats and feature tiers	Pricing may follow usage, completed workflows or verified outcomes
Product analytics measure sessions and clicks	Agent analytics measure discovery, invocation, completion and reuse
Interface and stored workflow create switching cost	Memory, policy and cross-product orchestration create switching cost
The application owns most customer context	The agent may hold the broader customer context

The shift will be uneven. Direct manipulation, visual exploration, shared creative work and specialist judgment still need rich interfaces. In those workflows, the agent may prepare and coordinate while the person works inside the application. The agent can hold the long-term intent even when the app owns the decisive moment.

The strategic risk begins where capabilities are easy to substitute. If the agent remembers the objective and can switch providers, interface habit no longer protects the supplier. Providers with scarce data, authority, expertise, inventory or execution remain harder to replace. The contest is over which layer holds the customer’s continuity and which layer supplies irreducible value.

The New Distribution Battle Is Agent Shelf Space

Our OpenClaw article argued that agents would become gatekeepers. Persistence sharpens that argument.

A search engine ranks options for a query. A persistent agent can remember which option worked. It can retain configuration, learn the failure modes and invoke the same provider directly next time. Discovery turns into installation, permission and habit.

The equivalent of winning a search result may become:

Being installed as a trusted skill
Receiving a persistent connection
Entering an approved capability list
Becoming the default for a recurring task
Demonstrating enough reliability to receive broader authority
Remaining preferred after the agent evaluates the result

This is agent shelf space: a durable place inside the customer’s working repertoire.

The concept already has early technical forms. OpenClaw’s ClawHub distributes skills. Pi packages bundle extensions and skills. IAB Tech Lab has introduced an Agent Registry to make advertising agents and their capabilities discoverable and verifiable. These systems serve different markets, but they point towards a common distribution problem: agents need a way to find, trust and retain capabilities.

That gives brands a new acquisition objective. The goal extends beyond being mentioned or cited. The brand wants to become callable, approved and remembered.

Search Becomes A Subroutine

Search will not vanish. It will lose some of its visibility as a distinct human activity.

An agent can use search at several points inside a longer plan: discover providers, gather evidence, compare claims, check a price, verify a policy or investigate a failed action. One human instruction can therefore produce many machine queries. Once the agent finds a reliable capability, later work may bypass broad discovery and go straight to the known provider.

This creates two different optimisation problems.

The first is initial discovery. Brands still need clear content, credible references, structured product data, accurate availability and machine-readable descriptions.

The second is operational retention. The agent evaluates whether the capability returns current information, respects permissions, handles errors, explains its effects and completes the task reliably.

Traditional SEO competes for a position in the result set. Agent optimisation also competes for a place in memory.

This is close to the thesis behind Parallel. In a Sequoia interview, founder Parag Agrawal argues that agents will query the web far more heavily than people and that an information economy funded by human clicks will struggle under that load. It remains a forecast, but it points to the right mismatch: machine demand can grow without producing a corresponding rise in human attention.

That second contest may be harder to observe. A merchant can see referral traffic from a search engine. It may struggle to know that an agent considered its capability, rejected it because of a vague schema and remembered a competitor instead. The next analytics category will need to connect discovery with invocation, outcome and future reuse.

Advertising Meets A Principal-Agent Problem

Agentic advertising is developing in two directions.

In the first, advertisers use agents to plan, buy and optimise media. IAB Tech Lab’s Agentic Advertising Management Protocols now include buyer and seller reference agents, shared advertising schemas and an agent registry. This is the supply side of agentic marketing: agents operating the machinery of advertising.

In the second, advertisers try to influence the agents acting for consumers and businesses. This is more difficult because the agent has a duty—formal or implied—to pursue its principal’s goal.

Suppose a shopping agent recommends a sponsored product. Did the product best satisfy the customer’s constraints? Did the seller pay for placement? Did a commercial connection become a remembered default? Did the agent disclose the incentive to the human?

Human advertising has developed visual conventions for sponsorship. Agent recommendations will need machine-readable equivalents:

Explicit sponsorship status
The source and value of any commercial incentive
Separation between utility ranking and paid placement
User policies governing whether sponsored options are permitted
A reviewable explanation of why the agent selected the recommendation

The central measurement question changes from “Did the person click?” to “Why did the agent choose this?”

An agent that optimises for its user may filter much of the ambient persuasion on which digital advertising depends. Advertising will not disappear; it will have to negotiate with a proxy that remembers incentives and can compare the promise with the outcome.

Ecommerce Breaks Into Capabilities

Ecommerce makes the structural change easier to see because its actions are concrete.

Google’s open-source Universal Commerce Protocol models the commerce journey as modular capabilities covering discovery, checkout and order management. It supports several transports, including APIs, MCP and agent-to-agent connections. WebMCP can expose actions on the live merchant page. An agent can use either route depending on whether the human is inspecting the experience or delegating the outcome.

A persistent shopping agent can remember size, budget, dietary restrictions, loyalty accounts, delivery preferences, return history and previous disappointment. It can then assemble a journey from several providers:

discovery → comparison → negotiation → checkout → fulfilment → service

Each stage can come from a different capability. One provider supplies trusted reviews. Another searches stock. A merchant handles the transaction. A payment provider verifies the payment. A delivery service fulfils it. The agent presents one coherent experience over the top.

This puts pressure on the retailer’s traditional control of the funnel. The retailer’s defensible assets become clearer: exclusive inventory, accurate data, price, fulfilment, service, loyalty value and reliable execution.

Brand still matters because humans supply the values the agent is meant to serve. Its role changes. Brand becomes part of the agent’s decision policy—trusted, avoided, preferred, acceptable at a premium—rather than only an impression designed to trigger a click.

The Agency Becomes A Governed Agent System

For agencies, the largest opportunity sits above isolated automation.

An agency can build a persistent marketing agent for an account: one that knows the commercial objective, approved channels, historical experiments, client terminology, margin model, budget constraints and escalation policy. Specialist agents can handle search, retail media, programmatic, creative analysis and measurement while the account agent maintains the whole picture.

The agency’s product then includes:

Tested marketing skills and operating procedures
Reliable capability integrations
Client-specific memory and context
Decision policies and approval boundaries
Evaluation of recommendations and completed effects
Exception handling and incident response
Audit trails that explain what changed and why

This changes the economics of agency work. Value moves away from the number of people available to operate platform interfaces. It moves towards the quality of the system: what it knows, what it can do, when it refuses, how it learns and whether the client can trust the outcome.

The risks rise with the value. Cross-client memory leakage, reused credentials, stale approval, duplicated transactions and silent partial failure become agency governance problems. Tenant isolation cannot live in a prompt. Budget authority cannot be inferred from a previous conversation. A successful API call cannot prove that the business objective was met.

The agency that builds this well will sell more than efficiency. It will sell governed continuity.

An Agent Request Is Not Customer Permission

For a brand, SaaS provider or agency, the authority problem begins when an agent invokes a capability. It may ask to publish a price, issue a refund, move campaign budget or place an order. The request may express the customer’s intent accurately. The service still has to establish whether this caller may create that effect now.

Persistent memory makes the distinction harder. An agent may remember that a customer approved a budget move last month. That approval may have expired or applied to a different campaign, amount or market. A confident request carrying rich context remains a request.

The service owns the verification boundary. Before producing a consequential effect, it should authenticate the customer and the delegated actor, resolve the exact account or object, load its current state and check the requested action against current permissions, limits and expiry. Material judgment or an irreversible action may require human approval bound to that specific effect.

Agent requests an outcome
      ↓
Service authenticates the customer and delegation
      ↓
Service resolves the target and current state
      ↓
Policy checks action, scope, limit and expiry
      ↓
Human or standing rule authorises the exact effect
      ↓
Service executes the capability safely
      ↓
Receipt and current state return for reconciliation

For a commerce brand, this means allowing broad access to accurate product and policy information while binding purchases, refunds and subscription changes to current customer authority. For a SaaS team, it means separating read, draft, stage and publish capabilities, then enforcing permissions in the application backend. For an agency, it means encoding the client mandate by account, campaign, market, budget and time—and keeping those controls outside the agent’s prompt and memory.

The service should return evidence as carefully as it checks permission: what changed, which authority allowed it, what it cost, what failed and what the current state is. Autonomy becomes commercially useful when the provider can prove why an action was allowed and what actually happened.

What Businesses Should Build Now

The agent-owned web is early enough to reward experiments and mature enough to demand controls. A useful readiness programme starts with one bounded customer outcome rather than a catalogue of speculative tools.

For SaaS Product Teams

Map outcomes, then capabilities. Identify what customers repeatedly try to achieve and which bounded operations the product can expose safely.
Design two coherent interfaces. Preserve the visual product for exploration, review and exception handling. Add an agent interface for structured actions.
Separate discovery from permission. An agent may learn that a capability exists without receiving authority to invoke it.
Describe effects precisely. State what each operation reads, changes, costs and returns. Define partial failure, cancellation and retry behaviour.
Make writes safe to repeat. Use idempotency keys, transaction boundaries or compensation for purchases, messages, campaign changes and other consequential actions.
Return evidence. Give the agent a structured result it can verify rather than a generic success message.
Test more than WebMCP. Evaluate the workflow through a live page, persistent MCP connection, direct API and browser fallback where relevant.
Explore capability pricing. Model what happens if customers pay for invocations, completed workflows or outcomes instead of seats.

For Marketing And Commerce Teams

Audit agent discoverability. Check whether product facts, availability, terms, prices and policies are current and retrievable.
Measure the capability funnel. Track discovery, permission, invocation, completion, failure, human correction and repeat use.
Treat reliability as brand behaviour. Slow, ambiguous or misleading capabilities teach the agent to prefer someone else.
Prepare for incentive disclosure. Make sponsorship and commercial relationships explicit enough for agents and humans to inspect.
Protect the human decision. Identify where an agent may optimise automatically and where taste, risk or value requires human judgment.

For Agencies

Build one governed account agent. Start with read-only monitoring and recommendation before enabling platform changes.
Encode expertise as skills. Turn recurring analysis and operating procedures into reviewable, versioned assets.
Bind authority outside the model. Keep tenant identity, budget limits, credentials and approvals in deterministic controls.
Evaluate end-to-end outcomes. Measure whether the campaign, customer or business objective improved—not only whether the tool call succeeded.
Design for exceptions. Define who receives an escalation, what evidence they see and how work resumes after correction.

When The Customer Returns Through The Agent

Return to the head of growth from Monday morning. She still has not opened the individual applications.

On Thursday, her agent reports that acquisition cost rose after mobile checkout completion fell following a release. It does not move media budget; that would optimise around a product failure and hide the cause. Instead, it uses analytics and commerce capabilities to isolate the affected journeys and prepare a rollback. The commerce service verifies the target and current authority. A human approves the exact change. The agent watches the recovery and updates Friday’s launch plan.

The outcome depends on several products, yet no single product owns the task. The agent holds the objective, context, memory and explanation. The applications supply validated data, specialist logic and execution. Policy determines what may happen. A person retains authority over the consequential decision.

This is the larger meaning of WebMCP. It gives a live application a structured way to participate in a workflow assembled elsewhere. Pages remain valuable for exploration, judgment and review. The same product can also supply callable capabilities when the customer delegates an outcome.

The web will still contain applications, search results, ads and checkout flows. Their commercial position changes. They become less often the destination and more often a capability inside a longer process owned by the customer’s agent.

When the customer stops opening your app, the relationship has not vanished. It has moved to the layer that carries the customer’s intent. A business keeps its place by becoming a capability the agent can discover, trust and choose again.

Reference Reading

The shift from applications to capabilities

WebMCP and agent-accessible applications

Persistent agent systems

Commerce and advertising