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

Die Fragmentierung der KI‑Agent‑Frameworks ist vorbei: GitAgent definiert Agenten als strukturierte Git‑Repositories, die sich nahtlos zwischen LangChain, AutoGen, Claude Code, OpenAI und CrewAI portieren lassen – mit integrierter Compliance, Versionierung und Human‑in‑the‑Loop‑Review.

---

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 einfach so in LangChain. Ein CrewAI‑Agent lässt sich nicht ohne großen Aufwand auf AutoGen portieren. Jeder Wechsel bedeutet komplette Neuimplementierung, hohe Switching‑Costs und technische Schuld.

GitAgent löst dieses Problem mit einem radikal 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 generiert die notwendigen Framework‑spezifischen Dateien – die Agent‑Logik (SOUL.md, Skills, Tools) bleibt dabei unverändert. So kann ein Team etwa einen Agenten lokal in Claude Code entwickeln, ihn für Staging in LangChain deployen und für Production auf OpenAI Assistants umziehen – ohne eine Zeile Prompt‑Engineering neu schreiben zu müssen.

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 – genau wie Code. git blame zeigt, wer welche Regel wann hinzugefügt hat. git revert macht fehlerhafte Prompt‑Änderungen rückgängig. CI/CD‑Pipelines validieren Agent‑Definitionen vor dem Merge.

Compliance by Design: FINRA, SEC & Segregation of Duties

Für Unternehmen in regulierten Branchen (Banken, Versicherungen, Healthcare) bietet GitAgent First‑Class‑Support 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 definiert man Rollen (maker, checker, executor, auditor), legt Konflikt‑Paare fest (maker darf nicht auch checker sein) und erzwingt Mehr‑Agenten‑Validierung für kritische Aktionen (z.B. Kreditentscheidungen, regulatorische 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

Der Validator (gitagent validate --compliance) prüft vor dem Deployment, ob keine 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 ein standardisiertes Git‑Repository ist – eine Design‑Entscheidung, die direkt aus dem GitHub‑Repo hervorgeht – lässt er sich forken, clonen, branch‑en 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.

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

Fazit

GitAgent löst das Fragmentierungs‑Problem der KI‑Agent‑Frameworks, indem es Agenten als Git‑Repositories definiert. Die Vorteile:

1. Portabilität – Einmal definiert, überall lauffähig (Claude Code, LangChain, OpenAI, …)
2. Versionierung – Full Git‑History für Prompt‑Änderungen, Memory‑Updates und Skill‑Erweiterungen
3. Compliance by Design – FINRA/SEC‑konforme Segregation of Duties, Audit‑Trails, Human‑Review
4. Open‑Source‑Sharing – Agenten werden zu forkbaren, modular wiederverwendbaren Komponenten

Wer heute mit KI‑Agenten arbeitet, sollte GitAgent im Blick behalten – es könnte der Docker‑Moment für die Agent‑Entwicklung sein.

Links:

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