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

Apps are not about to disappear. But they may stop being the place where every customer task begins and ends.

A persistent agent can carry an objective across services, request the capabilities each service provides, and return with a result. The customer may still open an app to inspect a complex choice, correct an error, or approve an action. What may change is where the task’s context lives and which layer coordinates what happens next. “Agent-owned” describes that orchestration role here. It does not mean ownership of the person, their data, or every commercial relationship involved.

That possibility creates a practical question for businesses: if an agent carries the customer’s goal between products, what makes your product worth finding, trusting, and using again? The answer is not simply “add an agent interface.” Access, decision-making, and permission to act are separate problems. A useful strategy has to address all three.

From an application to a capability

Most software is designed around a person using its interface. The interface helps people find functions, inspect information, and decide what to do. An agent changes the route into those functions: instead of navigating screens, it may call a defined operation such as checking stock, comparing campaign performance, or drafting a return.

WebMCP is one emerging way for a website to expose structured tools to an agent operating in the browser. It can give the agent a declared action instead of making it infer controls from page appearance. That can make a task more reliable, but it does not tell the agent which action serves the customer, whether the customer has authorised it, or whether the result achieved the intended outcome. Those decisions belong to the surrounding system and the service that performs the action. Chrome’s WebMCP documentation describes the browser-facing interface and its tool model.

This is why an app can keep its value while losing some control over the customer relationship. It may still supply the data, specialist rules, inventory, and execution. Another system may carry the customer’s context, select the provider, and decide when to call its functions. The interface remains useful, but it is no longer the only route to the product.

A product with two ways in

Lovable CTO Fabian Hedin describes exposing selected functions of a published application through a hosted MCP server, alongside its human interface. The application remains responsible for the useful capability; an agent can request it without opening the same screens a person would use. His broader “company brain” direction joins organisational context to capabilities and includes resuming work later, such as a scheduled check on a deployment. Hedin’s interview with Latent Space describes this product account and direction.

Lovable’s app-user connectors show a related but distinct change: a published app can let each user connect their own third-party account, with access based on the permissions granted to that user. That is about connecting user data to an app; it is not the same thing as exposing every app function as a callable capability. Keeping these mechanisms distinct matters because “agent-ready” can describe several different technical arrangements. Lovable’s connector announcement explains the per-user connection model.

The product model is easier to reason about when its parts are named:

Human interface: a place to explore, inspect, make nuanced judgments, and handle exceptions.
Callable capabilities: operations an agent can request through WebMCP, MCP, an API, or another interface.
Authority controls: rules that establish who may request which action, on what object, within what limits and time period.
Execution and evidence: the service that changes state and returns a record of what happened.

These parts can live in one product or span several systems. They should not be collapsed into a single promise of autonomy.

What our Conversion Lab prototype shows

For the OpenAI WebMCP Challenge, we built Conversion Lab, a commerce prototype with a visual merchant workspace and storefront. Its repository documents ten page-scoped tools: they read product evidence, create a draft, run deterministic buyer-task checks, stage review, and support bounded demo operations.

The useful design point is that the person and agent work on the same application state through different interfaces. The checks evaluate declared tasks in the demo; they do not measure actual shopper conversion. Publishing is limited to the demo storefront, and the advertising package is an export rather than an external campaign launch. The credential-free review gesture also does not establish authenticated merchant authority for production writes.

This example stops at page-level capabilities. A persistent agent that carries an objective across services is a further layer, requiring its own state, scheduling, permissions, and evaluation. A working tool surface is one component of that system.

Access, continuity, and permission have different jobs

WebMCP and similar interfaces give an agent a structured route to a service’s functions. A model helps interpret the task. The surrounding runtime keeps the work in progress: its state, relevant memory, procedures, schedules, and results. Access to a tool does not supply that continuity by itself.

The customer-side agent carries a person’s or organisation’s goal. A service-side agent carries the provider’s role and operates within its rules. That distinction concerns whose interests and authority it represents, rather than whether it runs on a laptop, a private server, or a managed cloud computer. Self-hosting alone does not establish alignment with the customer.

A remembered objective is also different from current permission. A service receiving a request must verify the caller and delegation, exact target, operation, limits, and expiry before producing an effect. Reads, internal drafts, reservations, purchases, and publication have different consequences. The Commerce Readiness Stack develops the effect classes, approval, retry, receipt, and state-verification requirements.

From sessions to a continuing task

A session records a visit. A delegated task can remain open after the person leaves. “Find a better energy tariff before renewal” may require an initial comparison, later price checks, a question about a missing preference, and approval before switching. The same goal spans several visits or no new human visit at all.

The agent would need to retain the stated objective, constraints, evidence already checked, pending decisions, and what may happen next. It must also notice changed prices and expired authority. Keeping a goal active for a month does not make a month-old quote or approval current.

For a software provider, this changes the meaning of retention. The person may use the interface less while the agent continues calling a valuable capability. Conversely, an app can receive many visits without retaining a place in the customer’s delegated work. Measure direct use and agent-mediated use separately, then ask whether either helps complete the task.

Continuity can also make dependence move. Configuration, task history, preferences, and policy may accumulate with the orchestration service rather than with an individual supplier. That service could make switching suppliers easier while becoming harder to replace itself. Portability of the customer’s state and permissions becomes a commercial question, not merely a file-export feature.

The Meta Connect comparison applies that question to competing platforms: merchants may join several agent networks while customers favour the one that carries their continuing tasks. That possible imbalance gives the platform a source of bargaining power even when its inventory is not exclusive.

What may move up the stack

If a persistent agent carries a customer’s context across products, some commercial advantages may shift from the application interface to the system that holds that context. This is a hypothesis about how products and distribution could develop, not a settled forecast.

Today’s app-centred emphasis	Possible agent-mediated emphasis
Bring the customer back to the interface	Become a capability the agent can reliably reuse
Measure visits, clicks, and sessions	Measure discovery, permission, invocation, completion, correction, and reuse
Retain users through interface habits and stored workflows	Retain a place through reliable execution, valuable data, and trusted results
Acquire a visit or app installation	Earn an approved connection or a remembered role in a recurring task
Price by seats and feature tiers	Explore usage, workflow, or outcome pricing where the value and costs can be verified
Accumulate workflow state inside one product	Accumulate context, configuration, and policy across products at the orchestration layer

The shift would be uneven. Visual exploration, shared creative work, and specialist judgment still benefit from rich interfaces. Some tasks will be delegated end to end; others will move between agent preparation and human review. The question for a provider is not whether every user will stop opening its app, but which parts of the customer’s work can be usefully separated from the interface.

The supplier may also retain meaningful power. Exclusive inventory, accurate data, regulated authority, specialist logic, fulfilment, and dependable service can be difficult to replace. A customer-side agent may coordinate demand, while a product remains essential to supply. Continuity and supply are different sources of influence. A merchant may still hold the order, fulfilment duty, and customer-service relationship while an agent chooses when to return to that merchant. “Who owns the customer?” hides these separate roles. Ask instead who controls selection, records, support, and the next interaction.

How might capability pricing work?

A seat is a convenient unit when a person repeatedly enters an application. If a capability is mostly used through another system, the supplier may consider charging per invocation, per completed workflow, or for a verified result. These are design options rather than a forecast that subscriptions will disappear.

Each creates a different contract. Per-call pricing needs to explain failed calls, retries, and repeated reads. Workflow pricing needs a boundary for what starts and ends the job. Outcome pricing needs agreement about what counts as success and which party can verify it; a returned API response is usually too weak a definition.

The supplier still pays for computation, data, support, exceptions, and sometimes fulfilment. The customer still needs to know the likely cost before authorising repeated work. A useful pilot can compare the economics of direct use and agent-mediated use while keeping spending limits, disputed outcomes, and cancellation visible.

Discovery could become a lasting place in the workflow

Search remains useful for discovering providers, checking evidence, comparing claims, and investigating failures. But if an agent repeatedly uses a capability that works, later tasks may start with that known provider instead of a fresh search. Initial discovery and continued selection become different problems. One delegated instruction may generate many machine queries while producing few human page views. A referral report would capture only part of that work; invocation, completion, correction, and repeat use reveal another part.

For a business, this suggests two questions. Can an agent find and understand the offer? And, after a permitted use, does the capability provide accurate information, respect limits, recover from errors, and return verifiable results? Clear product data and accurate policies help with the first. Reliability, permissions, and evidence matter to both.

Some of this is already being formalised in specific sectors. IAB Tech Lab’s Agentic Advertising Management Protocols include work on advertising agents and an agent registry, aimed at making agents and their capabilities discoverable in that ecosystem. That is an industry standards effort; it does not show that consumer agents already rank or select brands in a universal “agent shelf.” IAB Tech Lab’s current AAMP overview describes the initiative.

The phrase agent shelf space can be useful as shorthand for a capability’s durable place in a customer’s authorised working repertoire: an approved connection, an available skill, or a remembered provider for a recurring task. Availability in that repertoire does not establish actual use. This is a distribution metaphor, distinct from the proposed Agent Share of Choice evaluation framework. Businesses should first measure what they can observe: referrals, connections, invocations, successful completion, human correction, and repeat use. They should avoid treating an unobserved agent impression as equivalent to a search impression or a sale.

The marketing consequences depend on the role

Advertising has to account for the agent’s principal

In conventional digital advertising, a person sees the message and decides whether to act. With an agent in the decision path, the agent may filter, compare, or explain offers on the person’s behalf. If a recommendation is sponsored, the agent and the person need to be able to inspect that incentive and distinguish it from a utility-based ranking.

The relevant questions become: who paid, what did the payment influence, what rule allowed the recommendation, and how was that disclosed? Advertising may persist, but a system acting for a customer creates a principal-agent problem: the service provider wants to promote an offer, while the customer’s agent is expected to pursue the customer’s stated interests.

The capability should expose enough for both agent and person to inspect the incentive:

Whether an option is sponsored and who benefits from that arrangement.
Whether payment affected eligibility, ordering, a recommendation, or only a separate placement.
What evidence supports suitability and which alternatives were excluded.
Whether the customer’s current policy permits sponsored options in this task.

These are proposed disclosure requirements, not a claim that every protocol already supplies the fields. A provider should not silently turn a sponsored trial into a remembered default. The Answer Independence Paradox examines funding and ranking incentives in more detail.

Commerce becomes a sequence of services

Commerce makes the capability model concrete. Google’s Universal Commerce Protocol describes a modular way to connect stages such as product discovery, checkout, and order management, with multiple integration paths. A shopping task can already span a merchant, a payment service, and a delivery provider; agent-mediated flows make that composition more explicit.

The retailer’s opportunity is to be the most useful and dependable source for something the agent cannot easily substitute: accurate availability, distinctive products, fair terms, fulfilment, or service that resolves a problem. Brand still matters, but it may influence a decision through trust, preference, and past experience as well as through an advertisement that earns a click.

Agencies can sell governed continuity

An agency could assemble an account-level system that retains client objectives, approved channels, prior experiments, budget limits, and escalation rules. Specialist tools or agents might support search, retail media, creative analysis, and measurement. The value would come from how those parts work together and remain accountable, not merely from automating platform operations.

That proposition carries operational risks. Cross-client memory leakage, stale approvals, shared credentials, duplicate transactions, and silent partial failure need controls in the system itself. Tenant identity, budget limits, and approval state cannot safely live only in a prompt or in the agent’s memory. The OpenClaw marketing-agent guide covers a related implementation path, while this article considers the broader customer and distribution question.

Start with one bounded customer outcome

Choose a recurring customer task and map which information, capability, and decision each party supplies. A campaign-monitoring task, for example, needs more than a rule to reduce spend when acquisition cost rises.

If a checkout release reduces completion, an agent pursuing the overall objective should investigate the failure before treating it as weak demand. It could assemble evidence from analytics and commerce records, propose a repair or escalation, and request approval for a specific change. A budget-only optimisation might hide the product problem by sending less traffic. After any approved repair, the team still needs to check whether customer completion recovered. This is a design walkthrough, not a reported experiment.

The business pilot should answer five questions:

Which recurring outcome would justify delegating part of the work?
Which narrow capability can the product expose, and through which appropriate interface?
What current authority and cost limit does the service need to verify?
What evidence distinguishes a returned call, a completed task, and a result worth repeating?
Why should the customer or agent choose this supplier again, and can they leave with their records?

The Readiness Stack supplies the implementation checks. The OpenClaw guide gives a related operating example. Here the strategic test is whether delegated use creates a valuable recurring relationship, even when it creates fewer visits.

What deserves a continuing place?

The product may remain essential because it supplies accurate data, specialist judgement, inventory, fulfilment, or dependable execution. The agent’s continuing role is to connect those contributions to a customer’s task. Either side can hold influence; neither should be described as owning the entire relationship.

The useful decision for a business is therefore which capability should become callable, why it deserves repeat selection, and what the customer can inspect or correct. A continuing objective can connect many services while each service remains accountable for its own claims and effects.

Making that capability understandable and safe to use is the next practical problem. The Agentic Commerce Readiness Stack follows a merchant from product evidence to controlled action. Whether the resulting position can resist imitation is a separate question for Distribution Alone Is Not a Moat.

Reference Reading

Capabilities and WebMCP

Agent systems

Commerce and advertising

Publication history

Originally published by Performics Labs.