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 Aufruf wird vor der Ausführung geprüft, fälschungssicher protokolliert und auf den Cent genau abgerechnet.

Zur Doku Auf GitHub ansehen Live-Demo: bald verfügbar
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. 01 Ereignis

    Ein Ereignis trifft ein.

    Ein signierter Webhook, ein Kafka-Topic, ein Zeitplan, eine E-Mail oder eine Erwähnung im Chat. openagentix prüft es, speichert es und startet einen Lauf.

  2. 02 Audit-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. 03 Agenten

    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. 04 Kontroll-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. Eine optionale Prüfung durch ein Modell kann Regeln nur verschärfen, nie lockern.

  5. 05 Ergebnisse

    Ergebnisse landen dort, wo Ihr Team arbeitet.

    Ein Pull Request, eine behobene CVE, ein aktualisiertes Ticket, eine Nachricht in Teams oder Slack, ein Bericht oder Metriken für Ihr Monitoring. Jedes Ergebnis lässt sich bis zum auslösenden Ereignis zurückverfolgen.

Architektur

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. Gearbeitet wird in kurzlebigen Worker-Knoten, die genau die Tools mitbringen, die ein Agent braucht.

  1. 01 Kontrollknoten

    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. 02 Start

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

    Der Runner startet das Toolbox-Image des Agenten, etwa git + node, trivy oder jira-cli. Minimal, ohne root, schreibgeschützt, per Digest fixiert, signiert und gescannt. Ausgehender Verkehr nur per Allowlist.

  3. 03 Erst fragen

    Vor jedem Tool-Aufruf fragt der Worker nach.

    Jeder Aufruf geht zuerst an das Policy-Gate des Kontrollknotens. Die Schritte fließen über einen authentifizierten Kanal zurück und landen in der Audit-Kette.

  4. 04 Abbau

    Danach ist der Worker weg.

    Endet der Lauf, wird der Worker entfernt und seine eingegrenzten Secrets werden widerrufen. Nichts bleibt liegen, nichts driftet.

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.“ Im Dialog, in ganz normaler Sprache.

  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, Freigaben und Tests und bringt sie in Produktion.

  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 in Produktion 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, E-Mail, Teams und Slack starten Läufe. Jedes Ereignis wird geprüft und als CloudEvent lückenlos nachverfolgt.

  • Eigene MCP-Server mitbringen

    Registrieren Sie Ihre MCP-Server je Mandant, remote oder als Container. 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

    Geplant

    Mandanten trennen Agenten, Läufe, Schlüssel, Audit und Kosten. 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, alles über die Lauf-ID verknüpft.

  • Eigene Schlüssel und Modelle

    OpenAI-kompatible APIs, Ollama, Anthropic und AWS Bedrock. Schlüssel sind Referenzen, begrenzt auf Plattform, Mandant, Team oder Agent. Modelllisten und Preise stammen aus einem festgeschriebenen models.dev-Stand, mit lokalen Anpassungen für private Modelle.

  • 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.

  • Helm und EKS

    Ein Helm-Chart mit IRSA, NetworkPolicies, PodSecurity „restricted“, Autoscaling und Migrations-Job.

  • Mensch in der Schleife

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

  • Zeitpläne mit Änderungsprüfung

    Geplant

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

  • Richtlinien und Hardening-Agent

    Geplant

    Versionierte Entwicklungsrichtlinien hängen an einem Agenten oder Mandanten. Ein globaler Hardening-Agent prüft, was Entwicklungs-Agenten liefern, gegen unternehmensweite Regeln und kann Entscheidungen nur verschärfen.

  • Dark Software Factory

    Geplant

    Optional: Agenten führen eine Aufgabe von der Spezifikation bis zu Code, Tests und Pull Request mit minimalem menschlichem Eingriff. Nur für MVP- und Proof-of-Concept-Entwicklung empfohlen, nicht für Produktionsänderungen ohne Prüfung.

Runner

Agenten laufen überall.

Im Prozess, auf dem Laptop, in Containern, auf Kubernetes oder EKS, in AWS Lambda, GitHub Actions oder GitLab CI. 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

    Docker oder Podman: ein kurzlebiger Container pro Lauf, schreibgeschützt, ausgehender Verkehr nur per Allowlist.

  • Roadmap

    Kubernetes / EKS

    Ein Job pro Lauf mit eigenem ServiceAccount, IRSA und NetworkPolicy.

  • 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.

Heute laufen Worker im Prozess oder lokal. Als Nächstes folgen Container und Kubernetes/EKS, danach AWS Lambda und CI-Runner.

Roadmap

Eigenes Harness mitbringen. Optional.

Claude Code, OpenCode, Hermes oder OpenClaw können einen Agenten ausführen. 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. 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. #2 policy.decision agent:triage cve-db/lookup_cve allow prev abb116…d89a hash c68b8a…d781
  2. #3 step.tool_call agent:triage cve-db/lookup_cve prev c68b8a…d781 hash 43dcf3…f9fd
  3. #4 policy.decision agent:notify tickets/delete_ticket deny prev 43dcf3…f9fd hash 7348b5…12ba
  4. #5 run.completed worker run/4821 prev 7348b5…12ba hash fe7bf2…4771
Kette geprüft Signierter 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.

Rolle agentsrunsconnectionspoliciesauditcosts
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 $
Monatsbudget 70,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.

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 Erwähnung in Teams 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. Jede Änderung passiert dieselbe Art von Prüfungen, die die Plattform für Ihre Agenten durchsetzt – und nichts wird ohne menschliche Prüfung veröffentlicht.

agentix-zero ist das Agenten-Konto des Projekts. Menschen prüfen jede Änderung und tragen die Entscheidungen.

Prüfungen für jeden Commit

  • Conventional Commit bestanden
  • Tests · Abdeckung ≥ 80 % bestanden
  • Keine Anfragen an Dritte bestanden
  • Menschliche Prüfung bestanden

Letzte Commits von agentix-zero

  1. 3f52775 feat(site): rework the mobile scroll experience of the how-it-works section (#15)

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, Mandanten, Runner im Prozess und lokal.

  2. 0.2

    Worker-Knoten in Containern und auf Kubernetes/EKS, mit signierten, gescannten Toolbox-Images.

  3. 0.3

    Runner für AWS Lambda, GitHub Actions und GitLab CI; optionale externe Harnesses.

  4. 1.0

    Stabile APIs, signierte Releases, dokumentierte Upgrades und eine öffentliche Demo.

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 folgen Live-Demo bald verfügbar

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.