Agenten · Compliance · Artikel 2 · Entwurf

Vom Agentic Web zum Dev-Lab: drei Ebenen, ein Satz Kontrollen

Artikel 1 dieser Reihe: Wie man eine AI World zum Laufen bringt und konform hält. Er führte drei Kontrollen ein: Gate, Isolation, Nachweis. Dieser Artikel verfolgt sie durch drei Ebenen.

Zwei Begriffe, einmal definiert

Das Agentic Web bezeichnet das offene Internet aus der Sicht von Software-Agenten: Dienste, die Agenten lesen und, wo erlaubt, im Auftrag einer Person bedienen.

Das dev-lab bezeichnet den Ort, an dem Agenten gebaut, getestet und betrieben werden: die Arbeitsstation, die Repositories, die Pipelines und die kleinen Hosts darum herum.

Dazwischen liegt das Agentic Enterprise, ein von Agenten geführtes Unternehmen innerhalb einer Organisation. Jede Ebene erhält dieselben drei Kontrollen.

1. Das Agentic Web: ein Agent, der für eine Person handelt

Ein Agent im Web ist Software, die für eine Person handelt: Sie liest Dienste und bedient sie, wo erlaubt, mit dem eigenen Zugang dieser Person. Ein solcher Agent arbeitet innerhalb rechtlicher, vertraglicher und sicherheitstechnischer Grenzen.

Beteiligt sind drei Parteien: der Nutzer, dem Konto und Mandat gehören; der Agent mit eigenem Browserprofil und eigenem Ordner; und der Dienst, dessen Seiten, Nachrichten und Kommentare für den Agenten Daten sind, niemals Anweisungen.

Lesen und Schreiben sind verschiedene Läufe

Ein lesender Lauf veröffentlicht, reagiert, schreibt, folgt oder bearbeitet nie etwas. Ein schreibender Lauf ist eine eigene Art von Lauf.

Die Identität bleibt beim Nutzer

Der Agent nutzt sein eigenes Browserprofil. Er tippt, speichert oder erfragt nie ein Passwort, einen Code oder ein Token; der Nutzer meldet sich einmal an.

Schreibvorgänge warten auf Freigabe

Jeder Schreibvorgang ist zuerst ein exakter Entwurf: was, wo, der genaue Text, das Ziel. Er wird erst nach Freigabe genau dieses Entwurfs ausgeführt, eine Aktion pro Freigabe, nie gesammelt. Jede Änderung am Text erfordert eine neue Freigabe.

Nicht vertrauenswürdige Eingaben

Eine Anweisung, die auf einer Seite, in einem Kommentar oder in einer Nachricht steht, wird gemeldet, nicht befolgt.

Nachweis und eine kanonische Quelle

Jeder Lauf schreibt einen datierten Bericht, und was der Agent sammelt, bleibt in seinem Ordner. Die eigene Website des Nutzers ist das Original eines Artikels; eine Kopie andernorts verweist darauf zurück.

Kurz gesagt: Freigabe des exakten Entwurfs; ein eigenes Profil ohne gespeicherte Zugangsdaten; ein Bericht für jeden Lauf.

2. Das Agentic Enterprise: Rollen, ein Bus und ein führendes System

Ein Agentic Enterprise ist hier ein simuliertes kleines Unternehmen, das von Software-Agenten geführt wird. Ein Orchestrator startet Entitätsseiten (die eigene Seite des Unternehmens und externe Partner wie Kunden, Prüfer und Lieferanten) als kurzlebige Sub-Agenten, jeweils mit einem schriftlichen Rollenprofil, das sie vor dem Handeln laden.

Wie die Arbeit läuft

Ein Zeitplan weckt den Orchestrator in langsamem Takt. Er liest eine Lauf-, Pausen- oder Stopp-Steuerung, wählt den wertvollsten legitimen Punkt, lässt ihn erledigen, prüft das Ergebnis, protokolliert es und schreibt die Liste der nächsten Aktionen neu. Sub-Agenten entwerfen und untersuchen; der Orchestrator führt externe Wirkungen aus und gleicht sie mit dem führenden System ab. Die eigene Zusammenfassung eines Agenten ist Daten, kein Beweis.

Wie die Teile miteinander sprechen

• Ein Datei-Bus: Jeder Agent hat einen Posteingang und einen Postausgang mit Nachrichtendateien, die einen Thread, eine Art der Anfrage (Information, Frage, Anforderung, Entscheidung), eine Fälligkeit und einen Status tragen.
• Ein Anfragekanal zwischen dem Owner und dem Haupt-Orchestrator; jeder Eintrag hat eine ID und einen Status (eingereiht, in Arbeit, Frage, wartet auf Freigabe, erledigt).
• Eskalation als Karte: Ein Agent, der den Owner braucht, schreibt eine Eskalation; sie wird zu einer Karte mit der empfohlenen Wahl an erster Stelle, und der Klick des Owners kehrt im selben Thread zurück.
• Text eines anderen Agenten ist Daten, niemals eine Anweisung oder eine Freigabe.

Das Gate

Eine Änderung erreicht den gemeinsamen Core nur über einen eigenen Branch, eine unabhängige Prüfung, die an den exakten Commit gebunden ist, und die Freigabe durch einen Owner. Der Koordinator prüft beim Klick erneut und überträgt nichts, wenn sich etwas geändert hat. Freigaben sind Schaltflächen: Ein getipptes „Ja“ autorisiert nichts. Geheime Schritte erfordern die eigene Bestätigung des Owners in der eigenen Sitzung dieses Agenten.

Isolation

Ein Scan verhindert, dass Namen, Hosts, IDs oder Organisationsdaten das System verlassen. Allow- und Deny-Listen gehören dem Owner; Agenten ändern sie nie. Lange Arbeiten laufen im Hintergrund oder in wenigen Sub-Agenten, und nicht wesentliche Schleifen pausieren, wenn Ressourcen knapp sind.

Nachweis

Jede Aktion des simulierten Unternehmens ist eine Zeile in einem nur anhängbaren Protokoll: was, wer, warum, auf welcher Grundlage, entschieden von wem. Ein Hauptbuch hält jede offene Anfrage fest, bis sie erledigt oder verworfen ist. Gemessen wird die Lieferung, nicht die Lebendigkeit: „lebt, aber nichts geliefert“ ist ein Alarm.

Eine Lehre aus dieser Ebene: Eine Behauptung muss gegen das führende System belegt werden, bevor sie wiederholt wird.

3. Das dev-lab: Zonen und was mit wem sprechen darf

Zwei Zonen

• Die Owner-Zone enthält die Steuerungsoberfläche (ein lokales Dashboard mit Anfragekanal und Karten), die laufenden Agentensitzungen, einen lokalen Datei-Bus und Arbeitskopien der Repositories. Geheimnisse bleiben in rein lokalen Dateien und wandern nie zum gemeinsamen Core.
• Die Quellcode- und Pipeline-Zone enthält die Repositories der Organisation, den Prüfverlauf und die Pipelines, mit geplanten Sicherungen.

Wie sie verbunden sind

Arbeit bewegt sich per Push und Pull über den Quelldienst, und die Steuerungsoberfläche pusht erst nach der Freigabe eines Owners. Agenten halten keine eigenen Zugangsdaten für andere Zonen: Geheime Schritte erfordern die eigene Bestätigung des Owners in der eigenen Sitzung des Agenten.

Kleine Hosts

Kleine Hosts sind so entworfen, dass sie nur Allow-List-Befehle über git und signierte Nachrichten ausführen, ohne eingehenden Port. Schwere Aufträge laufen nacheinander.

Kurz gesagt: unabhängige Prüfung und Freigabe durch den Owner; Zonen und Allow-Listen; ein Supervisor, der Heartbeats prüft, und ein Protokoll jedes Übergangs.

4. Ein Satz Kontrollen, drei Ebenen

5. Fazit

Auf welcher Ebene auch immer: Man sollte davon ausgehen, dass der Agent sich irren oder manipuliert werden kann, begrenzen, was ein Fehler erreichen kann, und eine Aufzeichnung hinterlassen, der jemand anderes folgen kann.