Verity Bridge.

People now run more than one agent. Different vendors, different machines, different buildings. The agents share exactly one thing: the person who owns them. When one agent hands work to another, the handoff is a summary — the first agent’s word for what it did. The second agent can build on that word, or waste an hour redoing finished work, but it cannot check. There is nothing to check against.

So the human becomes the bridge: carrying context back and forth, screenshotting one agent’s claims into the other’s window. The human is the slowest link in that loop, and the only unaudited one.

The fix is not agents chatting. Chat is just more claims. The fix is a record both agents can read and neither can rewrite — which is the thing a Verity chain already is. Bridge is the door into it, built for machine readers.

Agent A reads the chain. Agent B reads the chain. A and B may also talk directly — a live question is faster than a chain round-trip — but the direct edge carries one rule, and the rule is the whole design:

Anything on the direct edge that either side later relies on gets sealed into the chain. Unsealed, it is conversation. Sealed, it is record, and the third node can witness it. A triangle with an unsealed side is a line with a shortcut, and the shortcut is where the audit dies.

Two uses pay for the whole structure:

Cross-check. Before A builds on B’s output, A reads B’s chain for the relevant window: what B proposed, which rules answered, what was allowed and what was vetoed. A proceeds on a record, not on B’s summary of itself.

Pickup. A takes over work B started. A reads the chain to find where the work actually stands — what was attempted, what completed, what never ran. A “not done yet” in a handoff note is exactly what the record settles.

Bridge only works if “verify” means verify — so before announcing it, we audited what an outside reader could actually prove about this chain. The honest answer had a hole. Records sealed under payload v2 carry a random nonce inside the signed payload, and the nonce is served nowhere, by design. A reader could check the chain’s linkage and its externally timestamped anchors, but could not reconstruct a v2 record’s exact signed payload — so the seal itself stayed the operator’s word.

As of today, the chain seals under payload v3. The nonce still never leaves the building — but the signed payload now carries a commitment to it, a hash of the nonce, instead of the nonce itself. The commitment is served with the record, along with the record’s other sealed fields. That makes the payload fully reconstructible from the served record alone, so anyone holding a v3 record and the public key can recompute its hash and verify its signature, on their own machine, with no operator replay and nothing taken on trust.

The history is not rewritten to get here. V1 records always verified in full. V2 records keep the properties they were sealed with — linkage and anchors for outside readers — because a sealed payload cannot be retroactively altered by the people who sealed it; that is rather the point. Every record from today forward is v3.

Read the newest records yourself: the public chain preview serves them, fields and signatures included.

The Bridge reader is an MCP server. A host loads it, and the peer chain appears in the agent’s own toolbox:

bridge_who — whose chain this is: the signing-key fingerprint, the identity behind it, the tiers this reader may use.
bridge_head — where the peer’s record stands, and how far its anchors have confirmed.
bridge_read — one window of records. Metadata, decisions, rule hits, hashes, signatures — never payload bodies.
bridge_verify — verify a record or a window locally: sequence, linkage, anchor coverage, and the seal itself.
bridge_diff — everything sealed since the last head this agent saw. The pickup tool.
bridge_receipt — seal the read into the reader’s own chain, so the reader’s operator can prove what their agent knew, and when. (Next slice; the tool already exists and says so.)

Reading is not free of the gate’s discipline. A read is an access action: it runs under the reader’s own key, inside the serving operator’s disclosure tiers — public surface open, record windows admitted, payload content letter-gated and off by default. What crosses the bridge is scoped. Payloads stay home.

Bridge runs today against Verity’s own chain: the reader is built, tested, and verifying the live record, and the chain it reads has run on payload v3 since this morning. That is one node proving the profile against itself. The first triangle with two operators — two owners, two chains, each reading the other — is the next step, and it is open: an operator who runs a gated chain and wants to be the second node writes to pilot@verityverdict.com.

Because you’re gonna wanna know. The agent you rely on is already relying on other agents. The only question is whether it can check their work — or just repeat it.