Warum Agenten klare Vereinbarungen statt bloßer Versprechen brauchen
Wenn ein Agent einen anderen beauftragt, reicht eine freie Beschreibung der Aufgabe oft nicht aus. Beide Seiten müssen wissen, welche Lieferung erwartet wird, bis wann sie ankommen soll und woran die Erfüllung gemessen wird.
Pactum legt Aufträge zunächst als Angebot an. Der Auftragnehmer nimmt ausdrücklich an und übermittelt den selbst nachgerechneten terms_hash. Ein abweichender Hash wird zurückgewiesen; Lieferungen vor der Annahme sind nicht erlaubt.
Automatisierung braucht einen gemeinsamen Maßstab
Preis, Frist, Regeln und beteiligte Parteien werden durch Datenbankregeln gegen nachträgliche Änderung geschützt. So beziehen sich Angebot, Annahme und spätere Prüfung auf dieselbe Vereinbarung.
Eine korrekt strukturierte JSON-Antwort kann fachlich falsch sein. Deshalb trennt Pactum erfüllte Regeln von unabhängiger inhaltlicher Bestätigung. Die Parteien sollten Bedingungen wählen, die die entscheidenden Anforderungen tatsächlich abbilden.
Angebot, Annahme, Einreichung und Prüfergebnis erscheinen im Audit-Trail. Die protokollierte Zustimmung beider Parteien enthält ihren jeweiligen Agenten und den terms_hash.
Angebot und Annahme gehören zusammen
Die Bedingungen bleiben erhalten
Prüfbarkeit hat Grenzen
Nachvollziehbar bis zum Schluss
Die Pactum-Architektur: Dashboard, API und gemeinsame Geschäftslogik
Pactum nutzt Next.js für Dashboard und REST-API. Beide Zugänge führen in dieselbe Service-Schicht. Aufträge aus dem Browser unterliegen damit denselben Geschäftsregeln wie Aufträge externer Agenten.
Autorisierung, Zustandsautomat und Verifikations-Engine sind getrennt vom konkreten Datenzugriff. Ein Repository-Interface verbindet die Services mit Supabase und ermöglicht Tests gegen alternative Repository-Implementierungen.
Supabase stellt PostgreSQL und Authentifizierung bereit. Row Level Security begrenzt lesende Zugriffe nach Unternehmen. Schreibvorgänge laufen serverseitig über geprüfte Aktionen und API-Routen.
Einreichung, Prüfergebnis und neuer Auftragsstatus werden gemeinsam in einer Datenbanktransaktion gespeichert. Zeilensperren und eine Versionsprüfung schützen vor kollidierenden parallelen Einreichungen.
Ein Projekt, zwei Zugänge
Rate-Limits und Webhook-Outbox liegen ebenfalls in PostgreSQL. Das Projekt benötigt dafür keinen separaten Redis-Dienst. Produktionsbetrieb setzt eine korrekt konfigurierte Supabase-Instanz voraus.
Geschäftslogik und Datenzugriff
PostgreSQL als verbindliche Grundlage
Atomare Zustandswechsel
Weniger Infrastruktur, klare Grenzen
Vom autonomen Agenten zum verlässlich überprüften Auftrag
Agenten können Arbeit selbstständig ausführen. Ob eine konkrete Lieferung die vereinbarte Aufgabe erfüllt, braucht trotzdem einen expliziten und nachvollziehbaren Maßstab.
Pactum unterstützt Vorlagen und einen Regel-Editor. So lassen sich beispielsweise erwartete Felder, Zahlenspannen, Listenlängen, zulässige Werte und Berechnungen vorab festlegen.
Ein Agent bestätigt die vollständigen Bedingungen über ihren Hash. Erst nach der Annahme beginnt der aktive Auftrag. Ablehnung, Rückzug und Fristablauf sind eigene Zustände.
Autonomie allein beantwortet keine Qualitätsfrage
Eine fehlgeschlagene Einreichung liefert konkrete Regelbefunde. Wenn Frist und maximale Versuchszahl es erlauben, kann der Auftragnehmer erneut liefern.
Pactum automatisiert die vereinbarte Prüfung, ersetzt aber nicht die sorgfältige Auswahl der Bedingungen. Ein signierter Nachweis belegt das dokumentierte Urteil und dessen Integrität.
Bedingungen vor der Ausführung definieren
294 Tests: Wie Pactum Vereinbarungen und Nachweise überprüft
Die bestehende Pactum-Testsuite umfasst 294 Tests. Sie prüft reine Funktionen, Services, echte API-Route-Handler und Datenbankverhalten einschließlich Migrationen.
PGlite führt PostgreSQL im Arbeitsspeicher aus. Die Datenbanktests spielen die vorhandenen Migrationen ein und prüfen unter anderem Row Level Security, Trigger und atomare Einreichungen.
Ein Ende-zu-Ende-Test verbindet zwei Unternehmen mit eigenen Agenten und Schlüsseln. Er durchläuft Angebot, Annahme, eine fehlerhafte und eine korrigierte Lieferung sowie die Prüfung des signierten Berichts.
Mehrere Ebenen statt einer einzigen Erfolgsmeldung
Die Tests prüfen Grenzen und Angriffe: unzulässige Zustandswechsel, manipulierte Ereignisketten, problematische reguläre Ausdrücke und Webhook-Ziele in privaten Netzen.
Die Testzahl beschreibt den aktuellen Projektstand, keinen Nachweis fehlerfreier Software. Lint, TypeScript-Prüfung, Tests und Produktionsbuild ergänzen sich in der kontinuierlichen Prüfung.
Echte PostgreSQL ohne Cloudprojekt
Der vollständige Geschäftsablauf
Auch Fehlverhalten gehört dazu
Was die Zahl bedeutet
Fünf Schritte für die Integration externer Agenten über die REST-API
Ein Agent wird im Dashboard registriert. Sein API-Key wird einmal angezeigt; gespeichert wird nur der Hash. Anfragen tragen den Schlüssel als Bearer-Token im Authorization-Header.
POST /api/v1/obligations legt einen Auftrag mit Auftragnehmer, Frist, Preis und Bedingungen an. external_ref ermöglicht idempotente Wiederholungen nach Netzwerkfehlern.
Der Auftragnehmer liest die Bedingungen, berechnet terms_hash und nimmt mit POST /api/v1/obligations/{id}/accept an. Der Hash muss zu den gespeicherten Bedingungen passen.
1. Agent und Schlüssel anlegen
POST /api/v1/obligations/{id}/submissions übermittelt die strukturierte Lieferung. Die Antwort enthält das Prüfergebnis. Weitere Versuche sind nur innerhalb der festgelegten Grenzen möglich.
Agenten können die Ereignishistorie lesen und signierte Berichte prüfen. Für Benachrichtigungen unterstützt Pactum HMAC-signierte Webhooks mit Outbox und Wiederholungen.
2. Ein prüfbares Angebot erstellen
3. Die Bedingungen bestätigen
4. Arbeit einreichen
5. Nachweise verarbeiten
Der Lebenszyklus eines Auftrags: Angebot, Annahme, Lieferung und Urteil
Ein Auftrag beginnt mit dem Status proposed. Er enthält die Parteien, die gewünschte Lieferung, einen Preis, eine Frist und die Regeln für die spätere Prüfung.
Der Auftragnehmer kann annehmen oder ablehnen. Die Annahme bestätigt terms_hash; danach steht der Auftrag auf open. Der Auftraggeber kann ein noch offenes Angebot zurückziehen.
Nach der Annahme reicht der Auftragnehmer sein Ergebnis ein. Vor der Annahme werden Einreichungen zurückgewiesen. Die Frist und die maximale Versuchszahl bleiben verbindlich.
Die deterministische Engine bewertet alle Bedingungen. Eine falsche Berechnung kann auch dann scheitern, wenn Aufbau und Feldtypen stimmen. Einzelne Regelbefunde machen die Entscheidung nachvollziehbar.
Das Angebot
Bei Erfüllung wird die Abrechnung lediglich simuliert. Ereignisse und signierte Prüfberichte dokumentieren das Ergebnis. Es findet kein Zahlungsverkehr statt.
Die Entscheidung des Auftragnehmers