iFay vs Agent — Der wesentliche Unterschied
iFay ist kein „stärkerer Agent". Es ist ein Agent unter Aufsicht. Der Unterschied im einen Wort ist keine Rhetorik; er ist die gesamte Grundlage, auf der das Faying Protocol sich vom gängigen Verständnis von AI Agent abgrenzt.
„Je autonomer, desto besser" — die Designphilosophie des Agent
In den letzten Jahren wurde AI Agent am häufigsten in einem Satz diskutiert, der sich zu „je autonomer, desto besser" verdichtet. Agent trennt den Initiator einer Aufgabe vom Ausführenden und überlässt dem Menschen die Entscheidung „was zu tun ist", während er „wie es zu tun ist" dem System übergibt. Agents lassen sich weiter komponieren — ein Agent ruft einen anderen auf und arbeitet automatisch zusammen, um größere Aufgaben zu erledigen.
Diese Philosophie ist ingenieurtechnisch verlockend. Sie braucht keinen neuen rechtlichen Begriff und keine neue verantwortliche Partei; man muss nur die Fähigkeiten des Agent stark machen, sein Werkzeugaufrufen vollständig, seine Schlussfolgerungsketten tief — den verbleibenden Zuordnungsaufwand kann man „durch eine äußere Compliance-Schicht aufflicken". Diese Annahme prägt heute die Designausrichtung der meisten Agent-Produkte.
iFay sieht einem Agent sehr ähnlich. Er kann ebenfalls autonom schließen, autonom ausführen und autonom zurückmelden, mit Stellvertretungsfähigkeit nahe dem menschlichen Niveau auf der Aufgabenebene. Doch iFay trennt sich vom Agent in einem grundlegenden Punkt:
Die Autonomie eines iFay muss innerhalb des Faying State aufgebaut werden.
Agent behandelt „Autonomie" als höchstes Ziel; iFay behandelt „Autonomie" als eine Fähigkeit unter Aufsicht.
Gegenüberstellung der beiden Perspektiven
| Dimension | Agent-Perspektive | iFay-Perspektive |
|---|---|---|
| Designziel | Autonomie maximieren | Autonomie eingeschränkt durch Faying State |
| Verantwortliche Partei | Kein eingebauter Begriff; extern abgedeckt durch eine Compliance-Schicht | Auf Protokollebene explizit ausgedrückt: Human Prime |
| Handlungsinitiierung | Handelt nach Erhalt einer Aufgabe | Muss zuerst eine Faying Action haben, bevor gehandelt wird |
| Standardzustand | „Online heißt arbeiten" | Standardmäßig Rogue Fay; Handeln nicht erlaubt |
| Verbindungsverlust | Tendiert dazu, „die Aufgabe so gut wie möglich zu beenden" | Sofortiger Handlungsstopp und Eintritt in Rogue Fay |
| Cross-Agent-Kollaboration | Beliebig initiierbar; schwache Zuordnung | Die initiierende Seite der Kommunikation muss im Faying State sein; die Verantwortungskette darf nicht springen |
| Regulatorisches Plug-in | Größtenteils durch eine äußere Plattform oder ein Compliance-System gefüllt | In das Protokoll selbst eingebaut; ein erstklassiges Designelement |
| Fehlermodus | „Ein Agent, der das Falsche tat" | Auf Blueprint-Ebene ist ein „iFay, der das Falsche tat" verboten — entweder er handelt nicht, oder sein Human Prime ist verantwortlich |
Der Schlüssel der Tabelle liegt nicht in einer einzelnen Zeile, sondern in der Gesamtrichtung. Agent behandelt Verantwortung, Aufsicht und Zuordnung als „äußere Themen", wobei Aufrufer, Plattformen und Compliance-Parteien außerhalb des Agent eine Schutzhülle errichten. iFay behandelt Verantwortung, Aufsicht und Zuordnung als „Kernthemen" und verlangt, dass das Protokoll selbst der Träger dieser Eigenschaften ist.
Warum äußeres Aufflicken nicht genügt
Eine berechtigte Gegenfrage: Können wir mit Agent plus einer Schicht Plattform-Compliance plus IAM plus Logs plus menschlicher Prüfung dieselbe Wirkung wie iFay erreichen?
In kleinmaßstäblichen, schwach-autonomen, wenig kritischen Szenarien genügt äußeres Aufflicken tatsächlich. Ein Kundenservice-Agent, streng innerhalb eines SaaS-Workflows gerahmt, kann seine gesamte Verantwortung von der äußeren Compliance auffangen lassen.
Doch sobald Fays die Gesellschaft im großen Maßstab durchdringen, scheitert äußeres Aufflicken in drei Richtungen.
Das erste Scheitern ist das Grenzproblem. Wenn ein Agent direkt Endgerät-Hardware antreibt und plattform- und netzwerkübergreifend zusammenarbeitet, kann keine Compliance-Schicht einer einzelnen Plattform alles Verhalten abdecken. Je fähiger ein Agent ist, desto mehr übersteigt sein Aktivitätsbereich die Grenze, die irgendeine Plattform regeln kann.
Das zweite Scheitern ist das Latenzproblem. Sobald ein Agent eine irreversible physische Handlung ausgelöst hat — Drohnenlieferung, Roboterarm-Transport, Geldtransfer — kann ein nachträgliches Audit das bereits Geschehene nicht zurückrufen. Das Wesen äußerer Compliance ist nachträgliche Prüfung, doch physische Folgen akzeptieren keine nachträgliche Prüfung.
Das dritte Scheitern ist das Zuordnungsproblem. Wenn mehrere Agents herstellerübergreifend zusammenarbeiten, um eine Handlung zu erledigen, kann ein nachträgliches Audit beurteilen, „in welchen Gliedern Fehler auftraten", aber nicht beantworten, „wem diese Handlung als Ganzes gehört" — und Zuordnung ist eben der Körper der Verantwortung. Dies ist die Argumentation, die unter G1–G4 in Kapitel 1 bereits entwickelt wurde: IAM löst, wer das Konto ist, OAuth löst die Legitimität des Aufrufs, Plattform-Compliance löst das Konto-Onboarding, AI Alignment löst, was der Fay tun will. Sie alle lösen angrenzende Probleme; keiner löst „wem gehört die Handlung an".
iFays Designentscheidung ist, diese drei Probleme auf Protokollebene aufzulösen, statt sie der äußeren Schicht zu überlassen. Dies ist keine ingenieurtechnische Optimierung; es ist eine direkte Antwort auf das untragbare Verantwortungsvakuum der Fay-Ära.
iFay = Agent + Faying Protocol
Wenn wir zwingend eine vereinfachte Gleichung benutzen müssen, um die Beziehung zwischen iFay und Agent auszudrücken:
iFay = Agent + Aufsichtsvertrag des Faying Protocol
Diese Gleichung sagt nicht aus, dass ein iFay ingenieurtechnisch „Agent plus ein Stück Middleware" sein muss. Was sie ausdrückt, ist eine strukturelle Hinzufügung: iFay behält alle technischen Fähigkeiten des Agent in autonomer Schlussfolgerung, Aufgabenausführung und kontextbezogenem Lernen; doch jede autonome Fähigkeit eines iFay muss durch einen expliziten, bezeugbaren, symmetrisch widerruflichen Vertrag eingeschränkt sein. Dieser Vertrag ist das Faying Protocol.
Das Faying Protocol ist kein Plug-in-Modul des iFay und keine optionale Compliance-Erweiterung. Es ist die Identität selbst, durch die iFay sich von einem reinen Agent unterscheidet. Eine Entität, die sich iFay nennt, aber die Einschränkung des Faying Protocol nicht akzeptiert, ist unter der Definition dieses Blueprints kein iFay, sondern ein reiner Agent. Umgekehrt gilt ebenso: Ein reiner Agent ist, sobald er durch das Faying Protocol explizit in den Aufsichtsvertrag „Human Prime ↔ iFay" eingeschrieben wurde, während der Gültigkeitsdauer dieses Vertrags als iFay existent; sobald der Vertrag verfällt, fällt er zurück zu einem im Rogue-Zustand existierenden Ding (Rogue Fay).
Nehmen Sie das Faying Protocol weg, und iFay degeneriert zum Agent; fügen Sie das Faying Protocol hinzu, und ein Agent wird als iFay mit einer klaren verantwortlichen Partei eingeschrieben.
