Intelligence runs

​

Overview

An intelligence run is the record the Merchandising Agent writes each time it answers a buyer’s get_products request for your storefront. Each run captures the inputs (buyer scope, brief, matched buyer instructions), the prompt and raw + parsed model output, the products it composed, and a result envelope. Runs are the per-request detail behind your seller analytics — analytics aggregate runs; runs show you exactly what happened on one request. Use intelligence runs to audit how the engine responded, debug an unexpected composition, and label runs for evaluation workflows.

​

Reading a run

The run record groups the durable evidence into four blocks so you can scan a decision from request to result. What the buyer asked records the brief, advertiser/brand, buying operator (including an agency or DSP), buyer account when it was captured, buying mode, and any budget or negotiation asks. Missing identity is shown as not recorded for that run: the view never substitutes a current customer, CRM, or source-native account. What we responded records the products and price range sent, the selected posture, the signals and guidance used, and anything withheld. Outcome records approval and the result — submitted, forwarded, rejected, or delivered — including attributed spend where it was recorded. Our read records the posture rationale, recommended versus selected posture, matched guidance, and learning evidence. Shaped by records the endorsed pair the agent followed and its reason, or states that no endorsed pair fit. Library slides appear as response blocks with their Library source named, so the run shows which material shaped the response as well as what the agent wrote.

​

Test a starter brief

The Storefront Briefs page is the only visible place to start a storefront brief test. Select Run brief to call your storefront with that brief and see the result, matched products, and any retry state beside the starter. The test is read-only, works while the storefront is still configuring, and stores an intelligence run so you can select Review decision to inspect exactly how the storefront reached its answer. Historical Test Runs links remain available during the rollback window for reading older records. They cannot start a new run. A failed or stalled record still offers Fix this run so you can recover the exact recorded failure. If you provide Murph with your own exact brief, Murph can run the same typed test directly. Both paths use the shared MCP tool contract, so the workflow is also available in other compatible hosts without copying a generated prompt into chat.

​

A test buys nothing

Running a starter brief is a preview of your agent’s answer, not a transaction. It does not create a media buy, does not create or send a proposal, does not commit or reserve any inventory, does not turn on transacting, does not persist composed products as bookable, and never contacts a buyer. The only thing it creates is the intelligence run itself — the record you open with Review decision. Nothing needs to be undone afterwards, and running the same brief repeatedly is safe.

​

”Nothing matched” is an answer, not a failure

A test that returns no products usually means your agent did answer and decided this storefront had nothing to offer for that brief — because no composition fit it, because there was no inventory to package against it, or because your acceptance policy or operating instructions declined it. That is your storefront working as configured, and the run is recorded with the reason so you can read it. Broadening the brief (other channels, formats, flight dates, or budget) or adding inventory changes the answer; nothing is broken. A run that could not reach an answer is reported differently and explicitly: the result says the run did not finish rather than reporting that nothing matched, and offers a retry. The distinction matters — the first outcome is feedback about your inventory and rules, and the second is a failure to retry. Integrations can draw the same line from the record, but the signal lives in two different places depending on when the request failed. Once composition has run, the recorded run tells you. result.kind is ok, error, or skipped, and result.code refines it:

​

Run-detail resolution and recovery

The run-detail record projects the persisted result envelope into one explicit resolution: offer, no_match, declined, failure, stalled, or unavailable. no_match is neutral; it is used only for the persisted no_compositions, age_targeting_unavailable, and buyer_price_ceiling_unsatisfied results. no_ingredients is an integration failure: the storefront had no inventory bundles to compose, so the Seller must correct the affected inventory-source configuration before retrying. unavailable covers intentional non-composition paths (not_live and llm_skipped); stalled means an unclassified skipped row has no recorded terminal-answer evidence, so the page does not claim either a buyer response or a no-match. For failure and stalled, the record supplies a safe failure object with the persisted code, category (llm, system, or integration), what stopped, why, and one seller action: retry or correct_configuration. The UI does not surface raw provider/model diagnostics. An integration configuration action is limited to the Seller’s own inventory-source setup; it never asks the Seller to alter buyer identity or authorization. The full intelligence-run projection reports the same safe inventory failure in explanation.failure, including its integration type and correct_configuration seller action. This keeps API consumers from reading an empty inventory configuration as a neutral no-match. Buyer identity in the detail record is likewise immutable and seller-scoped: the captured request supplies advertiser (brand.domain then account.brand.domain), buying operator/agency (account.operator), and the opaque buyer account (account.account_id). For historical records without a brief artifact, only the compose-run’s canonical brand/operator snapshot is a fallback. The account remains absent rather than guessed, and the system never joins current CRM, customer, or source-native mappings into this view. If the request failed BEFORE composition, there is no intelligence run to read — and the three groups that can happen report themselves differently:

1. Rejected credentials, or an unavailable service or inventory source. The request returns an AdCP error envelope, which the test_storefront_brief tool surfaces as result.adcpCode (AUTH_REQUIRED, SERVICE_UNAVAILABLE).
2. An adapter-routed storefront. The tool returns result.kind error with code adapter_preview_not_supported and no envelope, because adapter brief evaluation needs provider credentials and must be tested through an authenticated buyer/provider flow.
3. A paused storefront, or one with no supported settlement currency. These return a successful, empty catalog — no error envelope, no error code, zero products — so the only signal is the response summary text (for example This storefront is paused by the seller.). Two sibling replies read the same way but reach only real buyer get_products calls, never the starter-brief test: the not-admitted-to-transact reply is skipped for preview requests, and the “this storefront transacts in …” reply needs a filters.pricing_currencies value the test never sends.

The Storefront Briefs page tells you a run did not finish for groups 1 and 2 and for the composition failures in the table above (llm_unavailable, llm_failure, invalid_output) — in every one of those cases the honest reading is “retry”, not “nothing matched”. Group 3 is neither a failure nor a no-match: the page reads the summary and says your storefront’s configuration prevented the test from composing, so you change a setting rather than your inventory.

​

Run record fields

​

explanation

Each selectedProducts[].pricing is { baseCpm, currency, operatorDiscount, finalCpm }.

​

negotiationSummary.qualification

Present on brief-mode runs once the brief-qualification gate has run — the cheap classifier that decides whether the storefront should respond to a brief before composing. The gate weighs inventory fit and the storefront’s acceptance policy, fails open on any fault (composes), and records its verdict here on every brief. A storefront with an acceptance policy enforces declined_policy automatically; declined_fit is enforced only when fit-enforcement is enabled platform-wide. Until then a fit decline records would_decline: true with disposition: "responded" (shadow). Filter your demand inbox with ?disposition=.

​

Tasks

​

Related