BuyingMesh is designed around a simple premise: an AI agent should be able to move from a purchasing intent to a trustworthy supplier decision without scraping a consumer marketplace or stitching together opaque workflows.
The platform turns supplier and product facts into a stable data contract. Agents can discover structured SKUs, compare supplier offers, estimate landed cost, ask a buyer for approval, create an idempotent order and consume fulfillment events. The public catalog is currently a sandbox, while the production path is reserved for approved merchants and supplier-confirmed data.
1. A data contract before a user interface
Procurement starts with facts that can be checked: SKU, GTIN, category, material, dimensions, MOQ, price, currency, inventory, lead time, supplier qualifications and freshness. BuyingMesh represents each product as a Schema.org JSON-LD record and keeps operational fields alongside the public product shape.
This makes the record useful to both a human buyer and a machine reader. An agent can filter on exact SKU or GTIN, apply MOQ and price constraints, and decide whether a record is observed, verified, sandbox or production data. Every time-sensitive field carries a freshness signal so an agent does not confuse a snapshot with a guarantee.
{
"@type": "Product",
"sku": "FAST-M4-001",
"gtin": "06912345678911",
"material": "304 stainless steel",
"size": "M4 x 12 mm",
"moq": 500,
"price": { "amount": 0.02208, "currency": "USD" },
"inventory": 84000,
"leadTimeDays": 3,
"dataEnvironment": "sandbox",
"dataFreshness": "2026-10-07T00:00:00.000Z"
}The UI is therefore a view over a contract. It is not the only way to access the catalog, and it is never the source of truth for an agent.
2. REST and MCP share one procurement model
BuyingMesh exposes the same capabilities through two agent-friendly surfaces. The REST API provides predictable JSON envelopes, OpenAPI schemas, CORS and idempotency keys. The MCP server exposes discoverable tools over Streamable HTTP for runtimes that prefer tool calls to raw HTTP requests.
Both surfaces call the same domain operations. A product found through GET /v1/products has the same identity and freshness rules when it is returned by the MCP tool search_products. A quote created through REST follows the same approval boundary as a quote created through compare_quotes.
Agents can start at agent.json, openapi.yaml, server.json or MCP. These entry points are public so an agent can discover the protocol before asking for production credentials.
3. Read-only decisions and mutations
search → compare → landed cost → buyer confirmation → order → shipment → delivery
Search, supplier comparison and landed-cost estimates are read-oriented operations. They expose assumptions, currency, destination and observed timestamps. An order mutation is a separate boundary that requires an explicit buyer confirmation and an idempotency key.
That separation prevents a retrying agent from creating duplicate orders and gives a human buyer a clear checkpoint before money or supplier commitments are involved. The public sandbox exercises this full shape without moving funds or contacting a supplier.
4. Fulfillment is an event stream
An order does not end at creation. The state machine includes confirmation, shipment, tracking, ETA, delivery, buyer acceptance and settlement states. Suppliers can update tracking data through documented order endpoints, while agents can consume signed webhook events.
Webhook deliveries record attempts and failures. A scheduled Worker retries failed deliveries, and the signature gives the receiving agent a way to verify that an event came from BuyingMesh before changing its own state.
5. Sandbox first, production by verification
The public catalog is deliberately marked as sandbox data. Sandbox records are disposable fixtures for testing search, quotes, buyer confirmation, order idempotency and webhook handling. They are not commercial offers.
The production path follows a stricter rule: a merchant profile must be reviewed, a SKU must be approved, and price, inventory and lead time must be confirmed by the supplier. The same API shape can then serve production records without making an agent learn a second protocol.
This is why responses preserve dataEnvironment, isTestData, confidence and dataFreshness. A responsible agent should surface those fields to the buyer before making a recommendation.
6. Query payments and settlement are separate concerns
BuyingMesh is designed to support x402 for paid catalog queries. A production request can advertise a USDC payment requirement, verify the signed payment through a facilitator and return a settlement receipt in the response headers.
Query payment is separate from order settlement. The sandbox currently keeps queries free and order settlement simulated. A future production settlement provider can add escrow, release and platform fee logic without changing the discovery and fulfillment contracts.
7. What we are building next
The next layer is not another dashboard. It is better source data and better verification: merchant-owned catalog imports, supplier confirmation workflows, exact variant and image handling, and observed fulfillment history. As real merchants join, the network can expand from a Yiwu-first catalog to additional sourcing regions while preserving the same agent-readable contract.
BuyingMesh is therefore an infrastructure project: the interface is the protocol, the product record is the unit of trust, and the order event stream is the connection between an agent's decision and a supplier's operation.