September 2026 · Zweite Fassung · Erstfassung Mai 2026 im offenen Depot · Zweitveröffentlichung über Zenodo
DOI: doi.org/10.5281/zenodo.22277738
Wir schlagen SBKIM (Semantisches Bidirektionales KI-Matching) vor — ein offenes Protokoll zur Bestimmung semantischer Kompatibilität zwischen zwei Parteien in natürlicher Sprache, ohne strukturierte Abfragen, Datenbanken oder zentralisierte Plattformen. Im Unterschied zu unidirektionalen Retrievalsystemen verlangt SBKIM, dass beide Parteien gleichzeitig ihre Fähigkeiten und ihren Bedarf beschreiben. Ein Sprachmodell bewertet das Paar auf drei orthogonalen Dimensionen und gibt einen strukturierten Kompatibilitätsbericht zurück. Das Protokoll arbeitet auf zwei Ebenen: Layer 1 für Mensch-zu-Mensch-Matching (Käufer/Anbieter, Mitarbeiter/Projekt) und Layer 2 für Agenten-zu-Agenten-Matching in Multi-Agenten-Systemen. Wir argumentieren, dass SBKIM ein bislang unzureichend behandeltes Problem im aktuellen Agenten-Ökosystem adressiert — semantische Entdeckung vor der Kommunikation — und schlagen es als offenen Kandidaten-Standard vor. Eine funktionsfähige Referenz-Implementierung ist öffentlich verfügbar; der Verkehr des laufenden Netzes lässt sich über eine mitlesende Netz-Karte selbst nachsehen.
Die richtige Gegenpartei zu finden — ob Lieferant, Mitarbeiter oder KI-Agent — ist im Kern ein Problem des Verstehens. Aktuelle Ansätze reduzieren dieses Problem auf Keyword-Abgleich, Filterhierarchien oder plattformspezifische Empfehlungsalgorithmen. Diese Ansätze teilen einen strukturellen Fehler: sie sind unidirektional. Eine Partei sucht; das System liefert Treffer. Die gefundene Partei hat keine Handlungsmacht im Match.
Diese Asymmetrie erzeugt bekannte Versagensmuster. Ein Entwickler, der seine Arbeit als „Aufbau komplexer digitaler Systeme mit Skalierbarkeit" beschreibt, erscheint nicht in einer Suche nach „React-Entwickler" — obwohl er der ideale Kandidat wäre. Umgekehrt gewinnt ein Anbieter, der sein Profil für Suchbegriffe optimiert, Sichtbarkeit unabhängig von seiner tatsächlichen Eignung. Bedeutung wird systematisch zugunsten lexikalischer Übereinstimmung verworfen.
Das Aufkommen großer Sprachmodelle verändert dies grundlegend. Erstmals ist es praktikabel, die semantische Kompatibilität zweier natürlichsprachlicher Beschreibungen zu niedrigen Kosten und mit hohem Durchsatz zu bewerten. SBKIM ist ein Protokoll, das diese Fähigkeit operationalisiert: Beide Parteien beschreiben sich in natürlicher Sprache; das Protokoll bewertet bidirektionale Kompatibilität und gibt ein strukturiertes Ergebnis zurück.
Wir stellen eine Zwei-Ebenen-Architektur vor. Layer 1 wendet das Protokoll auf menschliche Netzwerke an — Marktplatz-Matching, Talentsuche, B2B-Lead-Qualifizierung. Layer 2 wendet dasselbe Protokoll auf Agentennetzwerke an — semantische Entdeckung zwischen KI-Systemen, bevor sie direkte Kommunikationskanäle aufbauen. Die Vereinheitlichung dieser beiden Ebenen unter einem Protokoll ist ein zentraler Beitrag dieser Arbeit.
Vektordatenbanken und Embedding-Suche (Pinecone[1], Weaviate, Chroma) ermöglichen semantisches Retrieval über große Korpora. Sie bleiben jedoch unidirektional: Ein Anfragevektor wird mit gespeicherten Dokumentvektoren abgeglichen. Es gibt kein natives Konzept einer zweiten Partei mit eigenen Bedürfnissen und Fähigkeiten.
Agenten-Kommunikations-Frameworks (LangChain[2], AutoGen, CrewAI) stellen Werkzeuge für Multi-Agenten-Orchestrierung bereit. Agenten-Verbindungen werden statisch durch einen menschlichen Orchestrator definiert. Kein Framework bietet derzeit einen Entdeckungsmechanismus, durch den Agenten ihre gegenseitige Kompatibilität vor der Verbindung bewerten können.
Model Context Protocol (MCP)[3], eingeführt von Anthropic, definiert, wie Agenten auf Werkzeuge und Datenquellen zugreifen. MCP adressiert das Wie der Agenten-Kommunikation nach der Verbindung. Es adressiert nicht das Ob zweier Agenten verbunden werden sollten, und warum.
Agenten-Marktplätze (entstehend, 2024–2026) versuchen Entdeckung durch zentralisierte Verzeichnisse mit strukturierten Metadaten. Dies führt Plattform-Abhängigkeit und dieselben Keyword-Matching-Versagensmuster wie bei menschlichen Marktplätzen wieder ein.
Drei Forschungsfelder haben Teile dessen, was dieses Protokoll zusammensetzt, längst bearbeitet. Sie gehören genannt, bevor hier ein Beitrag benannt wird.
Reziproke Empfehlungssysteme (reciprocal recommender systems)[6] sind ein eigenes Forschungsfeld mit eigenen Metriken. Sie entstanden für Partnervermittlung und Stellenvermittlung, und ihr Kern ist genau die Symmetrie, die Abschnitt 3.1 als Grundprinzip beschreibt: eine Empfehlung gilt erst dann als gelungen, wenn beide Seiten zustimmen. Die Symmetrie-Anforderung ist damit nicht neu. Was diese Systeme voraussetzen, ist eine Plattform, die beide Seiten kennt, und ein Kandidatenfeld, das schon feststeht.
Semantische Überlagerungsnetze (semantic overlay networks)[7] lösen die andere Hälfte, und das seit etwa 2008. Knoten ordnen sich nach inhaltlicher Nähe, und eine Anfrage findet ihren Weg ohne zentrales Verzeichnis. Semantische Entdeckung ohne Index ist damit ebenfalls nicht neu. Diese Netze sind aber einseitig: eine Anfrage sucht Inhalte, und die Inhalte suchen nichts.
Signierte Selbstbeschreibungen von Agenten gibt es seit 2026 als Agent Cards im A2A-Protokoll[8]. Eine Agent Card nennt Fähigkeiten, Fertigkeiten und die Bedingungen, unter denen ein Agent arbeitet. Sie nennt nicht, was der Agent von anderen sucht. Eine Arbeit vom März 2026 geht weiter und beschreibt signierte, kurzlebige Fähigkeits-Beschreibungen mit Verfallsdatum, die nach semantischer Ähnlichkeit weitergereicht werden[9]. Das ist der Spore aus Abschnitt 3 konzeptionell sehr nah.
| Ansatz | Beide Seiten nennen Können und Bedarf | Freier Text | Ohne zentralen Index | Ausgeliefert und gemessen |
|---|---|---|---|---|
| Vektorsuche | ✗ | Teilweise | ✗ | ✓ |
| Agenten-Frameworks | ✗ | ✗ | ✓ | ✓ |
| MCP | ✗ | ✗ | ✓ | ✓ |
| Agenten-Marktplätze | ✗ | Teilweise | ✗ | ✓ |
| Reziproke Empfehlungssysteme[6] | ✓ | Teilweise | ✗ | ✓ |
| Semantische Überlagerungsnetze[7] | ✗ | ✓ | ✓ | Prototypen |
| Agent Cards / Fähigkeits-Beschreibungen[8][9] | ✗ | ✓ | ✓ | teils Entwurf |
| SBKIM (diese Arbeit) | ✓ | ✓ | ✓ | ✓ |
Die Spalten der Tabelle sind einzeln alle besetzt. Keine der gefundenen Arbeiten besetzt sie zusammen. Reziproke Empfehlungssysteme haben die Symmetrie, brauchen dafür aber einen Betreiber in der Mitte. Semantische Überlagerungsnetze kommen ohne Betreiber aus, kennen aber nur eine Richtung. Agent Cards sind Anzeigen: sie sagen, was einer kann, und schweigen darüber, was er sucht.
Diese Beobachtung stammt aus drei Suchen und ist keine systematische Übersicht. Sie fällt, sobald eine Arbeit beides zugleich leistet. Der Beitrag dieser Arbeit steht in Abschnitt 6 und hängt nicht an ihr.
SBKIM basiert auf einer einzigen Symmetrie-Anforderung: Beide Parteien müssen sowohl ihre Fähigkeiten als auch ihren Bedarf beschreiben. Diese Vier-Felder-Eingabestruktur ist die minimal notwendige Spezifikation für eine bidirektionale Kompatibilitätsbewertung.
Eine Kompatibilitätsanfrage ist ein 4-Tupel:
Eine konforme SBKIM-Implementierung muss folgende strukturierte Antwort zurückgeben:
Die drei Bewertungsdimensionen sind so gestaltet, dass sie orthogonal sind — ein hoher Wert in einer Dimension impliziert keine hohen Werte in den anderen. Dies ermöglicht eine differenzierte Kompatibilitätsanalyse und gezielte Brückenempfehlungen.
Übereinstimmung in Fachgebiet und Wissen. Arbeiten beide Parteien im selben Problemraum?
Workflow-, Kommunikations- und Kollaborationskompatibilität. Wie arbeiten sie — nicht was tun sie?
Ausrichtung von Kapazität, Umfang und Wachstumstrajektorie. Können beide Parteien auf derselben Ebene operieren?
Eine gültige SBKIM-Implementierung muss folgende Eigenschaften erfüllen:
Symmetrie. Der Evaluator muss beide Richtungen berücksichtigen: ob A's Fähigkeiten B's Bedarf decken, und ob B's Fähigkeiten A's Bedarf decken. Eine Einrichtungsauswertung ist nicht SBKIM-konform.
Sprachunabhängigkeit. Eingaben müssen in jeder natürlichen Sprache akzeptiert werden. Es darf keine strukturierte Abfragesyntax, Ontologie oder kontrolliertes Vokabular verlangt werden.
Evaluator-Agnostizismus. Das Protokoll spezifiziert nicht das zugrunde liegende Sprachmodell. Jedes LLM mit Instruktionsfolgen und JSON-Ausgabe kann als Evaluator dienen. Das Prompt-Template ist das portable Artefakt.
Zustandslosigkeit. Jede Bewertung ist unabhängig. Keine Nutzerprofile, historischen Daten oder Plattform-Konten sind erforderlich oder vorausgesetzt.
Die Selbstbeschreibung einer Partei wird nicht einmal verfasst und dann festgehalten. Sie wird aus dem tatsächlichen Inhalt gerechnet, den die Partei führt, und sie wird neu gerechnet, wenn dieser Inhalt sich ändert.
Technisch trägt jede Partei zwei Auflösungen ihrer selbst. Einen Domänen-Vektor über den gesamten Bestand, 384 Dimensionen. Und bis zu zwanzig Satz-Vektoren, je einer für einen einzelnen Satz aus dem Bestand. Die feinere Auflösung trennt Verwandtes, das der Gesamtvektor verschmiert; fehlt sie, fällt die Bewertung auf den Gesamtvektor zurück.
Ändert sich der Inhalt, geschieht dreierlei: der Vektor wird neu gerechnet, ein Versionszähler steigt, und die Selbstbeschreibung wird neu signiert. Der Zähler ist ein Drift-Merkmal. An ihm erkennt eine Gegenstelle, dass sie eine ältere Fassung derselben Partei kennt. Zusätzlich hält die Selbstbeschreibung fest, woraus ihr Vektor stammt: aus dem Inhalt oder aus einem von Hand geschriebenen Steckbrief.
Was daraus folgt, ist der praktische Kern. Ein Kochbuch, das nur noch Sushi-Rezepte enthält, beschreibt sich als Sushi-Sammlung, sobald sein Vektor neu gerechnet wurde. Es wird für eine Sushi-Anfrage höher bewertet als ein Kochbuch, in dem Sushi in drei von zweihundert Rezepten vorkommt. Keine der beiden Parteien hat dafür etwas eingetragen, verschlagwortet oder angemeldet.
Die Zustandslosigkeit aus Abschnitt 3.4 bleibt davon unberührt. Was sich ändert, ist die Beschreibung, nicht das Verfahren: jede einzelne Bewertung arbeitet weiterhin nur mit den vier Feldern, die ihr vorliegen, ohne Vorgeschichte und ohne Profil.
Die Grenze dieser Eigenschaft ist eine Größenordnung. Der rohe Kosinus-Abstand des verwendeten Einbettungs-Modells hat einen hohen Boden: über einen gemessenen Bestand liegt der Mittelwert bei 0,82 bei einer Streuung von 0,02. Eine inhaltliche Verschiebung muss diesen Boden überschreiten, um in der Rangfolge sichtbar zu werden. Kleine Änderungen am Bestand bewegen den Vektor, aber nicht unbedingt den Platz in der Liste.
In Layer 1 beschreiben zwei Menschen unabhängig voneinander ihr Angebot und ihren Bedarf. Das Protokoll bewertet Kompatibilität und gibt ein strukturiertes Ergebnis gleichzeitig an beide Parteien zurück. Keine Partei hat privilegierten Zugang zu den Roheingaben der anderen vor der Auswertung — nur der Kompatibilitätsbericht wird geteilt.
Layer 1 ist bewusst dezentralisiert: Es ist keine Matching-Datenbank erforderlich. Zwei Geräte, ein gemeinsamer Sitzungsbezeichner, ein API-Aufruf. Dies macht das Protokoll in Kontexten einsetzbar, wo Datensouveränität eine Anforderung ist.
In Layer 2 stellen N Agenten jeweils eine Selbstbeschreibung bereit (Fähigkeiten und Bedarf). SBKIM bewertet alle N×(N–1)/2 Paare und gibt eine vollständige Kompatibilitätsmatrix zurück. Diese Matrix dient als semantische Karte des Agentennetzwerks — sie zeigt, welche Agenten natürliche Kollaborationspartner sind, bevor eine direkte Kommunikation aufgebaut wird.
Wir schlagen Layer 2 als Vor-Kommunikations-Schicht in Multi-Agenten-Architekturen vor: SBKIM zuerst ausführen, nur kompatible Paare verbinden. Dies reduziert unnötigen Kommunikationsaufwand und verhindert fehlangepasste Agenten-Paarungen, die Kontext verbrauchen und mindere Ergebnisse liefern.
Layer 2 adressiert, was wir das Agenten-Entdeckungsproblem nennen: In einem Netzwerk von N Agenten mit heterogenen Fähigkeiten — welche Agenten sollten zusammenarbeiten, und auf welcher Grundlage? Aktuelle Frameworks beantworten diese Frage durch statisches, menschlich definiertes Routing. SBKIM schlägt eine dynamische, semantisch begründete Alternative vor.
Am Anfang stand eine Plattform, und die wurde verworfen. Die erste Form war ein Server mit einer Suche und einem Index, alle anderen Knoten Klienten. Das ist ein Türsteher zwischen kleinen Webseiten und ihren Lesern. Kleine Seiten haben kein Plattform-Problem. Sie haben ein Findbarkeits-Problem, und sie wollen dafür nicht ihre Identität abgeben. Aus „Sage-Plattform" wurde damit das Sage-Protokol, eine Spielregel zwischen Gleichberechtigten.
Die Symmetrie kam aus einer Beobachtung, nicht aus einem Papier.
Anfangs war das Netz eine Einbahnstraße: Ein Sucher schickt eine Frage, ein Anbieter prüft, ob er antworten kann. Das rechnete nur eine Richtung. Dann fiel auf,
dass jede kleine Seite beides ist. Wer Cocktails anbietet, sucht vielleicht
Glaswaren. Wer Kochrezepte zeigt, sucht passende Getränke. Daraus wurden die
zwei Felder capabilities und needs, und aus dem
einseitigen Vergleich wurde ein Spiegel.
Unabhängig gefunden, nicht zuerst gefunden. Die reziproken Empfehlungssysteme aus Abschnitt 2.1 arbeiten seit Jahren mit dieser Symmetrie.
Es sind keine Sprachmodelle, die einander erkennen. Es sind Web-Anwendungen und
Seiten. Jeder Knoten rechnet seine Vektoren mit demselben kleinen
Einbettungs-Modell im eigenen Browser: multilingual-e5-small,
384 Dimensionen. Weil alle Knoten dasselbe Modell benutzen, liegen ihre Vektoren
im selben Raum und sind unmittelbar vergleichbar.
Kein Modell wird dafür über mehrere Rechner verteilt. Jeder Knoten hält eine vollständige Kopie eines kleinen Modells, und ausgetauscht werden nur die 384 Zahlen, die dabei herauskommen. Das ist keine verteilte Inferenz, sondern repliziertes Rechnen in einem gemeinsamen Vektorraum.
Der Sprachmodell-Richter ist eine zweite, freiwillige Stufe. Er ordnet die Kandidaten der Vektor-Suche neu und läuft mit dem Schlüssel des jeweiligen Nutzers. Ist er nicht erreichbar, meldet er das und die Vektor-Suche bleibt vollständig.
„Server-los" gehört in Anführungszeichen. Ein Relais gibt es, und der Betreiber dieses Netzes stellt selbst eines. Was fehlt, ist ein Server beim Einzelnen und ein zentraler Index. Peer-to-peer heißt hier: niemand muss eigene Infrastruktur stellen.
Eine Buchhaltungs-Anwendung passte zu 0,81 auf eine Mycel-Bibliothek, obwohl beide inhaltlich nichts teilen. Das verwendete Einbettungs-Modell ist anisotrop: es legt alle Texte in einen engen Kegel, statt sie über die Kugel zu verteilen. Zwei beliebige deutsche Fachtexte liegen dadurch schon bei etwa 0,82. Der Boden liegt also über der damals gesetzten Schwelle von 0,80, und fast alles passte zu fast allem.
Zieht man den Mittelwert-Vektor ab, bleiben nur echte Verwandtschaften übrig, und alle Paare zwischen dem Protokoll-Knoten und den Endknoten werden negativ. Der hohe Rohwert maß das Modell, nicht das Thema. Wer Ähnlichkeitswerte aus einem solchen Modell ohne diese Korrektur berichtet, berichtet den Kegel.
Die Referenz-Implementierung liegt im Protokoll-Depot: github.com/lausiklauskn-png/Sage-Protokol
Sie besteht aus einzeln übernehmbaren Modulen — Speicher, Identität, Einbettung, Match, Anastomose und Rendezvous —, die nur einen Browser erfordern. Kein Backend, keine Datenbank, keine Registrierung. Die Module werden byte-genau in die anwendenden Web-Anwendungen kopiert; eine Prüfung im Depot wacht darüber, dass die Kopien nicht auseinanderlaufen.
Die Beschreibung „zwei HTML-Anwendungen" traf den Mai 2026. Sie trifft den heutigen Stand um Größenordnungen nicht mehr. Stand 24. August 2026, ausgezählt aus den Zeitstempeln der Quelltext-Verwaltung:
| Was | Stand | Nachprüfbar an |
|---|---|---|
| Quelltext-Depots | 33 | Depot-Übersicht |
| davon ausgelieferte Web-Anwendungen | über zwanzig | je eine eigene Adresse |
| Module | 00 bis 23 | src/modules/, byte-genau kopiert |
| Endknoten mit eigener Identität, Spore und Postfach | mehrere | je sbkim/spore.json |
| Gespeicherte Arbeitsstände | 5.823 | Zeitstempel, öffentlich |
| davon von Hand | 5.775 | Differenz sind 48 zeitgesteuerte Läufe |
| Tage mit Arbeit | 128 | 10.03. bis 24.08.2026 |
Am 10. Juli 2026 lief die vollständige bidirektionale Suche zwischen zwei unabhängigen Knoten. Zwei echte Browser, zwei Schlüsselpaare, ein Relais dazwischen, das keine Inhalte kennt und keine Rechte hat.
| Richtung | Frage | Antwort | Dauer |
|---|---|---|---|
| Protokoll-Knoten → Getränke-Knoten | „Cocktails mit anderen Waldfrüchten" | 5 nach Bedeutung sortierte Treffer aus dessen eigenem Bestand (0,83 bis 0,84) | 39 s |
| Getränke-Knoten → Protokoll-Knoten | „wer weiß was über Pilze" | 4 Module aus dessen eigener Bibliothek | 0,5 s |
Eine Frage reist als Frage über das Relais, und eine nach Bedeutung sortierte Antwort kommt aus dem aktuellen Bestand des anderen Knotens zurück. Kein Beteiligter hält einen Index des anderen.
Zu den Zahlen 0,83 und 0,84. Sie sind rohe Kosinus-Werte aus einem anisotropen Modell, und Abschnitt 5.2 erklärt, warum solche Werte einen hohen Boden haben. Als Rangfolge innerhalb einer Antwort sind sie brauchbar. Als absolutes Maß für Verwandtschaft taugen sie nicht.
Das in der Implementierung verwendete Referenz-Prompt-Template ist bewusst minimal gehalten. Implementierende werden ermutigt, es zu erweitern und anzupassen, während sie die Vier-Felder-Eingabestruktur und das Drei-Dimensionen-Ausgabeschema beibehalten.
Es gibt zwei öffentliche Zugänge, und sie zeigen Verschiedenes. Die Vorführungen führen das Verfahren an einem gestellten Fall vor. Die Netz-Karte sieht dem laufenden Netz zu. Sie benutzen auch verschiedene Transporte, und das ist kein Versehen: das Verfahren ist an keinen gebunden.
| Die Vorführungen | Die Netz-Karte | |
|---|---|---|
| Was zu sehen ist | das Verfahren vom Selbstporträt bis zum Bericht, an einem gestellten Fall | welche Knoten sich gerade melden und einander antworten |
| Aufbau | drei Geräte: eines ist der Gastgeber, die beiden anderen treten per QR-Code bei, eines als Anbieter, eines als Suchender | ein Gerät, das nur zusieht |
| Transport | WebRTC, unmittelbar zwischen den Geräten, vermittelt über den Vorgabe-Vermittler von PeerJS | fünf Nostr-Relais, davon drei fremde: relay.damus.io, nos.lol, relay.primal.net |
| Voraussetzungen | Browser, Internet, ein eigener Anthropic-Schlüssel; die Seiten laden drei Bibliotheken von einem CDN | ein Browser, sonst nichts |
| Kann senden | ja, das ist der Zweck | nein |
| Zeitfenster | die Sitzung, solange sie läuft | die letzten dreißig Minuten |
Vorführung Layer 1, Mensch zu Mensch:
https://lausiklauskn-png.github.io/Sage-Protokol/sbkim-demo/demo.html
Vorführung Layer 2, Agentennetz:
https://lausiklauskn-png.github.io/Sage-Protokol/sbkim-demo/sbkim-network.html
Netz-Karte, mitlesend:
https://lausiklauskn-png.github.io/Sage-Protokol/mycel-karte/
Die Netz-Karte kann nicht senden. Der einzige Aufruf, den
sie an eine Verbindung richtet, ist ein Abonnement; ein Ereignis schreibt sie
nie. Das steht im Quelltext und ist in einer Zeile nachzuzählen. Ein
Instrument, das nur lauschen kann, kann den Verkehr nicht hergestellt haben,
den es anzeigt. Sie abonniert die fünf Marken sbkim-rdv,
sbkim-anastomosis, sbkim-anastomosis-reply,
sbkim-query und sbkim-query-reply; jeder Knoten,
der sich meldet, wird gezeichnet, jeder Handschlag zwischen zweien als Faden.
Drei Einschränkungen gehören dazu. Die Karte zeigt ein Fenster von dreißig Minuten; läuft in dieser Zeit kein Knoten, bleibt sie leer. Das ist der Normalzustand eines Netzes ohne Dauerprozess: es läuft, wenn jemand eine der Anwendungen offen hat, und sonst nicht. Zweitens zeigt sie, dass Knoten sich melden und einander antworten, nicht was sie einander antworten. Und drittens hat sie einen Probelauf-Knopf, der im Quelltext und in der Oberfläche ausdrücklich als Simulation gekennzeichnet ist.
Und eine über die Vorführungen. Sie hängen an einem CDN, an einem fremden Vermittler und an einem bezahlten Schlüssel. Das Protokoll selbst braucht nichts davon: die Module aus Abschnitt 6 laufen ohne CDN, ohne Vermittler und ohne Schlüssel. Diese drei Abhängigkeiten gehören der Vorführung, nicht dem Protokoll.
Die passive semantische Entdeckung besteht aus vier Teilproblemen. Zwei davon sind gelöst, zwei nicht.
| Teilproblem | Stand |
|---|---|
| Gemeinsamer Sitzungsbezeichner nötig | entfällt. Die Knoten finden einander über das Relais und ihre signierten Karten |
| Bidirektionale Bedeutungs-Suche zwischen unabhängigen Knoten | belegt am 10.07.2026, siehe Abschnitt 6.2 |
| Verteilter Index mit datenschutzerhaltender Abfrage | zur Hälfte offen. Für die Zustellung an einen bereits bekannten Gegenüber gibt es verschlüsselte Wege, und ein Knoten dieses Netzes benutzt sie; das Relais sieht dann nur Geheimtext. Offen ist die andere Hälfte: um gefunden zu werden, muss eine Frage heute lesbar auf einem gemeinsamen Medium stehen |
| Wirklich passive Entdeckung, also einmal beschreiben und danach fortlaufend bewertet werden | offen, und zugleich ausgeschlossen. Es fragt jemand aktiv an, und das ist eine Entscheidung: die Knoten dieses Netzes stellen von sich aus keine Anfragen ins offene Netz |
Die letzte Zeile ist keine Lücke, sondern eine Regel. Ein Knoten dieses Netzes antwortet, wenn er gefragt wird, und fragt nicht von selbst. Wer die fortlaufende Bewertung baut, hebt diese Regel auf und handelt sich ein, wovor sie schützt: ein Netz, in dem zwanzig Anwendungen unaufgefordert Anfragen stellen. Die Regel ist nicht unantastbar, aber ihre Aufhebung ist eine Entscheidung und kein Nebenprodukt.
Und eine Grenze, die im Betrieb sichtbar wurde. Eine Antwort kommt zuverlässig nur, wenn der Tab des antwortenden Knotens im Vordergrund und wach ist. Handys und Tablets drosseln Tabs im Hintergrund. Eine Wiederhol-Frage auf eine gealterte Karte lief ins Leere, bis der Knoten seine Karte erneuerte. Für einen Dienst, der ohne Zutun antwortet, ist das eine offene Stelle.
LLM-basierte Evaluatoren sind nicht-deterministisch. Zwei Bewertungen desselben Paares können unterschiedliche Scores liefern. Eine produktive SBKIM-Implementierung sollte Konsistenzanforderungen definieren und möglicherweise Ensemble-Bewertung oder deterministische Scoring-Heuristiken verwenden.
Im Gegensatz zu Keyword-Systemen ist SBKIM resistent gegenüber SEO-artiger Manipulation — das Auffüllen einer Selbstbeschreibung mit Keywords verbessert Match-Scores nicht direkt, da der Evaluator Bedeutung bewertet, nicht lexikalische Übereinstimmung. Adversarielle Prompt-Injektion in Selbstbeschreibungen ist jedoch ein bekannter Angriffsvektor und erfordert Eingabebereinigung in Produktivumgebungen.
Damit Layer 2 skaliert, benötigen Agenten ein Standardformat für Selbstbeschreibung.
Wir schlagen vor, dass Agentensysteme einen /.well-known/sbkim.json
Endpunkt mit Fähigkeits- und Bedarfsfeldern bereitstellen — analog zu
robots.txt oder OpenAPI-Schemata. Dies ist noch nicht standardisiert.
SBKIM ist ein minimales, offenes Protokoll zur semantischen bidirektionalen Kompatibilitätsbewertung zwischen zwei natürlichsprachlich beschreibenden Parteien. Es verlangt von beiden Seiten, Fähigkeiten und Bedarf zu nennen.
Der Beitrag dieser Arbeit ist ein Feldbericht. Die Bausteine sind bekannt: der Transport ist geliehen, die Einbettung ist Stand der Technik, die Kryptographie ist Standard, und die Symmetrie ist ein eigenes Forschungsfeld. Neu ist, dass sie zusammen laufen, seit Monaten, in über zwanzig ausgelieferten Anwendungen, die niemand betreibt außer ihren Nutzern. Die gefundenen Vorarbeiten sind Architekturen, Entwürfe und Prototypen. Die Bausteine sind bekannt; der Betrieb ist der Beitrag.
Dazu gehört, was dabei kaputtging. Der hohe Ähnlichkeits-Boden aus Abschnitt 5.2 hätte fast dazu geführt, eine Modell-Eigenschaft als inhaltliche Verwandtschaft zu berichten. Der gedrosselte Hintergrund-Tab aus Abschnitt 7.1 begrenzt bis heute, wofür das Protokoll taugt.
Die Zwei-Ebenen-Architektur zeigt, dass dasselbe Protokoll über Ebenen hinweg anwendbar ist: von zwei Menschen, die einen Vertrag verhandeln, bis hin zu einem Netzwerk von KI-Agenten, die ihre optimale Kollaborationstopologie entdecken. Wir glauben, dass diese Vereinheitlichung nicht-trivial ist und es wert ist, als offener Standard formalisiert zu werden, bevor das Ökosystem auf plattformspezifische Lösungen konvergiert.
Wir veröffentlichen diesen Vorschlag offen und laden zu Implementierungen, Kritiken und Erweiterungen ein. Die Referenz-Implementierung steht unter MIT-Lizenz. Die Protokoll-Spezifikation in diesem Dokument wird als gemeinfrei (Public Domain) freigegeben.
Dieser Text ist mit Hilfe eines Sprachmodells entstanden.
Die redaktionelle Verantwortung liegt bei einer Person, dem Betreiber des beschriebenen Netzes. Er hat die Fragestellung gesetzt, die Belege geliefert und jede Fassung gegengelesen. Die Wendepunkte kamen von ihm: der Auftrag, jeden Bestandteil des Anspruchs gegen die Fachliteratur zu prüfen; die Anweisung, jede Angabe an der Quelle nachzusehen statt sie zu vermuten; und die Vorgabe, als Feldbericht aufzutreten statt mit einem Anspruch, der bei der ersten Rückfrage fällt.
Worin die Prüfung bestand. Die Zahlen in Abschnitt 6.1 stammen aus den Zeitstempeln der Quelltext-Verwaltung und sind dort nachzurechnen. Die Messwerte in Abschnitt 6.2 stammen aus einem Lauf an echten Geräten, mit Datum. Die Vorarbeiten in Abschnitt 2.1 wurden gesucht und geprüft, bevor dieser Text einen Beitrag benennt. Wo eine Angabe nicht nachzuprüfen war, steht sie als Beobachtung da oder gar nicht.
Was das ausdrücklich nicht war. Keine Rechtschreibprüfung und kein Umformulieren eines fertigen Textes. Der Inhalt ist im Wechsel entstanden: Vorschlag, Einwand, Messung, Berichtigung. Mehrere Aussagen sind dabei gefallen, bevor dieser Text zum ersten Mal veröffentlicht wurde.
Wo die Belege liegen. Das Protokoll-Depot aus Abschnitt 6 trägt die Sitzungsprotokolle, die Lehren aus Fehlern und die Prüfblätter zu den Arbeitstagen. Die Historie ist öffentlich und mit Datum versehen.
Wo dieser Text zuerst stand. Das Depot war während der gesamten Entstehung öffentlich zugänglich; die Fassungen dieses Textes sind dort mit Datum und Änderungsverlauf nachzulesen. Die Erstveröffentlichung ist damit das offene Depot selbst: die erste Fassung dieses Textes liegt dort seit dem 18. Mai 2026 und war von der Startseite aus verlinkt. Die Fassung bei Zenodo ist eine Zweitveröffentlichung — sie gibt dem Text eine zitierfähige Adresse und eine feste Fassung, sie ist nicht sein erstes Erscheinen.
Referenzen
[1] Pinecone Systems. „Vector Database for Machine Learning." pinecone.io, 2021.
[2] Chase, H. „LangChain: Building applications with LLMs through composability." GitHub, 2022.
[3] Anthropic. „Model Context Protocol." modelcontextprotocol.io, 2024.
[4] Berners-Lee, T. „Information Management: A Proposal." CERN, 1989.
[5] Richards, M. et al. „AgentProtocol: A common interface for AI agents." agentprotocol.ai, 2023.
[6] Pizzato, L. et al. „RECON: A reciprocal recommender for online dating." RecSys, 2010. — Übersichten zum Feld: Palomares, I. et al. „Reciprocal Recommender Systems: Analysis of state-of-art literature, challenges and opportunities." Information Fusion, 2021.
[7] Crespo, A. und Garcia-Molina, H. „Semantic Overlay Networks for P2P Systems." Springer LNCS, 2004. — Fortführung: „A Semantic Peer-to-Peer Overlay for Web Services Discovery." Springer, ca. 2008.
[8] Google. „Agent2Agent (A2A) Protocol — Agent Card." a2a-protocol.org, v1.0, 2026.
[9] „Agentic Peer-to-Peer Networks: From Content Distribution to Capability and Action Sharing." arXiv:2603.03753, März 2026.
Die Angaben [6] bis [9] wurden über Websuche ermittelt und anhand von Titeln und Zusammenfassungen geprüft, nicht an den Volltexten. Für eine Einreichung ist eine richtige Literaturarbeit nachzuholen.
Kontakt & Ressourcen
Referenz-Implementierung: github.com/lausiklauskn-png/Sage-Protokol
Protokoll-Version: SBKIM-0.1 · September 2026 · Gemeinfrei (Public Domain)