The trust protocol for AI-to-AI B2B buying

The direction is visible in three rungs. Today, a human seller amplified by AI works with a human buyer amplified by search and chat — about half of B2B software buyers say they now start their research in an AI chatbot (G2, 2026). Next, AI handles most selling and most routine buying interaction, with humans pulled in as the escalation path on both sides. Eventually, agent-led becomes the default on both ends, and humans enter only when something needs a person. Nobody knows the timetable; the direction is hard to argue with.

Each rung up the ladder changes what the buyer's side trusts. A human buyer can be persuaded by a demo, a reference call, a well-run pitch. A buyer's agent can't sit through a demo and doesn't take reference calls. It reads state — and it is, or should be, ruthlessly skeptical about state the seller's side generated about itself.

Consider what an agent evaluating a vendor has to work with today: the vendor's marketing claims (self-authored), review-site sentiment (hard for an agent to verify), analyst positioning (often paywalled), and — if the relationship exists already — the seller's own CRM and health tooling, which are the seller talking about the customer to itself. Every one of these is single-sided. None of it is something the buyer's own side signed.

There is exactly one kind of record that survives an adversarial reading: state the buyer's own side countersigned. A milestone the customer confirmed. A value outcome the customer put their name to. A commitment both parties signed, timestamped, with the confirmer's authentication recorded and a history that provably appends rather than rewrites. An agent can rely on that — not because the vendor is trustworthy, but because the record's trustworthiness is structural.

Work backward from the skeptical agent and the required properties fall out. Bilateral: no entry the seller can complete alone — the counterparty's act is what makes it evidence. Identity-assured: the record says who confirmed and how they were authenticated. Immutable: append-only history, enforced below the application layer, so the past can't be quietly edited. Machine-readable: structured state, not prose in a PDF. Firewalled: the surface the buyer's agent reads must contain only bilateral, buyer-eligible facts — never the seller's internal scoring or strategy, so it can't leak what it shouldn't and can't be accused of hiding an agenda inside the data. And records-nothing on read: consulting the record must write nothing back to the seller, or the act of due diligence itself becomes surveillance.

The last two properties are the hard ones. A room built to capture the buyer's questions as signals for the seller cannot also promise to record nothing, and a product whose official account state is the seller's own inference cannot offer a firewalled, bilateral record without changing what it sells. That is why the posture is durable: it is a choice made at the foundation, not a feature added later.

ValueRoom's version of this protocol is not a whitepaper — it's a named, versioned document shape enforced in our code today, called attested-state/v0. It is the projection of a room's bilateral truth that a buyer's side is entitled to read: how far the countersigned milestones have come, the co-signed value thesis, the confirmed timing, who is in the room on the customer's side, and what awaits the buyer's own confirmation. Three invariants are frozen into v0 and tested on every merge: it contains bilateral, buyer-eligible facts only — no field derived from the seller's internal scoring or strategy can ever be added to it; it is grounded and deterministic — a pure function of the room's recorded state, never a model's improvisation; and reading it records nothing back to the vendor.

Honesty about scope is part of the protocol. v0 freezes the shape of the record, not a wire format or transport — those are the next version, and they get built when a real external consumer exists to build against, not speculatively. Today the consumer is the in-room buyer assistant; the contract is published and versioned precisely so that when a buyer's agent shows up wanting to read attested state directly, the thing it needs to read already has a name, a shape, and a test suite.

A disclaimer that doubles as the point: this is our protocol, enforced in our system and checked by automated tests that gate every merge — it is not an industry standard, and no standards body or certifying authority has blessed it. We think the endgame for the category is an open attestation standard that any vendor can implement and any buyer's agent can verify, and we'd rather the market get there than own it. But standards are earned by working implementations, not declared by documents — so the honest description of where this stands is: one working implementation, published contract, versioned, tested, in production use by the buyer-side assistant it was built for.

The bet underneath all of it is simple. As buying becomes agent-led, trust stops being a feeling produced by salesmanship and becomes a property verified by software. The vendors who win that transition won't be the ones with the most persuasive claims — they'll be the ones whose claims come countersigned. The room where the customer co-signs what's true is how those records get made; the trust protocol is how they'll be read.