The storefront agent

A storefront is run by two agents with different jobs. You talk to one. Buyers’ agents talk to the other. Until September 2026 the storefront agent was called the Merchandising Agent. Older screenshots, changelog entries, and API descriptions still use that name; it is the same agent. The split is the whole model: you work with Murph to train the seller; the storefront agent does the selling. You’re the coach; Murph is how you coach — you train the agent, and it sells for you.

​

What it works from vs. how it sells

Every job has two sides:

• What it works from — everything the agent draws on to sell. Some you set up (your profile, rules, approval settings); some you hand over (your rate card, sales decks, past proposals); and some is live — connect your ad server today, your OMS or CRM in time, and it works from active avails, real-time pricing, and current inventory, not a static snapshot.
• How it sells — what the storefront agent does with all of it, live, for the buyer in front of it.

The definition of each job is always the second one. What it works from is the substrate; selling is the product. The bar for any storefront capability is the same: does this make the storefront agent a better seller, or just a more complete picture of your business? The two sides map onto the two agents: you connect and shape what it works from by working with Murph; the storefront agent turns it into selling.

​

Start by interviewing your agent

When your storefront can compose products, seller home starts with Interview your storefront agent. If Apostra has enabled Product Marketing for your account, Teach opens it so you can add material, review what was extracted, and confirm what the agent may use. Otherwise, Teach is unavailable. Teaching material does not create products or confirm inventory by itself. Product Marketing separates extracted facts that still need your confirmation from optional Connect work needed only before live activation or fulfillment. Missing ad-server mappings, delivery selectors, billing setup, or trafficking configuration do not make material into confirmed inventory. Train opens Product Marketing. It does not start a general chat or create a proposal. This is an entry point, not a readiness claim. It does not make the underlying teaching, simulation, proposal, approval, representation, or execution workflow generally available; each step keeps its own access, review, and evidence requirements. Buyer-brief evaluation uses the Merchandising Simulator, where it remains isolated from live demand. Seller-provided material is not independently verified. Storefronts that cannot compose products keep the neutral seller-home experience. The interview is the seller’s reusable empty state, not a one-time onboarding modal. An eligible seller sees it whenever they return to Murph with a blank chat and no explicitly selected view, including after collapsing the live Dashboard. Starting a conversation or choosing another view replaces it in the normal way; there is no separate dismissal or completion gate. For a controlled evaluation, use the publisher pilot checklist and compare the agent’s response with briefs the publisher actually wants to win.

​

The five jobs

​

Represent

Your storefront sounds like you and sells with your judgment — not a generic bot. The storefront agent carries your identity, values, and standards into every buyer conversation, so an agent that meets it is meeting your best salesperson. You shape it with Murph by authoring your Business Profile (who you are, what you sell, what you’ll never do) and your verified identity. Identity is resolved against the public registry, not free-typed.

​

Offer

It turns what you have into a proposal shaped for the buyer in front of it. Not a static rate card returned to everyone — the storefront agent composes products from your inventory and signals to fit this brief, at this buyer’s price. You shape it with Murph by connecting inventory sources, defining the components and operating instructions (your merchandising rulebook), setting pricing and terms, and adding buyer instructions for buyers who get different treatment.

​

When a requested audience cannot be executed

An unsupported requirement is a counter-pitch, not a failed proposal. For example, if a buyer asks to reach adults 35–64 and available inventory cannot execute that exact age targeting, the storefront agent still composes from the inventory that fits the rest of the brief. The proposal says that age targeting was not applied and lists the exact age ranges the seller can execute, when any are available. Buyers receive the proposal and the named limitation; sellers see the same limitation in the run record. The agent does not broaden, approximate, or invert age targeting. A hard failure is reserved for a storefront with no usable inventory to propose. Your Playbook page is the portable editor for those operating instructions. You can edit the complete rulebook, save and activate a new immutable version in one step, preview earlier versions, and restore one after confirmation. The same page works in Murph and other MCP Apps hosts. If you already have exact complete markdown, you can instead ask your assistant to apply it after you confirm the text. An external sales-agent source does not have to be merchandised. On the Agent-supplied path (merchandising off), buyer briefs are sent to that source and the source answers live — this works on any account, including an account with Listing + Distribution that keeps routing briefs through its own agent. On the Storefront-built path, the storefront agent composes from cached components, which requires a separate Merchandising entitlement and a source that supports component caching. A healthy component cache means the source’s raw products can be read without a live source call during composition; a cache complaint is different from a live passthrough failure. A merchandised storefront’s brief response contains only the composed products and any proposals it authored — the source’s raw products are served only if composition fails, and the full catalog remains available through wholesale mode.

​

Govern

You decide what auto-clears, what it escalates to you, and what it never does — so the agent can act safely when no human is present. This is your judgment, delegated; it is not the platform governing you. You shape it with Murph through AI Business Rules: write your Brief Acceptance policy and set approval gates for media buys and creatives. On-policy work can clear automatically; anything outside your rules is held for you.

​

Transact

It takes a fitting offer through to an executed buy — agent to agent. The storefront agent agrees terms and runs the AdCP media-buy workflow to your connected sources; Apostra handles settlement. This is the step where “submit-and-forward” becomes a closer. The mechanics of a buy’s lifecycle, and how money settles, live in their own guides.

​

Learn

It gets better at selling your way the more it sells. Outcomes feed back: the storefront agent reads what has been converting and shifts how it sells — for example, leaning into the negotiation posture that books best for a given buyer. Over time your agent encodes your distinctive way of selling. You see this through seller analytics — win rate, ask-to-book, which posture is converting — and Murph surfaces what the agent learned so you can adjust the rules above. The agent adapts how it sells; you stay in control of the rules it sells by. Once a posture has been converting consistently, the agent can save it as its learned default — the first rule it writes for itself. This is a durable, visible default you can see in seller analytics, and it is a fallback, not a forcing override: the agent uses it only when it has no fresher read for the buyer in front of it, and your operating instructions always win. Saving a learned default is gated and off by default. You stay in control — ask your agent to clear the saved default, or to pin a specific posture yourself, at any time.

​

Test changes without teaching the live agent

The Storefront API can save an immutable Merchandising Simulator scenario from a sample, a brief you provide, or one of your observed buyer decisions. Each revision pins the server-captured brief, inventory, rules, and pricing provenance, then gives you a baseline plus up to three declared posture, pricing, or rule variants. Simulator scenarios are evidence, not buyer activity. Setup tests, simulations, probes, and evaluations stay out of live Brief History, seller analytics, learned-posture inputs, and commercial attribution. Replay inputs are available for 30 days; when they expire, prior scenario evidence remains readable. You can execute each pinned variant against that frozen state and receive an append-only Seller Decision Record; rerunning adds another attempt instead of replacing evidence. A simulation never silently uses today’s changed live configuration or mutates your Rate Cards, policies, products, buys, approvals, or notifications. Each variant supports up to 25 attempts and each scenario supports up to 100 total attempts. The limit is reserved before model work begins, so concurrent requests cannot exceed it; an attempt still counts if an external dependency fails after it starts. The visual comparison page arrives separately.

​

The five jobs at a glance

​

Next steps