GitAgent: Der Docker für KI‑Agenten – Framework-agnostische Portabilität für LangChain, AutoGen & Claude Code

GitAgent versucht, die Fragmentierung der KI-Agenten-Frameworks handhabbarer zu machen: Agenten werden als strukturierte Git-Repositories beschrieben, die sich in verschiedene Laufzeitumgebungen exportieren lassen, inklusive Versionierung und Review-Schleifen.

---

Das Problem: Fragmentierte Ökosysteme

Wer heute einen KI‑Agenten produktiv einsetzen will, steht vor einer zentralen Frage: Welches Framework? LangChain, AutoGen, CrewAI, OpenAI Assistants oder Claude Code – jedes bringt seine eigene Architektur, seine eigenen Boilerplate‑Dateien und sein eigenes Deployment‑Model mit.

Die Folge: Vendor‑Lock‑in. Ein Agent, den man für Claude Code schreibt, läuft nicht automatisch in LangChain. Ein CrewAI-Agent lässt sich nicht ohne Weiteres auf AutoGen übertragen. Jeder Wechsel bedeutet zusätzliche Anpassungen, höhere Switching Costs und oft neue technische Schuld.

GitAgent adressiert dieses Problem mit einem einfachen Ansatz: Agenten werden zu Git-Repositories.

GitAgent‑Architektur: Zwei Dateien reichen

Ein GitAgent‑Repository folgt einer klaren Verzeichnisstruktur, die Framework‑agnostisch ist – also unabhängig vom späteren Ausführungs‑Framework. Im Kern braucht es nur zwei Dateien:

• agent.yaml – das Manifest mit Name, Version, Model‑Präferenzen, Skills und Tools
• SOUL.md – die Identität des Agents: Persönlichkeit, Kommunikationsstil, Werte

Ergänzt werden können:

• RULES.md – harte Constraints und Safety‑Boundaries
• DUTIES.md – Segregation of Duties (SoD) für Compliance‑kritische Workflows
• skills/ – wiederverwendbare Fähigkeits‑Module (SKILL.md + Scripts)
• tools/ – MCP‑kompatible Tool‑Definitionen (YAML‑Schemas)
• memory/ – persistenter, versionskontrollierter Zustand (dailylog.md, context.md)
• workflows/ – deterministische Mehrschritt‑Abläufe
• hooks/ – Lifecycle‑Handler (bootstrap.md, teardown.md)
• compliance/ – regulatorische Artefakte

Die gesamte Agent‑Definition liegt damit in menschenlesbaren Markdown‑ und YAML‑Dateien – nicht verstreut in Python‑Code, Jinja2‑Templates oder Framework‑spezifischen Configs.

Framework‑Agnostische Portabilität: gitagent export

Das Herzstück von GitAgent ist der Export‑Mechanismus. Einmal als Git‑Repository definiert, lässt sich der Agent in jedes der großen Frameworks übersetzen:

# Export zu Claude Code (CLAUDE.md)
gitagent export --format claude-code

# Export zu OpenAI Assistants SDK
gitagent export --format openai

# Export zu LangChain/LangGraph
gitagent export --format langchain

# Export zu CrewAI (YAML)
gitagent export --format crewai

# Export zu AutoGen
gitagent export --format autogen

# Export zu OpenClaw
gitagent export --format openclaw

Der CLI-Befehl soll die nötigen framework-spezifischen Dateien generieren, während die Agent-Logik (SOUL.md, Skills, Tools) im Repository bleibt. Für Teams ist das vor allem als Portabilitätsversprechen interessant: Ein Agent kann lokal in Claude Code entstehen, später aber in andere Laufzeitumgebungen exportiert werden. Wie reibungslos das im Alltag funktioniert, hängt am konkreten Zielsystem und sollte eher als Designziel denn als garantierte Nahtlosigkeit gelesen werden.

Git als Human‑in‑the‑Loop‑Layer

GitAgent nutzt Git nicht nur als Versionskontrolle, sondern als Supervisions‑Schicht. Wenn ein Agent im Betrieb seine Memory‑Dateien (context.md, dailylog.md) aktualisiert oder eine neue Skill lernt, kann das System automatisch einen Git‑Branch und einen Pull Request erstellen.

Ein menschlicher Reviewer sieht dann im Diff, was sich geändert hat: Welche neuen Fakten hat der Agent gelernt? Hat sich seine Persönlichkeit (SOUL.md) ungewollt verschoben? Droht er zu halluzinieren?

Die Konsequenz: Agent-Verhalten wird auditierbar, revertierbar und reviewbar. git blame zeigt, wer welche Regel wann hinzugefügt hat. git revert macht fehlerhafte Prompt-Änderungen rückgängig. CI/CD-Pipelines können Agent-Definitionen vor dem Merge validieren.

Compliance by Design: FINRA, SEC & Segregation of Duties

Für Unternehmen in regulierten Branchen wie Banken, Versicherungen oder Healthcare positioniert sich GitAgent zudem mit Bausteinen für regulatorische Anforderungen:

• FINRA Rule 3110 – Supervision: Human‑in‑the‑Loop, Escalation‑Triggers, Kill‑Switch
• SEC 17a‑4 – Recordkeeping: Immutable Audit‑Logs, Retention Periods
• Segregation of Duties (SoD) – Maker‑Checker‑Prinzip in DUTIES.md

In der agent.yaml lassen sich Rollen (maker, checker, executor, auditor) definieren, Konflikt-Paare festhalten (maker darf nicht auch checker sein) und Freigabewege für kritische Aktionen modellieren, etwa bei Kreditentscheidungen oder regulatorischen Meldungen.

compliance:
  segregation_of_duties:
    roles:
      - id: maker
        description: Creates proposals
        permissions: [create, submit]
      - id: checker
        description: Reviews and approves
        permissions: [review, approve, reject]
    conflicts:
      - [maker, checker]  # maker cannot approve own work
    assignments:
      loan-originator: [maker]
      credit-reviewer: [checker]
    handoffs:
      - action: credit_decision
        required_roles: [maker, checker]
        approval_required: true
    enforcement: strict

Laut Projektbeschreibung soll ein Validator wie gitagent validate --compliance vor dem Deployment prüfen, ob definierte Compliance-Regeln verletzt werden.

Use Case: NVIDIA AIQ Deep Researcher

Ein praktisches Beispiel ist die Portierung von NVIDIA’s AIQ Deep Researcher – einem dreistufigen Agent‑Hierarchie (Orchestrator → Planner → Researcher), der wissenschaftliche Papers analysiert und zitierte Berichte erstellt.

Die originale Implementierung verteilt die Agent‑Identity über Jinja2‑Templates und Python‑Code. In GitAgent wird daraus:

examples/nvidia-deep-researcher/
├── agent.yaml          # Manifest + SOD policy
├── SOUL.md             # Orchestrator‑Identity (aus orchestrator.j2)
├── RULES.md            # Citation rules, report constraints
├── DUTIES.md           # Role separation: orchestrator ↔ planner ↔ researcher
├── agents/planner/     # Planner sub‑agent (aus planner.j2)
├── agents/researcher/  # Researcher sub‑agent (aus researcher.j2)
├── skills/{web,paper,knowledge}-search/
├── tools/*.yaml        # MCP‑kompatible Tool‑Schemas
└── config/             # Model‑Assignments pro Environment

Vorteile der GitAgent‑Version:

• Fork für neue Domänen – SOUL.md für Legal/Medical/Finance‑Research anpassen, ohne Python zu berühren
• Unabhängige Prompt‑Versionierung – git diff zeigt, wann der Orchestrator‑Style regrediert
• SoD‑Validierung – gitagent validate stellt sicher, dass der Orchestrator nicht gleichzeitig Researcher sein kann
• Export zu anderen Runtimes – dieselbe Identity läuft auf Claude Code, OpenAI oder als raw System‑Prompt

Ein zentraler Hebel: Agent-Sharing als Open-Source-Repos

Weil ein GitAgent als standardisiertes Git-Repository gedacht ist, lässt er sich forken, clonen, branchen und als Modul in anderen Projekten wiederverwenden. Ein skills/-Ordner aus einem Public-Repo kann in den eigenen Agenten integriert werden; eine getestete DUTIES.md-Policy lässt sich als Baseline für neue Compliance-kritische Agents übernehmen. Wer eher auf operative Speicher- und Orchestrierungsfragen schaut, findet mit dem Basic-Memory-Plugin für OpenClaw und Claude Codes Desktop-Automation zwei gut passende Gegenbeispiele aus anderen Schichten des Stacks.

Das eröffnet ein Open‑Source‑Ökosystem für KI‑Agenten: Teams teilen nicht nur Code‑Snippets, sondern vollständige, lauffähige Agent‑Definitionen – mit allen dazugehörigen Guardrails, Memory‑Strukturen und Compliance‑Regeln.

Für wen ist GitAgent?

• KI‑Entwickler, die nicht an ein einzelnes Framework gebunden sein wollen
• Unternehmen, die Agenten über mehrere Teams und Tech‑Stacks hinweg konsistent betreiben müssen
• Compliance‑Officer, die auditierbare, versionskontrollierte Agent‑Definitionen benötigen
• Open‑Source‑Communities, die wiederverwendbare Agent‑Komponenten teilen wollen
• Product‑Teams, die Human‑in‑the‑Loop‑Reviews in ihre Agent‑Workflows integrieren müssen

Was GitAgent interessant macht

GitAgent versucht, das Fragmentierungsproblem der KI-Agenten-Frameworks über Agenten als Git-Repositories anzugehen. Die Vorteile:

1. Portabilität – ein einheitlicheres Repository als Ausgangspunkt für mehrere Zielsysteme
2. Versionierung – Full Git‑History für Prompt‑Änderungen, Memory‑Updates und Skill‑Erweiterungen
3. Compliance by Design – Vorlagen für Segregation of Duties, Audit-Trails und Human-Review
4. Open‑Source‑Sharing – Agenten werden zu forkbaren, modular wiederverwendbaren Komponenten

Wer heute mit KI-Agenten arbeitet, sollte GitAgent im Blick behalten, vor allem als Versuch, Agenten-Spezifikation, Review und Portabilität in ein gemeinsames Repo-Modell zu ziehen. Ob daraus tatsächlich ein Standard wird, ist offen; als Denkmodell für teamsichere Agent-Entwicklung ist das Projekt trotzdem interessant.

Referenzen:

• GitHub‑Repo: open‑gitagent/gitagent
• Installation: npm install -g gitagent
• Beispiel: NVIDIA AIQ Deep Researcher
• Spezifikation: SPECIFICATION.md