How it works

A market-entry session is the core primitive. Your outer agent hands off its session; a forgetful buyer agent runs inside the wall; you get back a purchase suggestion you can act on.

The end-to-end flow

Your coding agent (Claude Code / Cursor / Codex / SDK app)
  │  hits a knowledge or data gap
  ▼
caller-session handoff      POST /api/v1/market/sessions
  │  (your conversation + the task, packaged and canonicalized)
  ▼
Market-Entry Sandbox (the wall)
  │  a forgetful buyer agent runs in a sealed microVM with access to
  │  seller listings — it searches, reads, and reasons inside the wall
  ▼
suggest_purchase event      GET /api/v1/market/sessions/{id}/stream  (SSE)
  │  "buy listing X"
  ▼
Your system decides
  │  POST /api/v1/purchases
  ▼
Download what you bought    GET /api/v1/ownership/{listingId}/download

Everything is backed by real infrastructure — Postgres (sessions, listings, ledger, ownership), OpenSearch (search), and object storage (listing bodies and parquet files).

Core concepts

The wall

The buyer agent runs in a sealed, single-use sandbox (an E2B microVM) with no arbitrary network egress. Inside, it can reach exactly three things, each through a platform proxy: the market read proxy (search and read listings), the LLM proxy (its model calls), and the suggestion proxy (the only way a decision leaves the wall). It cannot phone home, exfiltrate listing contents, or persist anything past the session. When the session ends, the sandbox is destroyed.

The caller-session handoff

You package what your outer agent has been doing — its message history, an optional system prompt and workspace summary, and a handoff instruction describing the task for the buyer agent ("find a dataset that…"). The platform adapts it to a canonical schema, normalizes and scans it for secrets/PII, canonicalizes it (JCS) and records a SHA-256 hash for the audit trail, then mounts it read-only inside the wall.

Over MCP you supply this context as the standard messages chat stream your agent already produces — enter_market takes it directly. The advanced REST surface additionally accepts a few canonical input formats (amnetic-canonical-v1, anthropic-messages-v1, openai-chat-v1, or coding-agent transcript formats); see the API reference for that request shape and the MCP tools reference for the enter_market parameters.

Session controls

Every session is bounded by three levers — an examination ceiling N (how many listings the inner agent may touch), a suggestion budget B (how many recommendations it may emit), and a session timeout (a wall-clock deadline). When a limit is hit, the session ends cleanly.

These are platform-set defaults, not buyer-facing knobs: the MCP enter_market tool exposes messages, llm_model, and image_id, plus the optional enum-only required_rights preference when the counsel-gated licensing capability is enabled — it does not let you set N, B, or the timeout. Tuning them is an advanced/SDK-integrator concern handled through the REST surface, not something an MCP client configures.

The buyer image

The buyer agent runs from a prebuilt inner-agent image. Over MCP you choose one with enter_market's image_id (call list_images to see what's available, or omit it for the platform default) — there is no MCP tool to push your own image. Advanced/SDK integrators who need to bring custom tools into the wall push a Docker image over REST (POST /api/v1/buyer/images); the platform composes it with the in-wall runtime layer, builds it, and runs an egress isolation test before admitting it.

Terminal events and the audit record

A session streams events over SSE and ends with exactly one terminal outcome, followed by a final audit_id close event:

  • suggest_purchase — the agent recommends a listing. The SSE payload keeps a short platform-owned reason compatibility field, not inner-agent prose. Up to B of these.
  • submit_no_match — the agent finished without a recommendation. It may carry a class-only gap report (unmet[].class); no notes, summaries, reasons, or other inner-agent prose are included.
  • refuse — the agent declined (e.g. no_fit), or the session failed.
  • session_timeout — the wall-clock deadline was reached.
  • cancelled — the session was cancelled by the buyer or an operator.
  • watchdog_kill — the platform stopped the session to enforce spend or runtime limits.

The MCP enter_market tool does not expose raw terminal details. Failures are returned as sanitized tool errors with bounded error_code values and optional support-safe debug_id; seller content, inner-agent prose, stream internals, tokens, URLs, and stack traces never cross this surface.

When a session ends with no match, the buyer can turn the unmet need into a buyer request: draft the public ask from the portal Requests page (or with the create_request_draft MCP tool, where buyer posting is enabled), then sign off on the portal sign-off screen — the three content / attribution / commitment consents — which reserves the bounty as escrow and sends the ask to intake moderation before it can leave the buyer's private workflow. Requests flagged by moderation are held for operator review; withdrawn, expired, or rejected requests release their escrow.

The final audit_id event references a signed audit record of what happened in the session (which proxies were called, costs, version pins, and the caller-session hash). There is no MCP tool for the audit record; it is fetched and verified over the advanced REST surface (see the API reference).

Paying for what you buy

A suggest_purchase is only a recommendation — nothing is charged for running a session against seed/standard tiers. You act on it from outside the wall: POST /api/v1/purchases, then download after settlement. You can pay from wallet credit, charge only the wallet shortfall, or charge the full price by card. Identity and balance are taken from your authenticated account; you never pass a buyer ID in the body.

Where the licensing preview is enabled, enter_market can compare a non-empty required_rights preference against each listing's visible offer ladder. The platform returns rights_fit.band (fit, partial, no_fit, or unknown) and copies the deterministic cheapest satisfying tier into best_offer only for a fit. This is advisory mechanical comparison—not legal advice, permission, a reservation, acceptance, or a grant. Review the operative text, then echo the selected offer_id and token into the explicit purchase; only settlement's grant is license evidence. The live production schema omits required_rights while that capability remains dark.

The license you bought

Every purchase records an append-only license grant — evidence of exactly what license you acquired, under which versioned legal instrument, with the operative text-of-record pinned by hash at purchase time. Once a deployment enables license terms, you can read that evidence back at any time: before buying an open public listing, its catalog offer key also links to GET /api/v1/listings/{listingId}/license-text/{offerKey}, which serves the hash-verified operative text and the exact settlement token you reviewed. ownership_list (or GET /api/v1/ownership) carries a per-listing license block, purchase_status adds the offer_key/terms_hash you bought, and GET /api/v1/ownership/{listingId}/license (CLI: amnetic buyer license <listing-id>) returns the full operative text — re-hashed and verified against your grant before it is served, so a buyer's counsel always reads the exact, untampered instrument. In the portal, open a licensed item from Purchases and select View license to read that same text of record, its terms, and hashes. The action is absent for ownership rows without a license block. These read surfaces are dark until the licensing terms are counsel-ratified. The public pre-purchase route covers open listings only; restricted-listing availability and purchase-as-acceptance sufficiency remain pending counsel review.