Agent-Mediated Introduction: What It Looks Like in Practice
Before two people meet, their agents could already have exchanged compatibility scores, checked hard constraints, and issued a contact token. Here is what that looks like.
Consider two people — call them A and B — who have each published a PairGeek profile on their own domains. Neither knows the other exists. An agent operating on behalf of A is crawling profiles that match A's compatibility constraints.
The agent discovers B's /.well-known/pairgeek manifest, resolves the schema URI, and fetches B's profile. It runs A's hard constraints against B's declared attributes. No violations. It computes a soft-preference score: 0.81. Above A's configured threshold of 0.7.
The agent now initiates the PairGeek handshake: it sends a PAIRGEEK_HELLO message to B's agent endpoint, attaching A's schema URI and the requested variant. B's agent fetches A's profile, runs B's own constraints, computes a score from B's perspective. Also above threshold. B's agent issues a contact_gate token — a time-limited, single-use URL through which A can initiate contact with B.
A's agent presents this to A: a proposed introduction, with the compatibility scores, the constraint check results, and the contact link. A decides whether to proceed.
No centralized platform was involved. No engagement algorithm decided what A saw. Both parties maintained full control of their own data. The human decision — whether to actually make contact — remained with the humans.
This is not science fiction. Every component of this flow exists. The missing piece is the protocol that makes them interoperable. That is what PairGeek provides.