Im Jahr 2012 schrieb ich ein [Postmortem für Plancast](https://markmhendrickson.com/posts/a-postmortem-for-plancast/), ein Startup, bei dem ich drei Jahre lang gearbeitet hatte. Die Prämisse war einfach: Menschen machen Pläne, Pläne sind es wert, geteilt zu werden, und ein Feed über bevorstehende Ereignisse von Menschen, denen Sie vertrauen, würde Dinge ans Licht bringen, von denen Sie nicht wussten, dass Sie sie tun wollten. Es hat nicht funktioniert. Der Artikel ging auf das Warum ein.

Wenn man es zwölf Jahre später noch einmal liest, sind die oberflächlichen Diagnosen immer noch gültig. Es werden zu selten Pläne gemacht, um eine tägliche Ernährungsgewohnheit aufrechtzuerhalten. Das Teilen von Zukunftsplänen führt im Vergleich zum Teilen von Fotos zu schwachen Eitelkeitsschleifen. Da die Pläne ablaufen, ist jeder einzelne Inhalt stundenlang haltbar. Die meisten Pläne sind geografisch lokal, sodass die meisten Pläne Ihres Netzwerks die meiste Zeit irrelevant sind. Und das größte Problem: Menschen möchten nicht aus der Umgebung heraus Kenntnis von Ereignissen haben, zu denen sie nicht persönlich eingeladen wurden. Bewusstsein ohne Einladung fühlt sich wie Ausschluss an. Die meisten Menschen möchten auch nicht jeden Plan mit ihrem gesamten Netzwerk teilen. Es können die falschen Leute auftauchen oder der Raum fühlt sich nicht mehr kontrollierbar an.

Was mir 2012 entgangen ist, war, dass es sich hierbei nicht wirklich um produktmechanische Probleme handelte. Es handelte sich um Substratprobleme. Das damals verfügbare Substrat, ein Feed innerhalb eines zentralisierten sozialen Netzwerks, hatte für keinen von ihnen die falsche Form. Ich habe versucht, das Substrat mit Features zu konstruieren. Der Untergrund hatte in jeder Metrik immer noch eine niedrige Decke.

## Was eigentlich falsch war

Ein Feed ist das falsche Grundelement für die Planfreigabe, weil:

- Ein Feed setzt einen stetigen Strom an Inhalten voraus. Pläne kommen nicht als Stream an.
- Eine Feed-Belohnungsübertragung. Pläne brauchen angesprochene Zielgruppen.
- Ein Feed verfügt über eine Minimierungsfunktion. Plancast wählte „Bald zuerst“ nach Veranstaltungsdatum, soziale Feeds wählten „Neuestes zuerst“ nach Veröffentlichungszeit. In jedem Fall handelt es sich um eine chronologische Sortierung. Pläne profitieren von vielen Abfragefunktionen, und die nützlichen Funktionen (wer geht in Ihr Vertrauensdiagramm, was passt an diesen Donnerstag, wer ist in der Stadt) sind selten überhaupt chronologisch sortiert.
- Ein Feed macht jeden Inhalt für jeden sichtbar, der Ihnen folgt. Pläne brauchen Spielräume.
- Ein Feed behandelt den Konsum als die dem Benutzer zugewandte Oberfläche. Pläne müssen mit anderen Systemen (Kalender, RSVPs, Transit, Wetter) verknüpft werden.
- Ein Feed zentralisiert die Vermittlung. Pläne entstehen grundsätzlich zwischen Menschen.

Sobald diese Liste auf dem Tisch liegt, ist jeder Plancast-Fehler, den ich 2012 genannt habe, ein nachgelagertes Symptom. Das Substrat konnte nicht ausdrücken, was Plan-Sharing eigentlich sein will.

## Das Substrat, das ich brauchte

Der Untergrund, auf dem ich jetzt bauen würde, besteht aus zwei Teilen, von denen 2012 keines in nutzbarer Form existierte.

**Dauerhafter, nur anhängbarer Zustand für persönliche KI-Agenten.** Das ist es, was ich als [Neotoma](https://neotoma.io) erstelle. Jede Beobachtung, die ein Agent macht (ein hinzugefügter Kontakt, ein beantwortetes Ereignis, eine ausgestellte Einladung, eine bestätigte Teilnahme) wird zu einer typisierten Entität mit Herkunft, Schemaeinschränkungen und einem unveränderlichen Verlauf. Der eigene KI-Agent des Benutzers liest und schreibt daraus. Es gibt keinen zentralisierten sozialen Graphen. Der Benutzer besitzt den Staat.

**Ein souveränes Geflecht aus Adressbüchern und Vertrauensbereichen.** Dafür ist [Darkmesh](https://github.com/markmhendrickson/darkmesh) (mein Fork von [Anand Iyer](https://www.anandiyer.com/)s Original) da. Mit Darkmesh kann eine Person mit ausdrücklicher Zustimmung adressierbare Abschnitte ihres Kontexts (bestimmte Kontakte, bestimmte Gruppen, bestimmte Bereiche) auf den Mesh-Knoten anderer Personen veröffentlichen. Die Einwilligung erfolgt am Netzwerkrand. Der Agent eines Absenders kann eine Nachricht nicht in den Status eines Empfängers versetzen, es sei denn, der Mesh-Knoten des Empfängers hat den Bereich des Absenders zugelassen.

Persönliche KI-Agenten kommunizieren über das Netzwerk hinweg miteinander. Geben Sie an, dass ihnen das Leben im eigenen Neotoma jedes Benutzers dauerhaft am Herzen liegt. Es gibt keinen zentralen Server, auf dem alle Pläne gespeichert sind.

## Wie die ursprüngliche Mission handhabbar wird

Der ursprüngliche Plancast-Pitch lautete: zufällige Zusammenkünfte aufgrund des gemeinsamen Bewusstseins für Pläne. Der Fehler bestand darin, zu glauben, dass gemeinsames Bewusstsein aus einem Feed kommen müsse.

Auf diesem neuen Untergrund zerfällt die gleiche Tonhöhe in unterschiedliche Arbeiten.

1. **Die Ereignisaufnahme erfolgt automatisch.** Mein Agent kennt bereits Ereignisse, zu denen ich auf Luma zugestimmt habe, Ereignisse in meinem Kalender und Ereignisse in Bestätigungs-E-Mails von Eventbrite oder Meetup. Es schreibt sie als „Ereignis“-Entitäten mit Herkunft in mein Neotoma. Ich tippe sie nie irgendwo ein.

2. **Die Weitergabe ist einwilligungsgeschützt und erfolgt adressiert.** Wenn ich auf etwas antworte, kann mein Agent Bereiche markieren, die wissen sollten, dass ich gehe. Dies sind keine Feed-Beiträge. Es handelt sich um adressierte Beobachtungen, die durch das Netz nur an Personen weitergegeben werden, deren Knoten meinen Spielraum zugelassen haben.

3. **Discovery ist eine Abfrage, kein Feed.** Die natürlichste Oberfläche für „was in meiner Welt passiert“ ist kein Stream. Das ist eine Frage, die ich meinem eigenen Agenten stelle. *Wer in meinem Vertrauensnetz wird in den nächsten zwei Wochen wohin gehen? Welches dieser Ereignisse passt zu meinem Abend an diesem Donnerstag? Wer ist in der Stadt, den ich seit einem Jahr nicht gesehen habe.* Jede Abfrage wird zum Zeitpunkt des Abrufs über mein Neotoma und alle von meinem Netz zugelassenen Bereiche berechnet. Es gibt kein Futter.

4. **Einladungen sind erstklassig.** Dies ist der Teil, auf dem der Artikel von 2012 bestand, und der Teil, den die meisten Produktversuche übersprungen haben.

## Wie Einladungen eigentlich funktionieren sollten

Plancast hatte zwar explizite Einladungen, diese erfolgten jedoch manuell. Sie standen auf einem Plan, den Ihre Abonnenten bereits sehen konnten. Das Futter war noch die erste Oberfläche. Ein Tag, eine Erwähnung oder Metadaten, die Sie markierten, hatten die gleiche Form: Die Sichtbarkeit in der Umgebung stand an erster Stelle, der persönliche Tipp an zweiter Stelle. Eine echte Einladung soll diese Reihenfolge umkehren.

In diesem Substrat ist eine Einladung eine typisierte Entität im eigenen Staat des Empfängers. Ungefähr:

„
Einladung
  Absender: contact_id
  Empfänger: contact_id
  event_ref: event_id
  Geltungsbereich: „1:1“ | „small_group“ | „co_attending_set“
  note_to_recipient: Zeichenfolge (obligatorisch, nicht leer)
  Beziehungsbasis: String (warum diese Person, warum dieses Ereignis)
  slots_budget_used: Ganzzahl (Budget pro Veranstaltung)
  läuft ab: Zeitstempel
  Conditional_on: optionales Quorum-Prädikat
  Herkunft: Agent / Quelle / Zeitstempel
„

Aus dieser Form ergeben sich einige Dinge.

**Das Substrat verweigert die Zustellung, wenn das Netz den Bereich des Absenders nicht zugelassen hat.** Das tötet kalte Masseneinladungen mit Maschinengeschwindigkeit auf der einzigen Ebene ab, auf der sie getötet werden können: dem Netzwerkrand.

**Einladungsbudgets pro Veranstaltung erzwingen Selektivität.** Jede Veranstaltung verfügt über eine kleine, konfigurierbare Anzahl von Einladungsslots, die ein Absender ausgeben kann. Das Substrat, nicht die Willenskraft, erzwingt: „Benutzen Sie Ihr Adressbuch nicht mit einem Feuerlöscher.“ Die Spannung zwischen Eitelkeit und Selektivität von 2012 wird zu einem Substratparameter.

**Pull mit Vorabfreigabe ist das vorherrschende Muster.** Wenn mein Agent seine Dauerabfrage ausführt, sieht er nur Personen, deren eigene Agenten mich als jemanden gekennzeichnet haben, den sie bei dieser bestimmten Veranstaltung willkommen heißen würden. Der Schnittpunkt zwischen „Wer in meinem Netzwerk geht“ und „Wer würde mich dort willkommen heißen“ ist viel kleiner als „Wer in meinem Netzwerk postet“. Es handelt sich nicht um ein Futtermittel. Es handelt sich um einen berechtigungsgesteuerten Index.

**Persönlicher Kontext ist auf Typebene obligatorisch.** „note_to_recipient“ und „relationship_basis“ sind Pflichtfelder. „Leer“ ist kein gültiger Zustand. Mein Agent kann sie aus meinem Neotoma-Diagramm entwerfen (letzte Überlappung, gemeinsamer Kontext, gemeinsame Kontakte), aber eine vom Menschen bestätigte Linie ist die Standardeinstellung. Darauf deutete der Artikel aus dem Jahr 2012 hin, als er darauf bestand, dass sich die Menschen persönlich eingeladen fühlen wollen. Der Untergrund macht die persönliche Note zu einer strukturellen Anforderung und nicht zu einer optionalen Höflichkeit.

**Die Ablehnung erfolgt stillschweigend und wird nicht zugeordnet.** Die Empfänger antworten mit „Akzeptieren“, „Bestehen“ oder „Bleistift“. Für den Absender ist nur „Akzeptieren“ sichtbar. „Bestanden“ wird zu „Keine Antwort“ ohne Lesebestätigung und ohne Angabe von Gründen. Der Empfänger behält seine private Provenienz. Sie können Ihre eigene soziale Belastung prüfen, ohne sie preiszugeben.

**Quorum ist ein erstklassiges Primitiv.** Der Aufsatz aus dem Jahr 2012 nannte Prokrastination als größten Misserfolg: Menschen halten sich Optionen offen und weigern sich, sich frühzeitig festzulegen. Das Substrat spricht dies direkt mit „conditional_on“ an: „Ich gehe zu X, wenn Aaron und Diwaker sich ebenfalls verpflichten.“ Das Substrat beobachtet das Prädikat und löst es auf. Keine Koordinatorrolle, kein Gruppenchat-Thread, kein Flocken.

**Zusammensetzbarkeit mit dem vorhandenen Ereignisdiagramm.** Wenn eine Einladung angenommen wird, greift der Agent auf die Plattform zu, die das kanonische RSVP besitzt (Luma, Eventbrite, Kalender) und schreibt die tatsächliche Reservierung. Die Neotoma-Entität „attendance_commitment“ bleibt kanonisch für „Wer-vertraut-wer-wohin-geht“. Das RSVP eines Drittanbieters bleibt für den Veranstaltungsort und die Tür kanonisch. Zwei Datensätze, eine Quelle der Wahrheit pro Anliegen, verknüpft.

## Was die Agenten tatsächlich entscheiden

Das obige System funktioniert nur, wenn Agenten lokal nicht triviale Arbeiten ausführen. Die beiden Fragen sind in beiden Richtungen der Schleife konkret.

**Outbound, wer würde diesen Plan begrüßen?** Wenn mein Agent sieht, dass ich zu etwas geantwortet habe, werden meine Kontakte für das Ereignis gewertet, nicht für mich. Nützliche lokale Signale:

- Kontakte, deren Neotoma mit diesem gemeinsame Themen oder gemeinsam besuchte Veranstaltungen trägt,
- Kontakte, mit denen ich im letzten Jahr Ähnliches erlebt habe,
- Kontakte, die sich ausdrücklich für eine Kategorie entschieden haben (mich über Live-Musik in dieser Stadt informieren),
- Kontakte, deren eigener beobachteter Zeitplan oder Standort sich mit dem Ereignisfenster überschneidet.

Der Agent erstellt eine Rangliste der Kandidaten, niemals eine automatische Auslösung. Slot-Budgets werden von mir oder mit meiner Bestätigung ausgegeben und das Feld „relationship_basis“ wird aus derselben Bewertung ausgefüllt, sodass ich sehen kann, warum eine Person vorgeschlagen wurde, bevor ich sie sende.

**Eingehend, welche Pläne, die durch das Netz kommen, sind es wert, an die Oberfläche zu kommen.** Mein Agent führt die symmetrische Abfrage gegen eingehende Einladungen und gegen Umgebungs-Anwesenheitsbeobachtungen durch, die von meinem Bereich zugelassen werden. Lokale Signale:

- wie oft ich in letzter Zeit gemeinsam mit den beteiligten Personen teilgenommen habe,
- ob das Thema zu einer Kategorie passt, mit der ich mich weiterhin beschäftigt habe,
- ob mein eigener Kalender Platz hat,
- ob sich ein Kollegium bildet, das mir am Herzen liegt.

Die meisten eingehenden Pings werden archiviert und nicht angezeigt. Diejenigen, die auftauchen, enthalten einen eigenen kurzen Absatz des Agenten, in dem erläutert wird, warum dieser und nicht die anderen.

Beide Richtungen sind schwer zu bewältigen und beide bleiben lokal. Es gibt keinen zentralen Ranglistenplatz. Der Agent jedes Benutzers berechnet anhand des Status, den dieser Benutzer besitzt, und die Bewertung kann von diesem Benutzer überprüft werden. Dadurch wirkt das Erlebnis wie eine Infrastruktur, die in Ihrem Namen agieren kann, ohne zu einer Plattform zu werden.

## Wie sich Beziehungen wie beobachtet entwickeln

In einem Feed ist Ihr Beziehungsdiagramm nach der Erstellung größtenteils statisch. Du folgst Leuten, entfolgst ihnen selten und alles andere ist Signalrauschen, das die Plattform für dich interpretiert. In diesem Substrat wird der Graph durch Beobachtungen geformt.

Jeder getippte Schreibvorgang verschiebt eine Beziehung ein wenig. Eine gesendete Einladung verschiebt die Kante in eine Richtung. Eine angenommene Einladung bringt es weiter. Die von beiden Agenten erfasste Anwesenheitsüberschneidung verschiebt den Wert noch weiter. Ein aufgezeichnetes Gespräch, eine geteilte Notiz oder eine Projektentität, die beide Knoten berühren, hinterlässt jeweils eine Beobachtung am Rande zwischen zwei Kontakten, mit Herkunft und einem Zeitstempel.

Das Umgekehrte gilt auch. Kanten verfallen, wenn nichts passiert. Ein Kontakt, den Sie ein Jahr lang nicht eingeladen, mit dem Sie nicht teilgenommen haben oder über den Sie nicht geschrieben haben, ist eine andere Art von Vorteil als der Kontakt, den Sie letztes Wochenende gesehen haben. Der Verfall ist keine Löschung. Der Verlauf steht immer noch zum Abruf bereit. Aber die Relevanzbewertung des Agenten morgen verwendet die aktuelle Gewichtung, sodass ein Jahr Schweigen die Sichtbarkeit kostet, bevor es die Beziehung selbst kostet.

Dadurch wird das Feed-Modell in der gewünschten Weise umgekehrt. Feeds machen das Diagramm zur Eingabe und die Aktivität zur Ausgabe. Dieses Substrat macht die Aktivität zur Eingabe und den Graphen zur Ausgabe. Beziehungen entwickeln sich, weil Verhalten ein strukturierter Zustand ist, und nicht, weil jemand 2014 einmal auf „Folgen“ geklickt hat und die Plattform seitdem so tut, als bedeute Edge immer noch etwas.

## Was das nicht ist

Dies ist kein Versuch, von Menschen verfasste Einladungen zu ersetzen. Die Aufgabe des Substrats besteht darin, den Versand einer handgeschriebenen Einladung günstiger zu machen, die Wahrscheinlichkeit zu erhöhen, dass sie ankommt, und das Spam-Versand zu erschweren. Jede darüber liegende Ebene soll die Erfahrung auf das zurückführen, was ich 2012 richtigerweise als die tatsächliche soziale Währung identifiziert habe: Jemand, dem Sie vertrauen, hat speziell an Sie gedacht. Das Substrat kann diesen Gedanken nicht herstellen. Sie kann die Lieferung von Ersatzlieferungen verweigern.

## Was ist noch offen

Auf ein paar Dinge habe ich noch keine guten Antworten.

- Wie Einladungsbudgets benannt und erneuert werden sollten. Pro Veranstaltung, pro Woche, pro Mesh? An die Akzeptanzrate gebunden?
– Wie sich Änderungen des Netzbereichs ausbreiten, wenn sich Beziehungen ändern. Wie sieht es aus, einen Geltungsbereich zu widerrufen, ohne eine Beziehung zu zerstören?
- Cross-Mesh-Interop, wenn Teilnehmer unterschiedliche Mesh-Implementierungen ausführen. Ist eine dünne Protokollschicht erforderlich?
- Umgang mit Missbrauch, wenn ein zuvor zugelassener Absender mit dem Spam beginnt. Wer wendet die Strafe an, der Mesh-Knoten des Empfängers oder das Substrat als Ganzes?
– Migrationsgeschichte für Veranstaltungen, deren kanonisches RSVP hinter einer Paywall oder einem Login liegt.

Dies sind echte Fragen, aber es handelt sich um Produkt- und Protokollfragen auf einem bereits funktionierenden Substrat. Sie sind keine architektonischen Unbekannten.

## Warum ich das jetzt schreibe

Vor ein paar Wochen hinterließ Oo Nwoye einen öffentlichen Kommentar zu einem [aktuellen Artikel](https://markmhendrickson.com/posts/) über das Agentengedächtnis und fragte in so vielen Worten, ob Plancast für das KI-Zeitalter wiederbelebt werden sollte. Die Antwort ist dieselbe wie oben. Die ursprüngliche Mission war richtig. Der Untergrund war falsch. Das Substrat ist nun vorhanden.

Ich glaube nicht, dass die Antwort darin besteht, Plancast als App neu zu erstellen. Die Antwort besteht darin, Einladungen, Anwesenheits- und Vertrauensbereiche als Grundelemente auf einer souveränen persönlichen Zustandsebene aufzubauen, Agenten die Arbeit der Aufnahme und Weiterleitung übernehmen zu lassen und den sozialen Mechanismus aus der Tatsache entstehen zu lassen, dass es sich bei einer Einladung um ein getipptes Schreiben in einen dauerhaften Zustand und nicht um ein Ambient-Feed-Ereignis handelt.

Wenn Sie in dieser Nachbarschaft etwas gebaut haben oder bauen, würde ich gerne mit Ihnen sprechen.