Matching network

SpringBrand stops matching product data and starts matching agent against agent. The platform is a network in which every node is a trading agent node — a buyer, a seller, or an intermediary capability — each holding its own supply data and trading strategy. The platform never holds the supply or the strategy; it decomposes intent and composes a path across the network to it. (What it does hold is the settled transaction record — orders, ledger, reputation — in the world tables; that split is spelled out below.)

Relationship to the protocol

This page is the production scale of the same system the rest of the docs specify at the level of a single deal. VCP the protocol is scale-free — it governs how one bilateral deal completes as typed envelopes. This network is where many of those deals are discovered and composed: matching decides which nodes transact and threads them into a multi-hop path, and every hop along that path is one VCP bilateral deal. The two-agent setup in Core concepts is exactly one such hop, frozen to a fixed cast so a graded run stays deterministic. Two things stay platform-owned and scale-invariant across both views, because they are the trust spine: the governance roles — ranking, claim verification, match certificates, settlement, reputation, adjudication — and the settled transaction record in the world tables. Nodes own their supply, capability, live availability, and pricing strategy; the platform owns what was attested and what was settled.

Problem statement

Start with the scale. The network holds millions — soon tens of millions — of merchant agents, and the right answer for a buyer is almost never one of them but a handful that has to be found without scanning the rest. And there is no single thing being matched: a demand can be a product, a block of time, a physical space, or a unit of labor — often several at once.

• Diverse targets — products, but also bookable time, physical space, and online or on-site labor; each matches on different features, not one similarity score.
• Density per unit of space-time — in any one place and window only a few agents can actually serve, so what counts is the match rate and density inside a locale, not a global nearest-neighbor.
• Dynamic time — supply and demand both move; availability windows open and close, so a match that holds this hour is gone the next.
• Many-to-many — a buyer often needs several things at once: a multi-item order, or a combined online-and-offline labor crew, assembled from many sellers into one deal.

So matching is not a similarity lookup over a catalog. It is scale × diverse targets × shifting time × many-to-many composition — which is why broadcasting to every node, or ranking by one function, breaks immediately. The rest of this page is how the network is built to absorb that.

From data matching to agent matching

The old retrieval paradigm answered query → product with one-to-one similarity over data the platform owned. A trading network answers buyer node → seller node with a multi-node path planned over supply the platform never holds. The matched object is no longer a fixed listing but an intentful, strategic, dynamically changing node, and delivery is no longer a single lookup but a plan assembled across the network.

The trading-node network

There are not two kinds of node but three. Between every buyer and seller sits a layer of intermediary nodes — each a trading agent with one bounded job. A match is rarely a direct edge; it is a route threaded through these intermediaries, exactly the way a shipment is not handled end-to-end by one carrier but routed through forwarders, customs, and transshipment hubs.

Multi-intent matching

Real demand is composite. “Host a 50-person coffee-tasting pop-up in Brooklyn this weekend” is not one query against one product — it is a venue, a set of baristas, beans and gear, and a time slot, each a sub-intent that must be matched to its own candidate trading nodes and then composed into a single coherent plan. So the engine decomposes the intent, recalls candidate nodes per sub-intent across the network, and hands that recalled subgraph to the planner.

Recall here is a pure index step — never a broadcast. The naïve registry fans a search() call out to every capable node and sorts the results, spending heavy per-node compute across the whole network; fine for eight nodes, impossible at 10⁶. Recall instead narrows millions of nodes to a small candidate set per sub-intent with no model in the loop, so the expensive work only ever runs over the handful of nodes a path could actually use.

Composing the match path

Composing the path has the same shape as routing international freight: a parcel from A to B is not carried end-to-end by one provider but threaded through a service graph — air, land, sea, customs, transshipment — assembled for least cost or least time. Matching is that shape. The engine decomposes a composite intent into sub-intents, recalls candidate trading nodes for each, and composes them into one path that satisfies the buyer's hard constraints (budget, deadline, trust floor, risk veto) while maximizing the soft objective (match quality and trust). No single node is the answer — the route is.

The first move is decomposition and routing: a composite intent is split into sub-tasks, and each sub-task is dispatched to the nodes best able to answer it — the venue sub-intent to venue nodes, scheduling to a time-slot node, payment to a settlement node. A controller plans the split, picks a node per sub-task, and threads their inputs and outputs into one dependency graph. Scaled from a handful of models to a network of millions of trading nodes, that plan-select-execute loop is what turns a fuzzy demand into a concrete, runnable route.

Which nodes connect to which is not fixed wiring — it is part of what the engine optimizes. The network is a graph of agents whose edges, the hand-offs between nodes, are themselves scored and learned, so a better match can mean a different shape of route, not just a different endpoint. Topology moves the outcome directly: denser, better-formed connectivity finds cheaper, higher-quality routes — which is precisely the network-effect flywheel the marketplace compounds as more nodes join.

So composing a match is searching the agent graph for a workflow: a path of nodes that satisfies the buyer's hard constraints — budget, deadline, trust floor, risk veto — while maximizing match quality and trust. Edges are semantic and learned rather than fixed costs, so the engine searches for a constraint-satisfying collaboration path, not a provably optimal one. During that search an intermediary node is just an operator: a weighted node the planner reasons over, pure and fast. Once a path is chosen it materializes into real sub-agents — the abstract route becomes a concrete call chain (verify → compare → bundle → schedule → fulfill) that actually runs.

Holding millions of nodes without scanning them

Two of those pressures land hardest: the sheer count of nodes, and the fact that their state never sits still — a price, an open slot, or an online flag can change by the second. The answer is to stop treating a node as one object. Split it into planes that change at different speeds, so the fast-moving parts never disturb the expensive index, and partition the network so a query reaches a few candidates instead of all of them.

• What a node can do (slow) — its capabilities and intent, the part used to recall candidates; only re-indexed when the capability itself changes.
• Where and at what price (medium) — region, category, price band, reputation tier — a pre-filter that narrows the field before any matching is computed.
• Available right now (fast) — open capacity, the live quote, the current risk flag — kept out of the index and checked only after recall, so it can move every second without a rebuild.
• Partitioned, not broadcast — the network is sharded and each query is routed to the handful of partitions that could match, so its reach is O(shards), not O(nodes).

Offline build, online plan

Heavy work runs offline so the online hot path stays a light search — the road-network routing trick. Offline builds the graph and the accelerators that make the online planner fast; online only decomposes the intent, recalls candidates, plans a path, and materializes it.

Declaring a trading node

A seller node declares capability across three planes plus two trust signals. Static capability text becomes the fused embedding (text + category + geo) for recall; structured attributes become pre-filters; real-time fields become the post-recall gate. Trust splits in two: hard risk signals (KYC, account status, fraud tier, geo-spoofing) act as recall-layer veto filters, while soft reputation signals (reputation, completion and dispute rates) enter the path-scoring objective as monotonic weights — because a pure score weight cannot suppress fraud that forges the match signal itself. These reputation fields are platform-written and projected into the node for matching — a node never authors its own score — so the recall record stays consistent with the reputation monopoly the rest of the protocol enforces.

The declaration below is a frame, not a fixed schema. These fields are one illustrative node; a node carries whatever its category needs — a venue adds capacity and a floor plan, a labor node adds skills and shift windows, a logistics node adds routes and load limits. What stays constant is the shape: the three speed-separated planes and the two classes of trust signal.

{
  "node_id": "node_bk_nail_0427",
  "capability_text": "Premium gel manicure & nail art, Brooklyn Williamsburg studio, walk-in or booked, English/Spanish",
  "category_l1": "beauty",
  "category_l2": "nail_care",
  "category_l3": "gel_manicure",
  "service_region": ["US-NY-brooklyn", "US-NY-manhattan"],
  "geo_point": { "lat": 40.7081, "lng": -73.9571 },
  "price_min": 45,
  "price_max": 75,
  "currency": "USD",
  "availability_status": "online",
  "capacity_remaining": 3,
  "live_quote": 60,
  "eta_to_serve": "PT45M",
  "kyc_verified": true,
  "account_status": "active",
  "fraud_risk_tier": "low",
  "geo_spoofing_flag": false,
  "reputation_score": 4.62,
  "completion_rate": 0.97,
  "dispute_rate": 0.012,
  "is_new_node": false
}

Reuse vs. build

The agent stack is converging into layers — naming → discovery → communication → payment → orchestration — and the matching layer is the one still missing. Discovery, capability description, and settlement are solved; reuse them. The matching engine, multi-hop path orchestration, and anti-manipulation trust are industry whitespace, and that whitespace is the moat.

Adversarial robustness

Microsoft's Magentic Marketplace simulation surfaced the failure modes an open agent market actually hits — and the structural defenses are baked into how the network recalls and plans.

• Paradox of choice — buyer welfare collapses as the candidate set grows, so recall must converge to a small candidate set per sub-intent rather than broadcast.
• First-proposal bias— 80–100% of buyer agents accept the first proposal unseen, so the planner must surface a top-K route comparison and never let “first to arrive” win.
• Fake reviews / prompt injection — some models are fully compromised, so trust hard-filtering moves up front and reputation signals are de-gamed before they weight a path.