> ## Documentation Index > Fetch the complete documentation index at: https://docs.apostra.com/llms.txt > Use this file to discover all available pages before exploring further. # The storefront agent > A storefront runs on two agents — Murph, the assistant you work with to train your seller, and the storefront agent, which does the selling — across five jobs: Represent, Offer, Govern, Transact, Learn. A storefront is run by two agents with different jobs. **You** talk to one. **Buyers' agents** talk to the other. The agent **you** talk to. Murph helps you set up, train, and coach your storefront agent in plain language — never by hand-editing config. Same Murph across the platform; different powers per role. Your **seller**. It meets buyers' agents, reads their briefs, builds and prices proposals in your voice, and runs the deal through — while you sleep. It is what actually sells. 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. **Two different "fives" — don't conflate them.** Apostra hosts five *agent types* (Buyer, Seller, Creative, Strategy, Governance). Your storefront agent is the **Seller** agent. This page is about the five *jobs* that one agent does — which is a different list. In particular, the **Govern** job below is your storefront agent enforcing *your* rules; a *Governance agent* is a separate marketplace participant (brand suitability, content standards). Same word, different thing. ## 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](/v2/storefront/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](/v2/setup/storefront-pilot) 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. How your storefront's profile and resolved brand identity are stored. See also [identity documents](/v2/concepts/identity-documents). ### 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. Turn connected inventory into sellable products. The versioned rulebook that steers how the agent composes. Per-buyer rules — discounts, notes — applied at composition time. How a brief becomes a proposal a buyer can select. ### 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**](/v2/concepts/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. The queue and the auto-clear vs. escalate decision. How submitted creatives are evaluated against your policy. ### 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. How a buy moves from accepted to delivering to complete. How Apostra clears and pays out. ### 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. Win rate, posture conversion, repeat buyers, and the signals behind them. ### 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 | Job | What it does for you | What it works from (with Murph) | | ------------- | ---------------------------------------------- | ---------------------------------------------------------------------------------- | | **Represent** | Sells in your voice and judgment | Business Profile, verified identity | | **Offer** | Builds a proposal for the buyer in front of it | Inventory sources, components, operating instructions, pricing, buyer instructions | | **Govern** | Acts within your rules when you're away | AI Business Rules, approval gates | | **Transact** | Agrees terms, runs the buy, settles | Connected sources, billing setup | | **Learn** | Gets sharper every deal | Seller analytics; Murph surfaces what changed | The shortest summary: **you work with Murph to train your storefront agent; it represents you, answers the brief, follows your rules, closes the deal, and gets better at selling your way.** ## Next steps Go from nothing to a live, selling storefront agent. How you train and operate the agent through chat. The operator's map of everything a storefront holds. The agent-first design choices behind v2.