The Merchandising Agent

A storefront is run by two agents with different jobs. You talk to one. Buyers’ agents talk to the other. The split is the whole model: you work with Murph to train the seller; the Merchandising 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 Merchandising 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 Merchandising 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 Merchandising Agent turns it into selling.

​

The five jobs

​

Represent

Your storefront sounds like you and sells with your judgment — not a generic bot. The Merchandising 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 Merchandising 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. 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. If merchandising is off, the storefront runs passthrough: buyer briefs are sent to that source and the source answers live. If merchandising is on, the Merchandising Agent composes from cached components. 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 by writing your acceptance policy and setting approval gates for media buys and creatives. On-policy work can clear automatically; anything outside your rules is held for you. As it watches your own approval decisions, the agent also starts to surface what it’s learning about your governance — for example, flagging a buyer whose media buys have consistently cleared your review and recommending you opt them into per-buyer auto-approve. You see these as suggestions in seller analytics; the agent never changes an approval gate on its own — it recommends and you decide.

​

Transact

It takes a fitting offer through to an executed buy — agent to agent. The Merchandising Agent agrees terms and runs the AdCP media-buy workflow to your connected sources; the Interchange 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 Merchandising 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