SBKIM: A Protocol for Semantic Bidirectional AI Matching in Human and Agent Networks

Independent Research · Open Protocol Proposal

September 2026 · Second version · first version May 2026 in the open repository · second publication via Zenodo

DOI: doi.org/10.5281/zenodo.22277738

---

1. Introduction

Finding the right counterpart — whether a supplier, collaborator, or AI agent — is fundamentally a problem of understanding. Current approaches reduce this problem to keyword matching, filter hierarchies, or platform-specific recommendation algorithms. These approaches share a structural flaw: they are unidirectional. One party queries; the system retrieves. The retrieved party has no agency in the match.

This asymmetry produces well-known failure modes. A developer who describes their work as "building complex digital systems that scale" will not appear in a search for "React developer" — even if they are the ideal candidate. Conversely, a supplier who optimizes their listing for search terms gains visibility regardless of actual fit. Meaning is systematically discarded in favor of lexical overlap.

The emergence of large language models changes this. For the first time, it is practical to evaluate the semantic compatibility of two natural language descriptions at low cost and high throughput. SBKIM is a protocol that operationalizes this capability: both parties describe themselves in natural language; the protocol evaluates bidirectional compatibility and returns a structured result.

We introduce a two-layer architecture. Layer 1 applies the protocol to human networks — marketplace matching, talent discovery, B2B lead qualification. Layer 2 applies the same protocol to agent networks — semantic discovery between AI systems before they establish direct communication channels. The unification of these two layers under one protocol is a core contribution of this work.

2. Related Work and Gap Analysis

Vector search and embedding databases (Pinecone^[1], Weaviate, Chroma) enable semantic retrieval over large corpora. However, they remain unidirectional: a query vector is matched against stored document vectors. There is no native concept of a second party with its own needs and capabilities.

Agent communication frameworks (LangChain^[2], AutoGen, CrewAI) provide tooling for multi-agent orchestration. Agent connections are defined statically by a human orchestrator. No framework currently provides a discovery mechanism by which agents assess their mutual compatibility before connecting.

Model Context Protocol (MCP)^[3], introduced by Anthropic, defines how agents access tools and data sources. MCP addresses how agents communicate once connected. It does not address whether two agents should connect, or why.

Agent marketplaces (emerging, 2024–2026) attempt discovery through centralized directories with structured metadata. This reintroduces platform lock-in and the same keyword-matching failure modes as human marketplaces.

2.1 The prior work the building blocks come from

Three research fields have long worked on parts of what this protocol combines. They belong in this text before it names a contribution.

Reciprocal recommender systems^[6] are a research field of their own, with their own metrics. They grew out of online dating and job matching, and their core is exactly the symmetry that section 3.1 presents as the core principle: a recommendation counts as successful only when both sides agree. The symmetry constraint is therefore not new. What these systems require is a platform that knows both sides, and a candidate set that is already fixed.

Semantic overlay networks^[7] solve the other half, and have done so since around 2008. Nodes arrange themselves by topical proximity, and a query finds its way without a central directory. Semantic discovery without an index is therefore not new either. Those networks are one-sided, though: a query looks for content, and the content looks for nothing.

Signed agent self-descriptions have existed since 2026 as Agent Cards in the A2A protocol^[8]. An Agent Card states capabilities, skills and the conditions an agent operates under. It does not state what the agent is looking for from others. A paper from March 2026 goes further and describes signed, short-lived capability descriptors with a time to live, routed by semantic similarity^[9]. That is conceptually very close to the spore in section 3.

Approach	Both sides state capability and need	Free text	No central index	Deployed and measured
Vector Search	✗	Partial	✗	✓
Agent Frameworks	✗	✗	✓	✓
MCP	✗	✗	✓	✓
Agent Marketplaces	✗	Partial	✗	✓
Reciprocal recommender systems[6]	✓	Partial	✗	✓
Semantic overlay networks[7]	✗	✓	✓	prototypes
Agent Cards / capability descriptors[8][9]	✗	✓	✓	partly draft
SBKIM (this work)	✓	✓	✓	✓

2.2 What is left

Each column of the table is occupied on its own. None of the work found occupies them together. Reciprocal recommender systems have the symmetry but need an operator in the middle. Semantic overlay networks manage without an operator but know only one direction. Agent Cards are advertisements: they say what someone can do and stay silent about what they are looking for.

This observation comes from three searches and is not a systematic review. It falls the moment work does both at once. The contribution of this work is in section 6 and does not depend on it.

3. The SBKIM Protocol

3.1 Core Principle

SBKIM is founded on a single symmetry constraint: both parties must describe both their capabilities and their needs. This four-field input structure is the minimum viable specification for bidirectional compatibility assessment.

A compatibility request is a 4-tuple:

3.2 Compatibility Response

A conforming SBKIM evaluator must return the following structured response:

3.3 The Three Dimensions

The three evaluation dimensions are designed to be orthogonal — a high score in one does not imply high scores in others. This allows for partial compatibility analysis and targeted bridge recommendations.

3.4 Protocol Properties

A valid SBKIM implementation must satisfy the following properties:

Symmetry. The evaluator must consider both directions: whether A's capabilities meet B's needs, and whether B's capabilities meet A's needs. A single-direction evaluation is not SBKIM-conformant.

Language independence. Inputs must be accepted in any natural language. No structured query syntax, ontology, or controlled vocabulary may be required.

Evaluator agnosticism. The protocol does not specify the underlying language model. Any LLM capable of instruction-following and JSON output may serve as evaluator. The prompt template is the portable artifact.

Statelessness. Each evaluation is independent. No user profiles, historical data, or platform accounts are required or assumed.

3.5 The self-description follows the content

A party's self-description is not written once and then kept. It is computed from the actual content the party holds, and it is recomputed when that content changes.

Technically each party carries itself at two resolutions. A domain vector over the whole holding, 384 dimensions. And up to twenty sentence vectors, one per individual sentence from the holding. The finer resolution separates related material that the overall vector blurs; where it is absent, evaluation falls back to the overall vector.

When the content changes, three things happen: the vector is recomputed, a version counter increases, and the self-description is signed again. The counter is a drift marker. By it a counterpart can tell that it holds an older edition of the same party. The self-description also records what its vector was derived from: the content, or a hand-written profile.

The practical consequence is the point. A cookbook that comes to hold only sushi recipes describes itself as a sushi collection once its vector has been recomputed. It is scored higher for a sushi query than a cookbook in which sushi appears in three recipes out of two hundred. Neither party registered, tagged or enrolled anything to make that happen.

The statelessness of section 3.4 is untouched by this. What changes is the description, not the procedure: each individual evaluation still works only from the four fields in front of it, with no history and no profile.

The limit of this property is a matter of scale. The raw cosine distance of the embedding model in use has a high floor: across a measured holding the mean sits at 0.82 with a spread of 0.02. A shift in content has to exceed that floor before it becomes visible in the ranking. Small changes to the holding move the vector, but not necessarily the position in the list.

4. Two-Layer Architecture

4.1 Layer 1 — Human Networks

In Layer 1, two humans independently describe their offering and their requirement. The protocol evaluates compatibility and returns a structured result to both parties simultaneously. Neither party has privileged access to the other's raw input prior to the evaluation — only the compatibility report is shared.

Layer 1 is intentionally decentralized: no matching database is required. Two devices, one shared session identifier, one API call. This makes the protocol deployable in contexts where data sovereignty is a requirement.

4.2 Layer 2 — Agent Networks

In Layer 2, N agents each provide a self-description (capabilities and needs). SBKIM evaluates all N×(N–1)/2 pairs and returns a full compatibility matrix. This matrix serves as a semantic map of the agent network — revealing which agents are natural collaborators before any direct communication is established.

We propose Layer 2 as a pre-communication layer in multi-agent architectures: run SBKIM first, connect only compatible pairs. This reduces unnecessary communication overhead and prevents mismatched agent pairings that consume context and produce low-quality outputs.

Layer 2 addresses what we term the agent discovery problem: in a network of N agents with heterogeneous capabilities, which agents should collaborate, and on what basis? Current frameworks answer this question through static human-defined routing. SBKIM proposes a dynamic, semantically grounded alternative.

5. How this came about

It began as a platform, and that was discarded. The first form was a server with a search and an index, every other node a client. That is another gatekeeper between small websites and their readers. Small sites do not have a platform problem. They have a findability problem, and they do not want to hand over their identity for it. That is how "Sage platform" became the Sage protocol, a rule between equals.

The symmetry came from an observation, not from a paper. At first the network was one-way: a seeker sends a question, a provider checks whether it can answer. That computed one direction only. Then it became apparent that every small site is both. Someone offering cocktails may be looking for glassware. Someone showing recipes may be looking for drinks. That is where the two fields capabilities and needs came from, and the one-sided comparison became a mirror.

Found independently, not found first. The reciprocal recommender systems in section 2.1 have worked with this symmetry for years.

5.1 Where the language model sits

It is not language models recognising each other. They are web applications and websites. Every node computes its vectors with the same small embedding model in its own browser: multilingual-e5-small, 384 dimensions. Because all nodes use the same model, their vectors lie in the same space and are directly comparable.

No model is distributed across several machines for this. Each node holds a complete copy of a small model, and only the 384 numbers that come out of it are exchanged. This is not distributed inference; it is replicated computation in a shared vector space.

The language-model judge is a second, optional stage. It re-ranks the candidates from the vector search and runs on the respective user's own key. If it cannot be reached, it reports so and the vector search remains complete.

"Server-less" belongs in quotation marks. There is a relay, and the operator of this network runs one himself. What is missing is a server at each participant and a central index. Peer-to-peer here means that nobody has to provide infrastructure of their own.

5.2 The high similarity floor

An accounting application matched a mycelium library at 0.81, although the two share nothing in content. The embedding model in use is anisotropic: it places all texts into a narrow cone instead of spreading them over the sphere. Any two German technical texts therefore already sit at around 0.82. The floor is thus above the threshold of 0.80 set at the time, and almost everything matched almost everything.

Subtracting the mean vector leaves only genuine relatedness, and every pair between the protocol node and the end nodes turns negative. The high raw value measured the model, not the topic. Reporting similarity scores from such a model without this correction reports the cone.

6. The running network

The reference implementation lives in the protocol repository: github.com/lausiklauskn-png/Sage-Protokol

It consists of modules that can be adopted one at a time — storage, identity, embedding, match, anastomosis and rendezvous — requiring only a browser. No backend, no database, no registration. The modules are copied byte-for-byte into the applications that use them; a check in the repository guards against the copies drifting apart.

6.1 What it has grown into

The description "two HTML applications" was accurate in May 2026. It is wrong about today's state by orders of magnitude. As of 24 August 2026, counted from the timestamps of the version control system:

What	State	Verifiable from
Source repositories	33	repository listing
of those, deployed web applications	more than twenty	one address each
Modules	00 to 23	src/modules/, copied byte-for-byte
End nodes with own identity, spore and mailbox	several	each sbkim/spore.json
Stored working states	5,823	timestamps, public
of those, made by hand	5,775	the difference is 48 scheduled runs
Days worked	128	10 March to 24 August 2026

6.2 The measurement of 10 July 2026

On 10 July 2026 the full bidirectional search ran between two independent nodes. Two real browsers, two key pairs, and a relay in between that knows no content and holds no authority.

Direction	Question	Answer	Time
protocol node → drinks node	"cocktails with other forest fruits"	5 meaning-ranked hits from its own holdings (0.83 to 0.84)	39 s
drinks node → protocol node	"who knows anything about fungi"	4 modules from its own library	0.5 s

A question travels as a question over the relay, and a meaning-ranked answer comes back from the current holdings of the other node. Neither participant holds an index of the other.

On the values 0.83 and 0.84. They are raw cosine values from an anisotropic model, and section 5.2 explains why such values have a high floor. As a ranking within one answer they are usable. As an absolute measure of relatedness they do not serve.

The reference prompt template used in the implementation is intentionally kept minimal. Implementors are encouraged to extend and adapt it while maintaining the four-field input structure and the three-dimension output schema.

6.3 Two ways to check

There are two public entry points, and they show different things. The demonstrations walk through the procedure on a staged case. The network map watches the running network. They also use different transports, and that is not an accident: the procedure is not tied to any one of them.

	The demonstrations	The network map
What is visible	the procedure from self-description to report, on a staged case	which nodes are announcing themselves and answering each other right now
Setup	three devices: one is the host, the other two join by QR code, one as provider, one as seeker	one device that only watches
Transport	WebRTC, directly between the devices, brokered by the default PeerJS broker	five Nostr relays, three of them foreign: relay.damus.io, nos.lol, relay.primal.net
Requirements	a browser, internet, an Anthropic key of your own; the pages load three libraries from a CDN	a browser, nothing else
Can send	yes, that is the point	no
Time window	the session, while it runs	the last thirty minutes

Demonstration Layer 1, human to human:
https://lausiklauskn-png.github.io/Sage-Protokol/sbkim-demo/demo.html
Demonstration Layer 2, agent network:
https://lausiklauskn-png.github.io/Sage-Protokol/sbkim-demo/sbkim-network.html
Network map, read-only:
https://lausiklauskn-png.github.io/Sage-Protokol/mycel-karte/

The network map cannot send. The only call it makes on a connection is a subscription; it never writes an event. This is in the source and can be counted in one line. An instrument that can only listen cannot have produced the traffic it displays. It subscribes to the five tags sbkim-rdv, sbkim-anastomosis, sbkim-anastomosis-reply, sbkim-query and sbkim-query-reply; every node that announces itself is drawn, every handshake between two of them appears as a thread.

Three limitations belong with it. The map shows a window of thirty minutes; if no node is active during that time, it stays empty. That is the normal state of a network without a permanent process: it runs while someone has one of the applications open, and not otherwise. Second, it shows that nodes announce themselves and answer each other, not what they answer. And third, it has a rehearsal button that is explicitly marked as a simulation, both in the source and in the interface.

And one about the demonstrations. They depend on a CDN, on a foreign broker and on a paid key. The protocol itself needs none of these: the modules in section 6 run without a CDN, without a broker and without a key. Those three dependencies belong to the demonstration, not to the protocol.

7. Open Problems

7.1 Semantic Discovery Without Session Codes

Passive semantic discovery consists of four sub-problems. Two of them are settled, two are not.

Sub-problem	State
Shared session identifier required	no longer needed. Nodes find each other through the relay and their signed cards
Bidirectional semantic search between independent nodes	demonstrated on 10 July 2026, see section 6.2
Distributed index with privacy-preserving retrieval	half open. For delivery to a counterpart already known, encrypted paths exist and one node of this network uses them; the relay then sees only ciphertext. The other half is open: to be found at all, a query today has to sit readable on a shared medium
Genuinely passive discovery, that is, describe once and be evaluated continuously thereafter	open, and at the same time excluded. Someone asks actively, and that is a decision: the nodes of this network issue no queries of their own into the open net

The last row is not a gap but a rule. A node of this network answers when asked and does not ask on its own. Building continuous evaluation lifts that rule and brings in what it guards against: a network in which twenty applications issue queries unprompted. The rule is not untouchable, but lifting it is a decision and not a by-product.

And one limit that surfaced in operation. An answer arrives reliably only while the answering node's tab is in the foreground and awake. Phones and tablets throttle background tabs. A repeat question against an aged card ran into nothing until the node refreshed its card. For a service that answers unattended, this is an open point.

7.2 Evaluator Consistency

LLM-based evaluators are non-deterministic. Two evaluations of the same pair may return different scores. A production SBKIM implementation should define consistency requirements and potentially use ensemble evaluation or deterministic scoring heuristics.

7.3 Adversarial Inputs

Unlike keyword systems, SBKIM is resistant to SEO-style gaming — padding a self-description with keywords does not directly improve match scores because the evaluator assesses meaning, not lexical overlap. However, adversarial prompt injection in self-descriptions is a known attack surface and requires input sanitization in production deployments.

7.4 Agent Self-Description Standards

For Layer 2 to scale, agents need a standard format for self-description. We propose that agent systems expose a /.well-known/sbkim.json endpoint with capabilities and needs fields, analogous to robots.txt or OpenAPI schemas. This is not yet standardized.

8. Conclusion

SBKIM is a minimal, open protocol for semantic bidirectional compatibility assessment between two parties describing themselves in natural language. It requires both sides to state capabilities and needs.

The contribution of this work is a field report. The building blocks are known: the transport is borrowed, the embedding is state of the art, the cryptography is standard, and the symmetry is a research field of its own. What is new is that they run together, have done for months, in more than twenty deployed applications that nobody operates but their users. The prior work found consists of architectures, designs and prototypes. The building blocks are known; the operation is the contribution.

That includes what broke. The high similarity floor from section 5.2 nearly led to a property of the model being reported as topical relatedness. The throttled background tab from section 7.1 still limits what the protocol is good for.

The two-layer architecture demonstrates that the same protocol applies across scales: from two humans negotiating a contract to a network of AI agents discovering their optimal collaboration topology. We believe this unification is non-trivial and worth formalizing as an open standard before the ecosystem converges on platform-specific solutions.

We publish this proposal openly and invite implementations, critiques, and extensions. The reference implementation is MIT-licensed. The protocol specification in this document is released into the public domain.

9. How this text came about

This text was written with the help of a language model.

Editorial responsibility rests with one person, the operator of the network described. He set the question, supplied the evidence and read every version against it. The turning points came from him: the instruction to test every component of the claim against the literature; the instruction to check every statement at its source rather than assume it; and the decision to appear as a field report rather than with a claim that collapses at the first question.

What the checking consisted of. The figures in section 6.1 come from the timestamps of the version control system and can be recomputed there. The measurements in section 6.2 come from a run on real devices, with a date. The prior work in section 2.1 was searched for and checked before this text names a contribution. Where a statement could not be verified, it stands as an observation or not at all.

What this explicitly was not. Not a spell check and not the rewording of a finished text. The content emerged in alternation: proposal, objection, measurement, correction. Several statements fell in the process, before this text was published for the first time.

Where the evidence sits. The protocol repository from section 6 holds the session records, the lessons drawn from mistakes, and the worksheets on days worked. The history is public and dated.

Where this text first appeared. The repository was publicly accessible throughout the writing; every version of this text can be read there with its date and change history. The first publication is therefore the open repository itself: the first version of this text has been there since 18 May 2026 and was linked from the front page. The version on Zenodo is a secondary publication — it gives the text a citable address and a fixed version; it is not its first appearance.

---