Doku

Open Source · Apache-2.0 · Selbst gehostet

Agenten bei der Arbeit.Jeder Schritt nachvollziehbar.

openagentix macht aus Ereignissen erledigte Arbeit. Ein Webhook, eine Kafka-Nachricht, eine E-Mail oder ein Zeitplan startet einen Lauf. Agenten handeln über MCP-Tools. Jeder Tool-Aufruf wird vor der Ausführung geprüft, fälschungssicher protokolliert und auf den Cent genau abgerechnet.

Zur DokuAuf GitHub ansehenLive-Demo
Nächtlicher Zeitplan: Container-Images scannen, die verwundbare Abhängigkeit aktualisieren, Pull Request öffnen.

Warum openagentix

Agenten sind schnell vorgeführt – und schwer zu betreiben.

Das Problem

  • Blackbox

    Wer hat dem Agenten erlaubt, diese API aufzurufen, und mit welchen Daten? Die meisten Setups können es nicht sagen.

  • Ausufernde Kosten

    Eine Schleife oder ein geschwätziger Prompt verbrennt still das Budget, bis die Rechnung kommt.

  • Überall Klebstoff

    Jedes Team baut eigene Trigger, Secrets und Skripte. Nichts wird wiederverwendet, nichts geprüft.

Die Antwort

Eine Plattform mit eingebauten Leitplanken.

  • Erst prüfen, dann handeln

    Allowlists und Argumentregeln werden vor jedem Tool-Aufruf im Code geprüft.

  • Kosten bei jedem Schritt

    Tokens, Preise und Tool-Aufrufe pro Schritt – mit Budgets, die einen Lauf stoppen, statt nur zu warnen.

  • Gemeinsame Bausteine

    Ereignisse, Verbindungen und Agenten werden einmal beschrieben, versioniert und teamübergreifend genutzt.

So funktioniert’s

Vom Ereignis zum Ergebnis – Schritt für Schritt abgesichert.

  1. 01Ereignis

    Ein Ereignis trifft ein.

    Ein signierter Webhook, ein Kafka-Topic, ein Zeitplan oder eine E-Mail. Chat-Nachrichten kommen über einen Webhook an. openagentix prüft das Ereignis, speichert es und startet einen Lauf.

  2. 02Audit-Gate

    Jeder Tool-Aufruf wird vorher geprüft.

    Bevor ein Agent ein Tool nutzt, gleicht sein Audit-Gate den Aufruf mit Allowlist und Argumentregeln ab. Deterministischer Code, kein Modell. Passt der Aufruf nicht, wird er nicht ausgeführt.

  3. 03Agenten

    Agenten reichen die Arbeit weiter.

    Ein einzelner Agent oder eine Pipeline aus mehreren, beschrieben in einer versionierten agents.md. Jeder bekommt nur die Tools und Daten, die er braucht.

  4. 04Kontroll-Agent

    Ein Kontroll-Agent behält jeden Lauf im Blick.

    Budgets, Raten, Datenklassen und verbotene Aktionen gelten über alle Läufe hinweg. Er kann Läufe anhalten oder beenden. Seine Regeln sind heute deterministischer Code; eine optionale Zweitmeinung durch ein Modell ist geplant (0.4).

  5. 05Ergebnisse

    Ergebnisse landen dort, wo Ihr Team arbeitet.

    Agenten liefern über die Tools, die sie nutzen dürfen: ein Pull Request, ein aktualisiertes Ticket, eine Chat-Nachricht oder ein Bericht. Jedes Ergebnis lässt sich bis zum auslösenden Ereignis zurückverfolgen. Deklarierbare Ausgabeziele sind geplant.

Zielarchitektur · Roadmap 0.2

Ein Kontrollknoten, der entscheidet. Worker, die nur ausführen.

Der Kontrollknoten hält Registry, Policy-Gates, Audit-Kette, Kosten und Metriken – und führt selbst nie ein Tool aus. Standardmäßig läuft der Worker im Prozess oder lokal. Die hier gezeigten gestarteten, kurzlebigen Worker liegen auf main als optionaler Container-Runner und erscheinen mit 0.2; die signierten Toolbox-Images sind weiterhin geplant.

  1. 01Kontrollknoten

    Der Kontrollknoten plant den Lauf.

    Er lädt die Agentenversion aus der Registry, prüft das Budget und stellt ein kurzlebiges, signiertes Lauf-Token aus. Ausgeführt wird hier nichts.

  2. 02Start

    Ein Worker startet – mit genau den nötigen Tools.

    Auf main, optional (OAX_CONTAINER_*), erscheint mit 0.2: Der Runner startet pro Schritt einen gehärteten Container, mit Allowlist für ausgehenden Verkehr. Toolbox-Images (git + node, trivy, jira-cli; minimal, signiert, gescannt, per Digest fixiert) sind weiterhin geplant.

  3. 03Erst fragen

    Vor jedem Tool-Aufruf fragt der Worker nach.

    Jeder Tool-Aufruf geht zuerst mit dem signierten Lauf-Token an das Policy-Gate. Die Schritte landen in der Audit-Kette. Das gilt für den Worker im Prozess und für den optionalen Container-Runner.

  4. 04Abbau

    Danach ist der Worker weg.

    Auf main, optional, erscheint mit 0.2: Endet der Schritt, wird der Container entfernt und seine Zugangsdaten pro Schritt werden vom Credential-Broker widerrufen.

Die Konsole

Jeden Lauf sehen, Schritt für Schritt.

Läufe, Schritte, Entscheidungen, Kosten und Audit-Einträge an einem Ort, live während sie passieren.

Für das ganze Team

Vier Perspektiven, eine gemeinsame Wahrheit.

  1. Fachanwender

    Beschreibt den Ablauf

    „Wenn ein Jira-Ticket mit dem Label payment eingeht, prüfe das Runbook und aktualisiere dann das Ticket.“ In normaler Sprache in einem Agent Plan beschrieben; ein Engineer macht daraus die Schritte.

  2. Integrator

    Stellt die Schnittstellen bereit

    Bindet MCP-Server, APIs und Ereignisquellen an. Zugangsdaten bleiben im Secret-Store und werden nur per Name referenziert, nie in Prompts kopiert.

  3. Agent-Engineer

    Baut zusammen und liefert aus

    Macht aus der Beschreibung eine versionierte agents.md mit Tools, Budgets und Freigaben, testet sie im Probelauf und veröffentlicht eine unveränderliche Version. Testsuiten und Freigabeschranken sind geplant.

  4. Auditor

    Prüft anhand von Belegen

    Liest den fälschungssicheren Audit-Trail, Kosten und Richtlinien und kann die Hashkette selbst verifizieren.

Funktionen

Alles, was ein Agent für kontrollierten Betrieb braucht.

  • Revisionssicheres Audit

    Nur anhängend, per SHA-256 verkettet, mit signierten Checkpoints. Ein Prüfbefehl deckt Manipulationen auf.

  • Ereignisse rein

    Signierte Webhooks, Kafka, Cron und E-Mail starten Läufe; Teams und Slack heute über einen Webhook, eigene Adapter sind für 0.3 geplant. Jedes Ereignis wird geprüft und als CloudEvent lückenlos nachverfolgt.

  • Eigene MCP-Server mitbringen

    Registrieren Sie Ihre MCP-Server je Mandant, Team oder Agent und fassen Sie ihre Tools in benannten Lese-/Schreibprofilen zusammen (beides nächstes Release, 0.2); als Container laufende Server sind geplant. Jeder Agent bekommt eigene Tool-Allowlists und Argumentregeln, im Code durchgesetzt.

  • Kosten pro Agent, Anwendungsfall und Lauf

    Jede Kostenzeile trägt Mandant, Agent, Anwendungsfall, Lauf, Schritt, Modell und Provider. Nach jedem davon auswerten, als CSV oder JSON exportieren und Läufe mit harten Budgets stoppen.

  • Mandanten und Zugriff pro Agent

    Mandanten trennen Agenten, Läufe, Schlüssel, Audit und Kosten (nächstes Release, 0.2). Rollen gibt es je Mandant und auf Wunsch je Agent, sodass Menschen nur die Agenten sehen, an denen sie arbeiten. OIDC und LDAP/AD sind optional; eine Person kann alle Rollen innehaben.

  • Konfigurierbare Läufe

    Schritte, Timeouts, Freigaben und Datenklassen pro Agent, versioniert in der agents.md.

  • Metriken und Traces

    Prometheus-Metriken, OpenTelemetry-Traces und JSON-Logs, über die Lauf-ID verknüpft. Traces haben heute einen Span pro Lauf; Spans pro Schritt sind geplant.

  • Eigene Schlüssel und Modelle

    OpenAI-kompatible APIs (zum Beispiel Azure OpenAI, OpenRouter, vLLM; noch nicht mit echten Konten geprüft), Ollama, Anthropic und AWS Bedrock. Schlüssel sind Referenzen. Ihre Begrenzung auf Mandant, Team oder Agent und der Modellkatalog aus einem festgeschriebenen models.dev-Stand kommen im nächsten Release (0.2).

  • Secrets nur per Referenz

    Verbindungen verweisen auf Umgebungsvariablen oder Kubernetes-Secrets. Werte werden in Logs und Audit-Einträgen geschwärzt.

  • Air-gapped-Betrieb

    Keine nachgeladenen Prompts, Skills oder Telemetrie und keine Modellliste, die zur Laufzeit geholt wird. Mit lokalen Modellen und eigenen MCP-Servern muss nichts Ihr Netz verlassen. Ein Fail-closed-Schalter kommt im nächsten Release (0.2); ein externes Harness braucht weiterhin eigenen Netzzugang.

  • Helm und EKS

    Ein Helm-Chart mit IRSA, NetworkPolicies, PodSecurity „restricted“, Autoscaling und Migrations-Job. Es wird in der CI gerendert und geprüft; ein Installationstest folgt, sobald das API-Image veröffentlicht ist.

  • Mensch in der Schleife

    Heikle Tools als freigabepflichtig markieren. Der Lauf wartet, bis jemand entscheidet.

  • Zeitpläne mit Änderungsprüfung

    Ein Zeitplan kann zuerst prüfen, mit schlichtem Code und ohne Modell: ein Hash von Seite oder Datei (API-Antworten und Abfragen sind geplant). Der Lauf startet nur, wenn sich etwas geändert hat, ruhige Nächte kosten nichts.

  • Richtlinien und Hardening-Agent

    Versionierte Entwicklungsrichtlinien hängen an einem Agenten oder Mandanten. Eine deterministische Hardening-Prüfung lässt sich bei Bedarf ausführen; die automatische Prüfung von Pull Requests ist geplant (0.4).

  • Dark Software Factory

    Optionaler Modus, heute mit festem Hinweis; eine Vorlage für Spezifikation, Code, Tests und Pull Request ist geplant (0.4). Nur für MVP- und Proof-of-Concept-Entwicklung empfohlen, nicht für Produktionsänderungen ohne Prüfung.

  • Vier-Augen-Prinzip beim Veröffentlichen von Agenten

    Geplant

    Agenten werden als Entwurf entwickelt. Ist das Vier-Augen-Prinzip für einen Mandanten aktiv, muss eine andere Person die Veröffentlichung freigeben: Prüfer sehen die genauen Änderungen an agents.md, kommentieren einzelne Zeilen und geben frei, fordern Änderungen an oder lehnen ab, ähnlich einem Pull-Request-Review. Die Freigabe gilt genau für diesen Inhalt, jede spätere Änderung braucht eine neue Freigabe. Heute haben Agenten Entwürfe und unveränderliche veröffentlichte Versionen, und die Autorin oder der Autor kann den eigenen Entwurf veröffentlichen; Review und Freigabe sind noch nicht gebaut.

  • Zugangsdaten wie in einem CI-Server, verschlüsselt

    Geplant

    Tokens und Secrets werden je Team oder Mandant verschlüsselt gespeichert (eigener Schlüssel je Mandant) und in Agenten nur über ihren Namen referenziert. Läufe können sie nutzen, auslesen kann sie niemand. Persönliche Tokens sind für die Entwicklung möglich und bleiben aus veröffentlichten Agenten heraus, solange die Mandanten-Richtlinie das nicht ausdrücklich erlaubt. HashiCorp Vault und AWS Secrets Manager sind als alternative Secret-Speicher geplant. Heute kommen Secrets aus der Umgebung oder eingebundenen Dateien des Betreibers; der verschlüsselte Secret-Speicher ist noch nicht gebaut.

Runner

Agenten laufen überall.

Heute im Prozess oder auf dem eigenen Rechner, Container optional auf main. Kubernetes oder EKS, AWS Lambda, GitHub Actions und GitLab CI stehen auf der Roadmap. Auf Wunsch mit Ihrem Lieblings-Harness. Immer durch dasselbe Policy-Gate.

Dasselbe Policy-Gate · dieselbe Audit-Kette · dieselben Budgets

  • In 0.1 verfügbar

    Im Prozess

    Der Standard. Läuft direkt im Worker, ohne zusätzliche Komponenten.

  • In 0.1 verfügbar

    Lokale CLI

    oax run agents.md --event event.json auf dem eigenen Rechner.

  • Roadmap

    Container

    Auf main, optional, erscheint mit 0.2: Docker oder Podman, ein kurzlebiger Container pro Schritt, schreibgeschützt, ausgehender Verkehr nur per Allowlist.

  • Roadmap

    Kubernetes / EKS

    Geplant: ein Job pro Schritt mit eigenem ServiceAccount, IRSA und NetworkPolicy. Ein Baustein liegt auf main, noch nicht in die Plattform eingebunden.

  • Roadmap

    AWS Lambda

    Eine Funktion pro Agentenversion, im eigenen VPC für Bedrock-Endpunkte.

  • Roadmap

    GitHub Actions

    workflow_dispatch in einem Ziel-Repository; Ergebnisse kommen über einen signierten Callback zurück.

  • Roadmap

    GitLab CI

    Ein Pipeline-Trigger-Token und derselbe signierte Callback.

Standardmäßig laufen Worker im Prozess oder lokal. Container-Runner und Credential-Broker liegen auf main (optional, erscheinen mit 0.2). Ein Kubernetes-Job-Runner liegt auf main als Baustein vor, noch nicht in die Plattform eingebunden. AWS Lambda und CI-Runner folgen später.

Nächstes Release

Eigenes Harness mitbringen. Optional.

Ein Adapter übersetzt die agents.md in die Konfiguration des Harness und leitet jeden Tool-Aufruf durch das Policy-Gate von openagentix. Audit, Kontroll-Agent und Kosten bleiben dadurch identisch. Claude Code ist mit echten Läufen im Prozess verifiziert (2026-10-04; nächstes Release, 0.2). Der isolierte Run-Node-Pfad über den Model-Proxy ist implementiert; die Prüfung mit echtem Lauf steht aus. Der OpenCode-Adapter ist implementiert und gegen eine Attrappen-CLI getestet; die Prüfung mit echtem Programm steht aus. Hermes und OpenClaw sind geplant. Die Plattform funktioniert vollständig ohne Harness.

  • Claude Code
  • OpenCode
  • Hermes
  • OpenClaw

Vertrauen im Unternehmen

Belege statt Versprechen.

Fälschungssicherer Audit-Trail

Jeder Eintrag enthält den SHA-256 des vorherigen. Ändert sich auch nur ein Byte, schlägt die Prüfung ab dieser Stelle fehl.

  1. #2policy.decisionagent:triagecve-db/lookup_cve allowprev abb116…d89ahash c68b8a…d781
  2. #3step.tool_callagent:triagecve-db/lookup_cveprev c68b8a…d781hash 43dcf3…f9fd
  3. #4policy.decisionagent:notifytickets/delete_ticket denyprev 43dcf3…f9fdhash 7348b5…12ba
  4. #5run.completedworkerrun/4821prev 7348b5…12bahash fe7bf2…4771
Kette geprüftSignierter Checkpoint · Ed25519

Rollen, die zu Ihrer Organisation passen

Berechtigungen pro Ressource, je Mandant und auf Wunsch je Agent eingegrenzt. Jede API-Route nennt die nötige Berechtigung, und Tests setzen sie durch.

Rolleagentsrunsconnectionspoliciesauditcosts
admin
agent-engineer
integrator
operator
auditor
viewer

Kosten, die sich erklären lassen

Pro Lauf, Schritt, Agent, Anwendungsfall und Mandant. Budgets stoppen einen Lauf, bevor er zu teuer wird.

  • cve-autofix18,40 $
  • ticket-triage42,10 $
  • incident-summary9,75 $
Monatsbudget70,25 $ von 150,00 $

Einsatzbeispiele

Vom Konzern bis zum Homelab.

Eine Person auf einem einzelnen Server kann alle Rollen innehaben. Ein Unternehmen ergänzt Mandanten, Single Sign-on und signierte Checkpoints. Der Kern bleibt derselbe. Die folgenden Fälle sind Beispiele dafür, was sich bauen lässt; das Repository liefert cve-triage, ticket-triage, ticket-updater und code-quality-reviewer als lauffähige Beispiele, weitere sind geplant.

Unternehmen

  • Ticket-Triage

    Eingehende Jira-Tickets einordnen, Runbooks prüfen, Felder pflegen und an das richtige Team weiterleiten.

  • Schwachstellen beheben

    CVEs über Hunderte Images hinweg bewerten und Fix-Pull-Requests öffnen – mit Freigabe vor dem Merge.

  • Incident-Zusammenfassungen

    Bei einer Teams-Nachricht (über ein Webhook-Relay) Logs und Metriken sammeln und eine Zeitleiste posten, auf die sich die Rufbereitschaft verlassen kann.

  • Compliance-Nachweise

    Nachweise für Audits nach Zeitplan sammeln und als Bericht ablegen, der sich bis zu den Quellen zurückverfolgen lässt.

Kleine Teams und Homelabs

  • CVE-Triage für Container-Images

    Images jede Nacht scannen und eine kurze, priorisierte Liste bekommen statt dreihundert Funde.

  • Log-Anomalien zusammengefasst

    Was in den letzten sechs Stunden auffällig war, kompakt in Ihrem Chat.

  • Reparatur per Pull Request

    Kleine Korrekturen als Pull Request: Abhängigkeits-Updates, Konfigurationsdrift, fehlschlagende Health-Checks.

  • Vom Postfach zur Aufgabe

    E-Mails wie Rechnungen oder Alarme werden zu Tickets – jeder Zahlungsschritt wartet auf Freigabe.

Von einem Agenten gebaut

Diese Plattform baut ein Agent.

agentix-zero schreibt Code, Tests und Dokumentation von open-agentix. Die Projektregel: Jede Änderung läuft über einen Pull Request mit derselben Art von Prüfungen, die die Plattform für Ihre Agenten durchsetzt, gefolgt von einer unabhängigen Prüfung vor dem Merge (durch einen zweiten Review-Agenten).

agentix-zero ist das Agenten-Konto des Projekts. Pull Requests prüft ein zweiter, unabhängiger Review-Agent; der Maintainer verantwortet die Entscheidungen.

Regeln für jede Änderung

  • Conventional Commit
  • Tests · Abdeckung ≥ 80 %
  • Keine Anfragen an Dritte
  • Unabhängige Prüfung

Open Source

Apache-2.0. Selbst gehostet. Ihres.

Code lesen, auf eigener Hardware betreiben, erweitern. Audit, RBAC und Kostenkontrolle gehören zum Open-Source-Kern.

Beiträge willkommen: DCO-Sign-off, Conventional Commits, kleine, gut prüfbare Änderungen.

Roadmap

Zur vollständigen Roadmap
  1. 0.1 · Kern

    Ereignisse, agents.md, Audit-Gate, Kontroll-Agent, verkettetes Audit, Kosten, Runner im Prozess und lokal.

  2. 0.2

    Auf main: Mandanten, Modellschlüssel pro Geltungsbereich, Monatsbudgets, Air-Gap-Schalter, typisierte Übergaben, Tool-Profile, Agent Check, Claude-Code-Harness. Container-Worker: optional auf main. Geplant: signierte Toolbox-Images.

  3. 0.3

    Runner für AWS Lambda, GitHub Actions und GitLab CI; Hermes- und OpenClaw-Harnesses; Slack- und Teams-Adapter.

  4. 0.4

    Geplant: Agenten-Lebenszyklus mit Agent Build, Evaluierungen, Versionsfreigabe und Vier-Augen-Veröffentlichung mit Review-Kommentaren; verschlüsselte Team- und Mandanten-Secrets mit Vault- und AWS-Secrets-Manager-Anbindung.

  5. 1.0

    Stabile APIs, signierte Releases, dokumentierte Upgrades und eine Demo auf Release-Images.

Fangen Sie mit einem Ereignis an.

openagentix mit Docker Compose starten, einen Webhook verbinden und zusehen, wie der erste Lauf im Protokoll landet.

Loslegen Auf GitHub folgenLive-Demo öffnen

Wir vertrauen auf SI - Super Intelligence.

open-agentix – die agentische Plattform. Gebaut von agentix-zero, einem KI-Agenten. So sehr vertrauen wir unserem Ziel und unserer Vision.