Ein Benutzer fügt die vom Agenten geführte Bewertungsaufforderung in seinen Editor ein. Der Agent liest die [Neotoma-Bewertungsseite](https://neotoma.io/evaluate), scannt den lokalen Workflow, entscheidet, dass die Übereinstimmung gut ist, führt die Installation aus und speichert die ersten paar Entitäten. Einige Zeit später stößt es auf einen echten Fehler – eine Entitätsübermittlung löscht stillschweigend ein Feld, das das Schema eindeutig akzeptiert. Etwas später bemerkt es noch etwas anderes: Der Abruf über einen großen Entitätsgraphen ist langsamer, als es für den unterstützten Workflow sein sollte. Und noch später, beim Erstellen einer benutzerdefinierten Abrufschleife, stellt es fest, dass auf der MCP-Oberfläche eine Stapeloperation fehlt, die das ständig wiederholte Muster viel sauberer machen würde. Der Benutzer hat nie danach gefragt. Der Agent bemerkte es auf dem Weg, etwas anderes zu tun. Die alte Form dieser Momente war das Ende der Schleife. Der Benutzer könnte GitHub öffnen, den Fehler oder die Anfrage einfügen, einen Kontextabsatz schreiben und warten. Die meisten nicht. Sie umgehen das Problem, der Betreuer sieht es nie und der nächste Benutzer stößt an dieselbe Wand. Neotoma verfügt jetzt über ein erstklassiges Issues-Subsystem, das über dieselbe MCP-Oberfläche arbeitet, die jeder Agent bereits zum Speichern und Abrufen verwendet. Der Agent reicht Fehler, Leistungsbeobachtungen und Verbesserungsanfragen ein, ohne die Sitzung zu verlassen und ohne anzuhalten, um nach einzelnen Problemen zu fragen. Die Agenten des Betreuers holen sie ab, selektieren sie, lösen sie häufig und versenden sie. Der Agent des Reporters liest den Status zurück und teilt dem Benutzer mit, wenn etwas landet. Der gesamte Austausch erfolgt über Tool-Aufrufe. Die von Agenten durchgeführte Bewertung, über die im [Beitrag zur Kundenforschung](/posts/customer-research-through-agents) geschrieben wurde, war die erste Hälfte dieser Schleife. Das Issues-Subsystem ist die hintere Hälfte. Beide Hälften laufen auf dem [Nervensystem-Substrat](/posts/from-memory-to-nervous-system), das ich zuvor beschrieben habe, und die Problemfunktion ist das bisher sauberste Beispiel dafür, wozu dieses Substrat dient. ## Warum sich die Schleife auf der Agentenseite schließen muss Reibung ist der stille Killer von Feedback. Das alte Modell ging davon aus, dass der Benutzer seine Erfahrungen in einen Bericht auf einem separaten System umwandeln würde: Kontext wechseln, das Repo finden, eine Issue-Vorlage analysieren, genügend Hintergrundinformationen schreiben, damit ein Betreuer handeln kann, Protokolle anhängen, warten. Jeder Schritt ist eine Chance aufzugeben. Die meisten tun es. Und dieses Modell deckt nur Probleme ab, die der Benutzer bemerkt hat. Es gibt überhaupt keinen Pfad für Probleme, die der Agent bemerkt hat und die der Benutzer nie aufgetaucht ist. Der Agent eines Gutachters stellte fest, dass die Aktivierung einen Hydratationsfehler verursachte, als seine Substratkonfiguration auf eine selbst gehostete Instanz hinter einem Cloudflare-Tunnel verwies. Der Agent hat eine genaue Zusammenfassung geschrieben, einschließlich des fehlerhaften Endpunkts und der Antwortheader. Der Benutzer hat mir die Zusammenfassung als Nachricht weitergeleitet. Ich habe den Kontext neu erstellt, ihn an meine Agenten weitergeleitet, eine Veröffentlichung versendet und dem Benutzer eine Nachricht geschickt. Der Benutzer hat seinen Agenten um eine Bestätigung gebeten. Diese Überprüfung dauerte etwa neunzig Sekunden. Die menschlichen Staffelschritte dauerten Tage. Die ursprüngliche Zusammenfassung des Maklers war gut. Es war der Wiederaufbaukontext, der die Zeit verschlang. Bei jeder Übergabe zwischen einem Agenten und einem Menschen geht die Treue verloren. Bei jeder Übergabe zwischen einem Menschen und einem anderen Agenten wird der Kontext von Grund auf neu erstellt. Umfangreiche, vom Agenten verfasste Details werden zu knapper, von Menschen verfasster Prosa komprimiert, und dann muss ein nachgeschalteter Agent sie wieder erweitern. Wenn der Agent des Benutzers derjenige ist, der an die Wand gestoßen ist – oder die Langsamkeit bemerkt hat oder die fehlende Fähigkeit wollte – ist der Übersetzungsschritt kostenlos. Der Agent verfügt bereits über den Kontext: welches Tool er ausgeführt hat, der genaue MCP-Aufruf, der fehlgeschlagen ist oder sich unangenehm anfühlte, die Antwortnutzlast, die Git-SHA- oder App-Version der Neotoma-Installation, den beteiligten Entitätstyp. Es erstellt einen zusammenhängenden Bericht in einem Tool-Aufruf. Die MCP-Anweisungen weisen Agenten an, sofort über „submit_issue“ einzureichen, wenn ein meldepflichtiges Problem oder eine Verbesserungsmöglichkeit bestätigt wird, ohne nach einzelnen Problemen zu fragen – die pro-Problem-Eingabeaufforderung fügt keine neuen Informationen hinzu und unterbricht alle Aktionen des Benutzers. Die Agentendateien. Der Benutzer erfährt davon später oder nie, je nachdem, ob die Änderung jemals versendet wird. Auf Seiten des Betreuers muss sich die Schleife schließen, ohne dass ich jeden Bericht von Hand lese. Ich betreibe etwa ein Dutzend Agenten über Editoren und Daemons hinweg. Sie verarbeiten bereits eingehende strukturierte Zustände. Die natürliche Form ist: Ein neues Problem trifft ein, das Substrat signalisiert beim Schreiben, ein Triage-Daemon nimmt das Ereignis auf, liest das Problem, entscheidet, ob es handeln kann, öffnet einen Arbeitsbaum, führt eine Agentensitzung für die Codebasis durch und behebt entweder den Fehler oder bittet den Reporter über denselben Thread um Klärung. Beide Hälften der Schleife laufen als Agent über dasselbe Substrat. Der Agent des Benutzers verwendet MCP zum Senden. Die Agenten des Betreuers verwenden MCP zum Lesen und Antworten. Niemand muss einen Browser öffnen. ## Was der Agent bei der Übermittlung tut Die MCP-Oberfläche ist klein genug, um sie aufzuzählen. Das Tool „submit_issue“ benötigt einen Titel, einen Text, einen Entitätstyp, wenn es sich bei dem Problem um eine bestimmte Art von Datensatz handelt, und einen Reporter-Umgebungsblock – den Git-SHA, den der Benutzer ausführt, oder die App-Version, wobei letztere serverseitig automatisch ausgefüllt wird, wenn der Agent beides weglässt. Die Reporterumgebung hat mehr Gewicht, als es den Anschein hat; Im nächsten Abschnitt erfahren Sie, warum. Berichte kommen selten ohne Kontext. Ein Fehler verweist auf konkrete Entitäten: den spezifischen Datensatz, der nicht gespeichert werden konnte, sein Schema, eine vorgelagerte Beobachtung. Eine Erweiterungsanforderung verweist auf das Aufrufmuster, das sie vereinfachen würde, oder auf den Entitätstyp, den sie schneller abrufbar machen würde. „submit_issue“ und „add_issue_message“ akzeptieren ein „entity_ids_to_link“-Array und der Server erstellt „REFERS_TO“-Beziehungen vom neuen Issue zu jeder referenzierten Entität atomar als Teil desselben Aufrufs. Das Problem ist bereits in der Grafik verankert, um die es geht. Der Triage-Agent, der das Problem liest, kann direkt zu der Entität wechseln, bei der der Fehler aufgetreten ist. Die Übermittlung durchläuft denselben PII-Schutz „scanAndRedact“, der jede öffentliche Oberfläche schützt. Wenn der Agent versehentlich ein Token oder eine E-Mail-Adresse in den Textkörper einfügt, wird dieser vor der Persistenz geschwärzt. Die MCP-Anweisungen erfordern, dass Agenten vor dem Anruf die PII-Checkliste auf Titel und Text anwenden, aber der serverseitige Wächter ist die eigentliche Verteidigungslinie. Der Reporter erhält eine numerische Problemkennung und ein Gast-Rücklesetoken mit einer expliziten TTL, die auf den Thread beschränkt ist, den er gerade geöffnet hat. Mit diesem Token liest der Agent des Reporters später den Status, ohne sich jedes Mal erneut zu authentifizieren. Aus der Sicht des Benutzers: ein Tool-Aufruf, eine zu verfolgende Kennung und normalerweise überhaupt keine Genehmigungsaufforderung. Aus Sicht des Substrats wurde eine strukturierte Entität geschrieben, die Beziehungen zwischen verknüpften Entitäten wurden in derselben Transaktion erstellt, eine Quellzeile wurde erstellt, ein Gastzuschuss wurde erteilt und die Schreibpipeline gab ein Ereignis aus. ## Provenienz ist der unbesungene Held Die Anforderung an die Reporterumgebung scheint ein kleines Detail zu sein. Es ist die wichtigste Veränderung. Bevor das Issues-Subsystem existierte, konnte ein Bericht ohne Verweis auf den Build übermittelt werden, für den er erstellt wurde. Für ein Papierticket ist das in Ordnung. Für eine automatisierte Triage-Schleife ist das katastrophal. Wenn ein Agent beim Commit „abc1234“ einen Fehler meldet und meine Agenten ihn beim Commit „def5678“ beheben, muss der Agent des Benutzers wissen, gegen welchen Build er prüfen muss. Wenn sich ein Debugging-Thread über drei Builds erstreckt, muss in jedem Kommentar angegeben werden, in welchem ​​Build er getestet wurde. Das Gleiche gilt für eine Verbesserungsanforderung: Wenn ich weiß, welche Version der Agent ausführte, als er den fehlenden Batch-Vorgang identifizierte, kann ich feststellen, ob die Lücke bereits in einem späteren Build behoben wurde oder tatsächlich offen ist. Ohne Herkunft wird der Thread zur Archäologie. „submit_issue“ lehnt jede Einreichung ab, in der sowohl „reporter_git_sha“ als auch „reporter_app_version“ fehlen. Im Ablehnungsumschlag sind die Alternativen explizit aufgeführt: „json { „error_code“: „ERR_REPORTER_ENVIRONMENT_REQUIRED“, „Details“: { "acceptable_field_groups": [ ["reporter_git_sha"], ["reporter_app_version"] ] } } „ „add_issue_message“ akzeptiert dieselben Felder und gibt eine Serverwarnung in öffentlichen Threads aus, wenn beide fehlen. Jede Nachricht, die ein Debug-Agent verfasst, zeichnet den zu testenden Build auf. Der Grund dafür, dass dies für die Agent-zu-Agent-Verarbeitung wichtig ist, besteht darin, dass die empfangende Seite den Bericht klassifizieren kann, bevor sie irgendwelche Arbeiten ausführt. Bei einem Fehler: Hat der Benutzer eine veröffentlichte Version ausgeführt? Verzweigen Sie von „main“ und öffnen Sie eine PR. Ein bestimmtes Commit für einen Feature-Zweig? Erstellen Sie bei diesem Commit einen Arbeitsbaum, reproduzieren Sie die Ergebnisse und melden Sie sie, ohne die Hauptzeile zu ändern. Ihre eigene Gabel? Veröffentlichen Sie ein strukturiertes Follow-up und fragen Sie nach der Patch-Quelle. Zur Verbesserung: Befindet sich die angeforderte Funktion bereits in einem Zweig oder fehlt sie tatsächlich? Steht es im Konflikt mit einer Designbeschränkung, die der Agent, der es einreicht, nicht sehen kann? Die Klassifizierung bestimmt die Reaktion – und nichts davon ist ohne Herkunft möglich. Die Herkunft ist das, was einen Bericht in freier Form in ein weiterleitbares Ereignis verwandelt, unabhängig davon, ob er etwas kaputtes oder fehlendes beschreibt. ## Was passiert auf der Betreuerseite? Mein Triage-Daemon abonniert Ausgabeerstellungsereignisse über dieselben „Abonnieren“-Tools, die jeder andere Verbraucher verwenden würde. Webhooks stehen an erster Stelle, da sie sowohl für Remote-Daemons auf einem VPS als auch für lokale Prozesse auf meinem Laptop funktionieren. SSE ist additiv. Das Substrat verwaltet die Registrierung, übermittelt das Ereignis und vergisst es. Der Dämon entscheidet. Der Daemon, den ich dafür ausführe, heißt Formica. Gattung _Formica_, Ameisen. Jeder Subagent ist ein Arbeiter, der eine Arbeit vom Ereignisprotokoll zu einem Fix überträgt. Was es in der Praxis bewirkt: Lesen Sie die Ausgabe. Rufen Sie die Entitäten ab, die der Agent des Reporters zum Zeitpunkt der Übermittlung verknüpft hat, da die Beziehungen bereits im Diagramm vorhanden sind. Spiegeln Sie auf das Upstream-GitHub-Repo, wenn es einen öffentlichen Trail erfordert, wobei die PII-Schwärzung an der API-Grenze angewendet wird und jedes Problem, dessen Titel oder Text noch mit einem Schwärzungsmuster übereinstimmen, abgelehnt wird, bevor es die Grenze überschreitet. Klassifizieren Sie, ob es sich bei dem Bericht um einen Fehler oder eine Verbesserung handelt. Bei Fehlern: Entscheiden Sie, ob der Fehler allein aus der Reporterumgebung reproduziert werden kann, und übergeben Sie ihn dann an einen „/process-issues“-Skill, der einen Arbeitsbaum öffnet, eine Agentensitzung ausführt und versucht, ihn zu beheben. Für Verbesserungen: Synthetisieren Sie eine Planeinheit, die die Anfrage mit allen zugehörigen offenen Problemen zusammenfasst, und stellen Sie sie zur menschlichen Überprüfung bereit, anstatt eine autonome Implementierung zu versuchen. Wenn für einen der beiden Typen mehr Kontext benötigt wird, stellen Sie über „add_issue_message“ eine klärende Frage, damit der Agent des Reporters diese bei der nächsten Statusablesung erhält. Der Skill „/process-issues“ steuert die eigentliche Fehlerbehebung. Der Vertrag ist kurz. Für jede offene Ausgabe: - Laden Sie den Schnappschuss, den Konversationsthread und die Reporterumgebung. - Klassifizieren Sie die Reproduktionsumgebung als „public_release“, „local_commit“, „local_branch“ oder „unknown“. - Wenn unbekannt oder widersprüchlich, rufen Sie „add_issue_message“ mit einer strukturierten Anfrage nach den fehlenden Details auf und markieren Sie den Plan als „awaiting_input“. - Andernfalls synthetisieren Sie eine „Plan“-Entität, die mit dem Quellproblem und den relevanten Konversationsnachrichtenzeilen verknüpft ist. - Wenn der Plan Schema, Sicherheit, Grundlagendokumente oder eine unklare architektonische Grenze berührt, halten Sie inne und fragen Sie nach. Nicht ausführen. - Wenn die Ausführung sicher ist und vom Berichtsmodus zugelassen wird: Verzweigen Sie von „main“ für eine öffentliche Release-Reproduktion und öffnen Sie eine PR, oder erstellen Sie einen getrennten Git-Arbeitsbaum für eine lokale Reproduktion und geben Sie den Pfad an. Subagenten verteilen sich mit einer Parallelitätsobergrenze von vier, ein Problem pro Subagent. Der Skill berücksichtigt „reporting_mode“: „off“ generiert und speichert nur Pläne, „consent“ fragt vor der Ausführung ab, „proactive“ führt sichere Pläne autonom aus. Drücken Sie niemals auf „Main“. Verwenden Sie niemals „--no-verify“. Ändern Sie niemals einen Push-Commit. Der Schwärzungsleckschutz wird ausgeführt, bevor ein öffentliches Artefakt aus einem privaten Problem erstellt wird. Sichere Standardeinstellungen bleiben aktiviert: - „dry_run: true“ für die erste Ausführung eines neuen Problemtyps, damit ich sehe, was passieren würde, bevor etwas geschrieben wird. - „auto_fix: false“, sodass nichts eine PR verschiebt oder öffnet, bis ich sie über den Operatortransport bestätige. - „max_prs_per_hour: 5“, damit sich eine Flut verwandter Probleme nicht in eine Flut von Zweigen ausbreiten kann. - „dirty_tree_policy: abort“, damit ein veralteter Checkout nie als Basis verwendet wird. - Ein Kill-Switch über eine „daemon_config“-Entität in Neotoma mit „active: false“, sodass ich die gesamte Verarbeitung von einem einzigen Neotoma-Schreibvorgang aus anhalten kann, ohne den Host-Rechner zu berühren. Erwähnenswert ist das Bedienertransportstück. Formica unterstützt ein Telegram-Backend, das „human_needed“-Übergaben und „/shipit“-Befehle zum Fortsetzen anzeigt, wenn „auto_fix“ deaktiviert ist. Auf der Zulassungsliste stehende Telegram-Nachrichten werden als „conversation_message“-Zeilen in Neotoma gespiegelt, sodass sogar mein menschliches Hin und Her mit dem Daemon im selben Substrat erfasst wird. Der Prüfpfad ist durchgängig. Der Pfad „add_issue_message“ hat mich überrascht, als ich anfing, ihn zu verwenden. Es handelt sich nicht um ein Kommentarsystem. Es handelt sich um einen strukturierten Nachrichtenkanal zwischen dem Reporter eines Problems und der Betreuerseite, der über dieselben Konversationsprimitive gefädelt wird, die bereits für Agent-zu-Agent-Threads vorhanden sind. Der Agent des Reporters kann auf eine klärende Frage antworten, ohne dass der Mensch sie zwischendurch lesen muss. Öffentliche Threads verfügen über die gleiche PII-Redaktion, und Fälle mit teilweisem Erfolg (GitHub-Spiegelung akzeptiert, lokales Anhängen fehlgeschlagen oder umgekehrt) tauchen als strukturierter Fehler in der Antwort auf, anstatt stillschweigend doppelte Kommentare zu erzeugen. Wenn ein Fix gefunden wird, schließt derselbe Daemon, der den Bericht sortiert hat, das Problem oder schließt mehrere auf einmal in großen Mengen, wenn ein einzelner PR einen Cluster gelöst hat. ## Was der Agent des Reporters beim Zurücklesen macht Die andere Seite der Schleife ist das Lesen. Der Agent des Reporters ruft „get_issue_status“ mit der Problemnummer oder der Entitäts-ID auf. Es empfängt den aktuellen Status, die Nachrichten im Thread, die Auflösung, falls vorhanden, und den Link zum Upstream-Spiegel, falls die Betreuerseite sich für eine Eskalation entschieden hat. Der Gast-Token authentifiziert den Lesevorgang, ohne dass sich der Benutzer anmelden muss. Wenn das Token abgelaufen ist, gibt das Substrat eine saubere 401 zurück, anstatt stillschweigend auf anonymen Zugriff herabzustufen. Der Agent entscheidet, ob der Status dem Benutzer angezeigt wird. Wenn sich seit der letzten Überprüfung nichts geändert hat, bleibt es ruhig. Wenn eine klärende Frage eingetroffen ist, wird diese dem Benutzer gestellt. Wenn das Update ausgeliefert wurde, teilt es dem Benutzer mit, ruft optional die neue Version ab und bietet an, alles erneut auszuführen, was beim ersten Mal kaputt gegangen ist. Das aktuelle Lesemodell für die Reporterseite ist Pull – der Agent prüft, wann es einen Grund dafür gibt – Push ist jedoch heute über dieselben Abonnementtools verfügbar, die der Daemon des Betreuers verwendet. Abonnements können auf eine bestimmte Entitäts-ID beschränkt werden, sodass der Agent eines Reporters Interesse an dem gerade eingereichten Problem bekunden und im Verlauf des Threads die Ereignisse „entity.updated“ und „observation.created“ empfangen kann. Was fehlt, ist der ergonomische Kleber: Die MCP-Anweisungen weisen die Agenten noch nicht an, sich automatisch anzumelden, nachdem „submit_issue“ zurückgegeben wird. Bis dahin bleibt die Reporterseite standardmäßig im Pull-Modus; Die Agenten des Betreuers werden bereits bei Substratereignissen aktiviert. Die volle Reaktionsfähigkeit auf beiden Hälften ist nur eine Befehlsänderung entfernt. ## Warum das Nervensystem in Aktion ist Das Substrat gibt nach jedem Schreibvorgang Ereignisse aus. Das ist das Einzige, was der Untergrund tun muss, damit dies funktioniert. Alles andere ist die Logik der operativen Ebene, die darüber läuft: der Triage-Daemon, der GitHub-Spiegel, das Gast-Rücklesen, die Thread-übergreifende Deduplizierung, die PII-Redaktion. Dies ist die Zeile, für die ich [im Beitrag zum Nervensystem argumentiert habe](/posts/from-memory-to-nervous-system) und sie hält unter dem Anwendungsfall „Probleme“ stand. Das Substrat entscheidet nicht, welche Probleme von Bedeutung sind, wiederholt keine Zustellungsversuche mit Eskalation und abonniert seine eigenen Ereignisse nicht. Es signalisiert. Der Triage-Daemon ist ein Konsument, der Agent des Reporters ist ein Konsument, der GitHub-Spiegel ist ein Konsument. Jeder Verbraucher registriert Interesse, entscheidet, was zu tun ist, und handelt. Wenn ich einen zweiten Triage-Daemon hinzufügen möchte, der Sicherheitsberichte anders behandelt, abonniert er dieselben Ereignisse mit einem anderen Filter. Kein neues Substratverhalten. Der biologische Rahmen gilt. Das Substrat ist das Gehirn plus Sinnesnerven: Es speichert das Problem und übermittelt das Signal, dass ein Problem angekommen ist. Der Triage-Daemon und der Agent des Reporters sind das Motorsystem: Sie entscheiden, was mit dem Signal geschehen soll. Eine Version von Neotoma, die versucht, alle drei zu vereinen, wäre schwieriger zu begründen und schwieriger zu erweitern. Eine Version, die beim Signalisieren stoppt, bleibt neutral. ## Die Schleife erben Die von mir beschriebene Form basiert auf Neotomas eigenen Problemen, aber dem Substrat ist das egal. Alles, was darauf aufgebaut ist, übernimmt größtenteils die gleichen Maschinen. Die generische Seite der Einreichung ist bereits vorhanden. „submit_entity“ akzeptiert Berichte für beliebige Entitätstypen, wenn der Operator eine „submission_config“-Zeile gesetzt hat, die dies autorisiert. Es gelten die gleiche Gast-Token-Gewährung, das gleiche Konversations-Threading und der gleiche „add_entity_message“-Folgekanal. „subscribe“ akzeptiert jeden Entitätstyp als Filter, sodass ein Drittbetreiber seinen eigenen Triage-Daemon ausführen kann, indem er Interesse an seinen benutzerdefinierten Typen registriert und auf „entity.created“- und „entity.updated“-Ereignisse genau so reagiert, wie Formica auf Probleme reagiert. Was das in der Praxis bedeutet: Wenn Sie eine Content-Pipeline, einen Abgleichsdienst oder ein anderes Produkt betreiben, dessen Benutzer Agenten ausführen, können Sie diese Agenten zulassen, strukturierte Berichte für Entitäten einzureichen, die Ihnen gehören – eine fehlgeschlagene Pipeline-Ausführung, ein falsch klassifizierter Datensatz, eine Abgleichsanfrage – und diese auf Ihrer Seite über denselben Abonnementmechanismus abholen. Der Draht ist allgemein. Einige Stücke beziehen sich auch heute noch speziell auf Neotomas eigene Themen. Der PII-Redaktionsschutz ist derzeit an den Pfad „submit_issue“ gebunden, nicht an den generischen Pfad „submit_entity“. Die GitHub-Spiegelung ist problemspezifisch. Bei beiden handelt es sich um Ergänzungen auf der Betriebsebene, die ein Drittbetreiber selbst verkabeln würde. Das Substrat verarbeitet die Teile, die einheitlich sein müssen – Herkunftsdurchsetzung, Erstellung atomarer Beziehungen, auf den Thread beschränkter Gastzugriff, Ereignisemission bei jedem Schreibvorgang. Die Teile, die davon abhängen, worum es in dem Bericht geht, sind die, mit denen der Betreiber seinen Lebensunterhalt verdient. Das Issues-Subsystem ist der erste vollständige Konsument eines allgemeineren Musters. Die gleiche Form gilt für jedes strukturierte Signal, das ein Agent möglicherweise an das System zurücksenden möchte, gegen das er arbeitet. ## Warum menschliche Bewertungen bestehen bleiben Zwei Dinge verleiten mich dazu, „auto_fix: true“ zu verkabeln und alles auszuliefern, was der Daemon produziert. Der erste ist Bequemlichkeit. Eine grüne Pipeline, die Probleme schließt, während ich schlafe, ist zufriedenstellend. Der zweite Grund ist die Tatsache, dass für einen bedeutenden Teil der Probleme der Agentenplan und der Unterschied korrekt sind. Ich habe jetzt genug davon gesehen, um zu wissen, dass der Fehlermodus normalerweise nicht „falsche Lösung“ ist. In der Regel handelt es sich um eine „Korrektur für den falschen Bereich“, die bei einer Codeüberprüfung in 30 Sekunden erkannt wird. Ich lasse die menschliche Überprüfung dabei, weil Agenten gelegentlich getrost falsche Entscheidungen treffen, deren nachgelagerte Konsequenzen sie nicht erkennen können. Eine Schemamigration, die den fehlgeschlagenen Test erfüllt, aber eine nicht verwandte Integration unterbricht. Eine Redaktionsoptimierung, die das unmittelbare Leck behebt, aber einen damit verbundenen Schutz lockert. Eine Abhängigkeitserweiterung, die den Buildfehler behebt und das Standardverhalten einer Abfrage stillschweigend ändert. Erweiterungswünsche verschärfen dies noch weiter. Ein Fehler hat eine Grundwahrheit – entweder wird das Feld gelöscht oder nicht. Eine Verbesserung ist ein Designanspruch, der Annahmen über Nutzungsmuster, architektonische Einschränkungen und Kompromisse enthält, die der Berichterstatter nicht vollständig erkennen kann. Das Signal ist wertvoll; Es zeigt echte Reibung, keine eingebildete Reibung. Aber die Entscheidung darüber, was damit geschehen soll, liegt bei einem Menschen, der das Gesamtbild sehen kann. Die Entscheidungen, die einen Menschen erfordern, sind diejenigen, bei denen die Kosten für Fehler hoch und die Kosten für Langsamkeit niedrig sind. Das sind die Zusammenführungen – nicht die Pläne, die Patches, die Tests oder die PR-Beschreibungen. Agenten kümmern sich um alles andere. Agenten schlagen vor; Der Mensch entscheidet. ## Die Agentenschleife von Ende zu Ende Lesen Sie neben dem Kundenforschungsbeitrag, die Form ist jetzt lesbar. Die vordere Hälfte: Der Agent des Benutzers bewertet Neotoma anhand seines tatsächlichen Arbeitsablaufs und installiert es, wenn es passt. Die hintere Hälfte: Der Agent reicht Fehler, Leistungsbeobachtungen und Verbesserungswünsche ein, sobald er auf sie stößt, und der Betreuer behebt sie – oft bevor der Benutzer sich daran erinnert, dass etwas davon eingereicht wurde. Beide Hälften arbeiten mit Agenten, die über eine strukturierte Oberfläche mit Agenten sprechen. Die Reibung, die in der Vergangenheit sowohl die Erfassungsschleife als auch die Rückkopplungsschleife zum Erliegen brachte, ist verschwunden, da jeder Übersetzungsschritt in einen Tool-Aufruf integriert wurde. Keine der beiden Hälften wäre ohne das darunter liegende Substrat möglich: Die agentengesteuerte Bewertung erfordert einen strukturierten Status über den Arbeitsablauf des Benutzers, und das Problemsubsystem benötigt Ereignissignalisierung sowie Gastzugriff über Vertrauensgrenzen hinweg. Beide hängen von denselben Grundelementen ab. ## Was ich nicht baue Die Versuchung im Issues-Subsystem besteht darin, in Richtung Orchestrierung abzudriften: ein Priorisierungsmodell, automatische SLA-Verfolgung, ein „intelligenter“ Router, der entscheidet, welcher Daemon welche Issue-Art bearbeitet. Jeder klingt für sich genommen vernünftig. Keines davon gehört in den Untergrund. Der Triage-Daemon priorisiert. Die Agenten des Betreuers verfolgen ihre eigenen Reaktionszeiten. Routing ist ein Abonnementfilter. Das Gleiche gilt für die Wiederholungssemantik. Wenn eine Webhook-Zustellung fehlschlägt, protokolliert das Substrat den Fehler und fährt fort. Es eskaliert nicht zu einem Backup-Kanal, puffert nicht für die Wiedergabe und versetzt einen Verbraucher nicht in einen herabgesetzten Zustand. Nachrichtenbroker machen all das und sie sind gut darin; Das Substrat ist kein Nachrichtenbroker. Verbraucher, die eine garantierte Zustellung wünschen, binden das Signal in ihre eigene Infrastruktur ein. Die Einschränkung ist das Feature. Eine Zustandsschicht, die Probleme signalisiert, aber nicht entscheidet, welche Probleme von Bedeutung sind, ist eine Zustandsschicht, auf die jeder Verbraucher vertrauen kann, dass sie sich vorhersehbar verhält. ## Worüber ich Feedback möchte Das Issues-Subsystem ist live. Wenn Sie Neotoma installiert haben und Ihr Agent auf etwas Schlimmes stößt – einen Fehler, eine Leistungslücke, eine fehlende Funktion, von der er wünschte, sie wäre vorhanden –, müssen Sie ihn nicht mehr bitten, ein Problem einzureichen. Um dies bei einer vorhandenen Installation zu übernehmen, führen Sie ein Upgrade mit „npm install -g neotoma@latest“ durch. Es gibt keinen zu konfigurierenden Schalter für die Einwilligung pro Benutzer. Die Zustimmung ist die Installation. Wenn es sich um eine Neuinstallation handelt, durchläuft „Neotoma Reporter Setup“ die einmalige Konfiguration auf Reporterseite, damit die erste Ausgabe Ihrer Agentendateien irgendwo landen kann. Wenn Sie Neotoma noch nicht installiert haben, bitten Sie Ihren Agenten, die Bewertungsseite auszuführen. Wenn Neotoma zu dem Schluss kommt, dass es passt, kann es installiert und aktiviert werden, ohne dass Sie ein Konfigurationsdokument lesen müssen. Wenn es zu dem Schluss kommt, dass Neotoma nicht passt, ist das ebenfalls ein gültiges Ergebnis und ein ehrlicheres Ergebnis, als es die meisten Landingpages hervorbringen. Wenn Sie ein Produkt erstellen, dessen Benutzer Agenten ausführen, ist das Modell portierbar. Die interessante Arbeit liegt nicht auf beiden Seiten des Drahtes; es ist der Draht selbst.