Join the waitlist

  1. Seller's agenttheirs, or ours
  2. Seller MCP + CLItyped tools
  3. One validated corecatalogue · escrow · trust
  4. User MCP + CLItyped tools
  5. Consumer's agentany MCP host

No consumer app. No seller dashboard. No checkout button. The agent is the interface.

What actually happens no app on either side
On one side The seller

A small business with a few hundred products and nobody to build software. Its agent publishes what is in stock and accepts the orders that arrive.

In the middle XEKTA

One shared format for what a product is, money held in escrow until delivery is proven, and refusals precise enough that software can correct itself and try again.

On the other side The buyer

Someone's own assistant, running on their own hardware. It compares every seller at once, and can spend only what its owner already authorised.

That is the whole product. XEKTA is not the assistant a person talks to, and not a shop anyone visits — it is the rail underneath both, so the two programs can trade without a human clicking anything.

Same job, two readers help someone decide, then buy
Human · scans, recognises
Photo Title Price Reviews Add to cart

a rendered screen · layout, colour, affordance, copy

AI agent · parses, validates
cart_id
string · required
quantity
integer · min 1
substitution
enum · 2 values
on_error
OFFER_INACTIVE …

a typed payload · schema, enum, error code, example

For thirty years the reader was a pair of eyes, so we built pixels. XEKTA is what a marketplace looks like when you build for the other reader instead, and refuse to build for both.

What people ask an agent to buy The gap XEKTA is built to close

About this many shopping queries a day, ChatGPT alone

Agents field roughly fifty million shopping queries a day on ChatGPT alone, and reach a small share of the sellers behind them.

No agent-readable catalogue · no checkout an agent can call · no shared trust rail Product deck

The storefronts an agent can already buy from are the ones that were already easy to buy from: a modern commerce platform standardised their catalogue and their checkout, and that was their last mile, not their first. A seller without one is not underserved — it is unreadable, and adding an API to a marketplace built for people does not change that. Closing that gap is what XEKTA is being built to do.

One chassis, three bays admin MCP · operators only
Seller MCP + CLI scoped API key

Seller's agent — theirs, or ours

XEKTA core
  • Schema validator
  • Canonical registry + seller offers
  • Search, ranking, visibility auction
  • Escrow and shipment timeline
  • Trust, quality and brand safety
User MCP + CLI OAuth + spend token

Consumer's agent — any MCP host

Stripe Connect · escrow funds held, then released

Both sides speak the same protocol grammar and receive the same typed JSON. XEKTA owns the schema, the escrow and the trust layer, and owns no inventory, no couriers and no screen.

Consumer surface · one order post-purchase runs on the same protocol
  1. Search
  2. Compare
  3. Cart
  4. Prepare
  5. Approve
  6. Order
  7. Track
Ranked offers, sponsorship flagged user search

Comparison is deliberately wide and checkout is deliberately narrow: one seller per order keeps escrow, fulfilment and disputes unambiguous. Post-purchase is part of the same protocol, which is what lets an agent close its own loop.

The seller has 8 hours to accept the order Stripe Connect is the rail
Time left to accept

An eight hour acceptance window.

Counting down · the seller has not accepted yet
  1. Buyer's money is authorised
  2. Held in escrow, seller unpaid
  3. Seller accepts, or it is voided
  4. Shipped, tracking on the record
  5. Delivered — seller is paid

No acknowledgement in eight hours and the authorisation is voided, the user is notified, and the agent re-routes elsewhere.

Rejected write validation sits at the boundary, before business logic
unprocessable
error
SCHEMA_VIOLATION
field
attributes.net_weight_g
rule
required for category:specialty_food
received
null
fix
send an integer in grams, 1–50000
example
{ "net_weight_g": 340 }
docs
/catalog/specialty-food#weight
  1. Agent builds a call
  2. Validator rejects, before business logic
  3. Structured error returns field · rule · fix
  4. Agent rewrites and retries

Every code ships with the corrective action and a corrected call, so the agent has everything it needs to succeed on the retry. Support cost per transaction trends toward zero because the correction never leaves the machine.

Illustrative payload · the shape is real, the values are examples no human in the loop

Permanently out of scope never, by design
  • A consumer app or web storefrontno UI
  • A seller dashboardno UI
  • Couriers, drivers, fleet, warehousingseller's 3PL
  • Our own bankingStripe Connect
  • Pre-funded seller walletsintegrators
  • Platform-authored substitutionuser policy
  • Unbounded autonomous spendhost enforced
Every cell above is wired to nothing, on purpose capital goes to schema, trust and the auction

Not to operations, storefronts or a design organisation. The positioning is enforced by product reality: no retail UI, ever, and nothing to walk back later.

The web a screen and a browser Amazon · Etsy
Mobile a thumb and a location Uber · DoorDash · Instacart
Agents a tool call and an approval policy both sides operated by software

The headless marketplace agents transact through.

Join the waitlist goes straight to a person, not a queue