Wie GitLab den Code pro agentischem Flow um 45 % senkte

GitLab Duo Agent Platform orchestriert und automatisiert komplexe Aufgaben über agentische Flows. Ein zentraler Bestandteil der Plattform ist die Flow Registry, ein deklaratives Konfigurations-Framework aus wiederverwendbaren Komponenten, das YAML in voll funktionsfähige LangGraph-Flows kompiliert. Mit der Flow Registry können Agent-Builder (sowohl unsere GitLab-Entwickler(innen) als auch unsere Kund(inn)en) deklarative YAML-Konfigurationen verwenden, statt sich wiederholende, ad hoc geschriebene Python-Implementierungen. Die Flow Registry verwandelt maßgeschneidertes State-Management und Agenten-Verdrahtung, die zuvor über Agenten hinweg dupliziert wurde, in einen Satz wiederverwendbarer Komponenten und Primitive, die Agent-Buildern zur Verfügung stehen.

Der Einsatz der Flow Registry hat unseren eigenen Code pro agentischem Flow um 45 % gesenkt. Was bedeutet das konkret?

• Schnellere Iteration dank eines deklarativen Frameworks mit wiederverwendbaren Komponenten und Primitiven.
• Höhere Zuverlässigkeit, weil einmalige Implementierungsfehler und Boilerplate-Bugs auf Komponentenebene abgefangen werden.
• Geringere Wartungskosten, weil Verbesserungen an der Plattform einmal vorgenommen werden, aber allen Agenten zugutekommen.
• Abwärtskompatibilität unserer Funktionen (für unsere von GitLab erstellten Foundational Flows ebenso wie für die eigenen Flows unserer Kund(inn)en) dank der Abstraktionsschicht.

All diese Vorteile stehen Kund(inn)en zur Verfügung, die Agenten auf GitLab Duo Agent Platform orchestrieren und bauen.

In diesem Artikel teilen wir die architektonischen Prinzipien und Erkenntnisse aus diesem Vorhaben und zeigen, wie sie sich im eigenen Umfeld anwenden lassen.

LangGraph als Fundament für GitLab Duo Agent Platform

Nach der Veröffentlichung von GitLab Duo Code Suggestions und Duo Chat haben wir uns in eine damals neuartige Technologie eingearbeitet: autonome Agenten. Wir haben die verfügbaren KI-Frameworks untersucht und LangGraph ausgewählt: eine Agenten-Laufzeit und ein Low-Level-Orchestrierungs-Framework von LangChain, als Fundament für GitLab Duo Agent Platform.

Der umfangreiche Funktionsumfang von LangGraph (darunter eine breite Palette an Modell-Adaptern, durable execution und Nachvollziehbarkeit) brachte zusammen mit einem hohen Maß an technischer Autonomie alle Bausteine mit, die wir für den Start der Entwicklung von GitLab Duo Agent Platform suchten.

In den ersten Monaten bauten die GitLab-Entwickler(innen), unterstützt von LangGraph, zügig die Grundlagen von Duo Agent Platform, und schon bald lieferte das Team vier agentische Flows aus:

• Software Development Flow
• Duo Agentic Chat
• Convert to GitLab CI/CD Flow
• Developer Flow

Schnell erkannten wir auch eine kritische Lücke, die Low-Level-Frameworks wie LangGraph nicht schließen: das Fehlen einer Struktur, die konsistente Entwicklung im großen Maßstab trägt.

Schon bei nur vier Flows und einem kleinen Entwicklungsteam, das damals an GitLab Duo Agent Platform arbeitete, wuchs die Codebasis rasant. Jeder Flow war als ad hoc erstellter gerichteter Graph implementiert und wurde so zu einem Geflecht aus miteinander verbundenen Knoten und Kanten. Die frühe Codebasis von Duo Agent Platform hatte keine Wiederverwendbarkeit, keine Komponierbarkeit und kaum gemeinsame Standards. Neue Funktionen zu entwickeln wurde sehr schwierig, und jede horizontale, plattformweite Änderung schien eine unlösbare Aufgabe.

Da jeder Flow mindestens 450 Zeilen ad hoc geschriebenen Python-Code umfasste und wie dieses Beispiel aussah, verlangsamte sich das Tempo des Teams: Die Entwickler(innen) taten sich schwer damit, Änderungen einzubringen, überwältigt von Komplexität und Kopplung.

Die Komplexität des Graphen griff auch auf die Testsuite über. Jeder Testfall hing von einer Ausführung ab, die sich durch einen ganzen Graphen fortpflanzte, was die Tests von einem Sicherheitsnetz für die Qualitätssicherung in einen Angstgegner verwandelte, den niemand ansehen wollte.

Uns wurde klar, dass Graphen als atomarer Baustein auf dieser niedrigen Abstraktionsebene keine gute Grundlage für eine Plattformimplementierung sind. Um den angestrebten Maßstab zu tragen, mussten kleinere Einheiten eingeführt werden, die die Komplexität aufbrechen und die kognitive Last der Plattform-Entwickler(innen) senken, die das Projekt pflegen.

Zudem waren Graphen mit Low-Level-Knoten, die Modell-API-Aufrufe verwalten oder die von diesen Modellen erzeugten Funktionsaufrufe ausführen, auch für KI-Entwickler(innen) nicht die richtige Abstraktion, denn diese sind eher mit Begriffen wie Agenten und Agenten-Orchestrierung vertraut.

Auf der Suche nach einem Ausweg aus diesem Labyrinth entschieden wir uns, diese beiden Belange zu trennen (KI-Engineering von der Plattformentwicklung), und führten eine neue Abstraktionsschicht ein. Dazu prüften wir die bestehenden Graphen, identifizierten wiederkehrende Strukturen und extrahierten sie (zum Beispiel Zyklen zwischen Aufrufen eines Large Language Model (LLM) und Tool-Ausführung, die Agenten-Schleifen umsetzen). Der Refactor brachte etwas Entlastung, denn die komplexesten Dateien waren in kleinere Teile zerlegt worden, die die neue Abstraktionsschicht bildeten.

Doch die Plattform war noch weit von einem skalierbaren Zustand entfernt. Die extrahierten Graph-Teile arbeiteten leider mit ihren eigenen Zustandsstrukturen, eng gekoppelt an den Flow, aus dem sie stammten. Das hinderte uns daran, extrahierte Einheiten zwischen verschiedenen Flows wiederzuverwenden, und wir befürchteten, dass an diesem Punkt jeder neue Flow eher seinen eigenen Satz an Teilen erzeugen würde, statt aus bereits vorhandenen zusammengesetzt zu werden. Das System war weder kollaborativ noch effizient, und in diesem Zustand über längere Zeit nicht tragfähig.

Diese Erkenntnis machte deutlich: Wir mussten mehr investieren, die Architektur weiterentwickeln und klare Entwicklungsrichtlinien vorgeben. Zu diesem Zeitpunkt wussten wir bereits, dass Duo Agent Platform Flows nicht ausschließlich von anderen Produktteams gebaut würden, sondern dass auch eine breitere GitLab-Community zur Mitarbeit eingeladen werden sollte.

LangGraph-Details hinter dem neuen Flow-Registry-Framework abstrahieren

Ausgestattet mit dieser Erfahrung und angetrieben von ehrgeizigen Zielen gingen mein Teamkollege Alexander Chueshev und ich zurück ans Reißbrett und dachten das System neu. Wir wollten eine Lösung schaffen, die in hohem Maße kollaborativ, komponierbar und auf die Effizienz der KI-Entwicklung optimiert ist.

Diese neue Iteration sollte die Low-Level-Implementierungsdetails von LangGraph verbergen und Entwickler(innen) nicht länger mit Knoten oder Kanten behelligen. Das System sollte ihre Sprache sprechen (die Sprache des KI-Engineerings), mit Agenten als zentraler Komponente.

Uns war klar, dass KI-Entwicklung in Agenten denkt und nicht in Knoten, die Modelle aufrufen, Tools ausführen und so weiter. Aus den Lehren der vorigen Iteration entschieden wir uns, das neue Framework auf drei Säulen zu stellen:

1. Components
2. Routers
3. Shared State Structure

Wir waren überzeugt: Wenn es uns gelänge, sie gut zu entwerfen, wäre das neue Framework flexibel genug, um jeden KI-Flow zu tragen, den Nutzer(innen) bauen möchten.

1. Säule: KI-Engineering-Primitive als Components

Components sind die zentrale und wichtigste Säule der Flow Registry. Sie modellieren gängige Primitive wie Agenten, Human-in-the-Loop-Checkpoints und Schritte mit fester Logik. Diese Säule hebt die Abstraktionsebene auf die im KI-Engineering übliche Terminologie. Dank Components müssen Agent-Builder diese Primitive nicht länger von Grund auf neu implementieren, sondern können sie mit YAML-Snippets deklarieren, die wie dieses Beispiel aussehen:

           - type: AgentComponent
        name: "developer_agent"
        prompt_id: "developer_agent_prompt"
        inputs:
          - from: "context:goal"
            as: "goal"
          - from: "context:project_id"
            as: "project_id"
        toolset:
          - "read_file"
          - "find_files"
          - "edit_file"
          - "run_command"
          - "create_merge_request"

    

Unter der Haube ist die AgentComponent weiterhin ein Teil eines LangGraph-Graphen, dessen vereinfachte Struktur das folgende Diagramm zeigt. Ihre Implementierungskomplexität bleibt Agent-Buildern jetzt jedoch verborgen, die mit einem vertrauteren Primitiv arbeiten. Von denselben architektonischen Grenzen profitieren auch die Framework-Maintainer: Sie erhalten mehr Freiheit, die zugrunde liegende Implementierung zu ändern und zu erweitern, wobei sich Änderungen transparent auf die Flows übertragen.

flowchart LR
    %% External input/output
    input((inputs<br>from<br>shared state)) --> LLMCall
    End --> output((outputs<br>to shared state))

    %% Prompts
    Prompt["You are expert<br>software<br>engineer ..."] --> LLMCall
    subgraph Prompts
        direction TB
        style Prompts stroke-dasharray: 4 4, stroke:#3CB371
        Prompt
    end

    %% LLM and internal component
    LLMCall --> End
    LLMCall --> RunTools
    RunTools --> LLMCall

    subgraph Component
        direction LR
        LLMCall[LLM Call]
        RunTools[Run Tools]
        End[END]
    end

    %% Tools
    EditFile --> RunTools
    ReadFile --> RunTools

    subgraph Tools
        direction LR
        style Tools stroke-dasharray: 4 4, stroke:#1E90FF
        EditFile[Edit file]
        ReadFile[Read file]
    end

Der Agent als Component, mit der Fähigkeit, Arbeit an Subagenten zu delegieren, ist bereits eine mächtige Basis, die die 1. Säule allein liefert. Viele aktuelle Agentenplattformen betrachten das als vollständiges und ausreichendes Angebot. GitLab hat mit Duo Agent Platform jedoch größere Ambitionen, die die Flow Registry mit den nächsten beiden Säulen umsetzt.

2. Säule: Routers, um Components zu Flows zu orchestrieren

Mit den Routers der Flow Registry können Agent-Builder mehrere spezialisierte Agenten oder sogar ganze Agenten-Teams zu einem Flow orchestrieren, um hochkomplexe geschäftliche oder Softwareentwicklungs-Prozesse abzubilden. Auch wenn die größten aktuellen Modelle mächtig genug sind, komplexe Aufgaben allein zu bewältigen, zeigt der jüngste Popularitätsschub der Subagenten-Architektur, dass es viele Vorteile hat, mehrere Agenten für eine einzelne Aufgabe zusammenarbeiten zu lassen.

Als praktisches Beispiel werfen wir einen Blick auf einen Foundational Flow von GitLab: Fix pipeline. Dieser Flow ist mit einem automatischen Trigger konfiguriert, um fehlschlagende CI-Pipelines zu triagieren und zu beheben. Weil CI-Pipelines sehr komplex sein können, erfordert nicht jeder Fehlschlag eine Codeänderung zur Lösung – manchmal reagiert etwa ein abhängiger Dienst nicht, und ein einfacher Retry genügt, um den Fehlschlag zu beheben. Um diesem zweigleisigen Ansatz gerecht zu werden, verzweigt sich der Flow früh, gestützt auf die Entscheidung eines Agenten, der als Judge fungiert. Das Urteil des Judge-Agenten darüber, ob ein Fehlschlag zu bearbeiten ist, nutzen die Routers der Flow Registry dann, um die Flow-Ausführung in den richtigen Zweig zu lenken.

      routers:
 - from: "fix_pipeline_context"
    condition:
      input: "context:fix_pipeline_context.final_answer.decision"
      routes:
        "add_comment": "fix_pipeline_add_comment"
        "create_plan": "fix_pipeline_checkout_existing_branch"
        "direct_code_suggestions": "fix_pipeline_code_suggestions"
        "no_action": "end"
        "default_route": "end"

    

Es stimmt, dass Modelle nach dem Stand der Technik ähnliche Entscheidungen treffen und gleichzeitig umsetzen können sollten. Dank Multi-Agenten-Architektur können Agent-Builder jedoch die folgenden Vorteile nutzen:

1. Kleinere, günstigere Modelle können die größten und teuersten ersetzen – ein sich summierender Kostenvorteil bei hochfrequenten automatisierten Flows, die hunderte Male pro Tag laufen.
2. Die Sicherheitslage verbessert sich durch Rollentrennung: Lese- und Schreibrechte lassen sich auf verschiedene Agenten aufteilen.
3. Prozess-Leitplanken lassen sich durchsetzen, wenn der Workflow von vornherein bekannt ist, was bei strukturierten Aufgaben die Abhängigkeit vom Modellurteil verringert.

Die 2. Säule gibt Agent-Buildern die Wahl: eine einfache Flow-Architektur mit mächtigen Modellen nutzen oder Komplexität aus den Modell-Prompts in eine explizite Flow-Struktur auslagern – passend für eine breite Palette möglicher Anwendungsfälle, Kostenziele und Risikoprofile.

3. Säule: Shared State Structure

Die dritte und letzte Säule der Flow Registry ist eine Shared State Structure, die als Kommunikationsprotokoll zwischen Components dient. Ohne sie könnten die vorigen beiden Säulen nicht funktionieren, weil den Components eine verlässliche Möglichkeit zur Kommunikation fehlte. Zurück zum Beispiel Fix pipeline: Das Urteil des Judge-Agenten wäre wenig wert, ließe es sich nicht zuverlässig an einen Router der Flow Registry weiterreichen. Allgemeiner gilt: Daten, die ein Agent erzeugt, werden oft von nachfolgenden Agenten gebraucht, was einen klar definierten Kommunikationsvertrag unverzichtbar macht.

Die State Structure der Flow Registry enthält ein besonderes Catch-all-Attribut namens context, das sich wie ein verschachtelter Key-Value-Store (oder ein JSON-Objekt) verhält und Components einen vielseitigen Speicherraum gibt. Um die Flexibilität des context-Attributs weiter zu ergänzen, führte die Flow Registry einen deklarativen Zugriff auf context in Punktnotation ein – eine Konvention, die aus anderen Domänen vertraut ist (etwa GitLab CI Functions), in denen der Zugriff auf einen gemeinsamen Key-Value-Speicher innerhalb statischer Konfigurationen ausgedrückt werden muss.

Zur Vervollständigung der dritten Säule braucht es eine Konvention: Die Flow Registry unterstützt flexible Lesezugriffe auf den Shared State über besagte Punktnotation, doch alle Schreibzugriffe folgen strengen Regeln und liefern einen Satz stabiler, vorhersehbarer Ausgaben, auf die sich Agent-Builder verlassen können. Um das in der Praxis zu sehen, werfen wir noch einmal einen Blick auf ein Stück Flow-Registry-Konfiguration für einen weiteren Foundational Flow: Code review.

      # …

 # Step 5: Fetch lightweight MR metadata (file paths + custom instructions)
  - name: "fetch_mr_metadata"
    type: DeterministicStepComponent
    tool_name: "build_review_merge_request_context"

# ….

  # Step 6: Transform prescan results into structured JSON for review consumption
  - name: "analyze_prescan_results"
    type: AgentComponent
    prompt_id: "analyze_prescan_codebase_results"
    prompt_version: "^1.0.0"
    inputs:
      - from: "context:fetch_mr_metadata.tool_responses"
        as: "mr_context"
      - from: "context:prescan_codebase.tool_responses"
        as: "prescan_tool_responses"
        optional: True
    toolset: []
    ui_log_events:
      - "on_agent_final_answer"

# …..

routers:
 #  ….
  - from: "fetch_mr_metadata"
    to: "analyze_prescan_results"

    

Der Agent analyze_prescan_results von Code review braucht Daten, die ein vorausgehender fester Schritt fetch_mr_metadata zieht. Diese Abhängigkeit wird über die für den Agenten analyze_prescan_results deklarierten inputs ausgedrückt.

          inputs:
      - from: "context:fetch_mr_metadata.tool_responses"
        as: "mr_context"

    

Hier greifen Punktnotation und strenge Ausgabekonventionen ineinander und geben Agent-Buildern ein stabiles, vorhersehbares Protokoll, um Daten zwischen Components innerhalb eines Flows zu bewegen.

Von Python zu YAML

Auch wenn die Flow Registry deklarative YAML-Konfigurationen nutzt, begannen wir Entwurf und Rearchitektur in Python und verschoben eine deklarative Konfigurations-API auf spätere Iterationen. Sobald jedoch alle drei Säulen der Flow Registry in einem einzigen Python-Block zusammenkamen, wurde uns klar, dass es nur ein Schritt war, diese Deklarationen in eine YAML-Konfiguration zu überführen – also gingen wir ihn.

Diese Änderung entkoppelte das Flow-Registry-Framework vollständig von Python und LangGraph und bot eine High-Level-Abstraktionssyntax für die deklarative Erstellung von KI-Flows. Sie zog eine saubere Grenze zwischen der weiterhin auf LangGraph-Grundlagen implementierten Plattform und der deklarativen Schnittstelle des externen Frameworks, die es KI-Entwickler(inne)n ermöglichte, mit für sie vertrauteren Konzepten zu arbeiten.

Die Einführung des Flow-Registry-Frameworks als Basis für GitLab Duo Agent Platform trieb das gesamte System von reinen LangGraph-Implementierungen pro Anwendungsfall hin zu deklarativen YAML-Konfigurationen wie dieser hinter dem GitLab Duo Developer Flow, der aktuell in Produktion läuft.

Da die Plattform von der für KI-Entwickler(innen) gestalteten Framework-API entkoppelt ist, wird die zugrunde liegende Python-Codebasis über alle Flows hinweg gemeinsam nutzbar, und jede Verbesserung an der Engine selbst kommt allen Flows zugute – was die Effizienzgewinne aus der klaren Trennung zusätzlich unterstreicht.

Zudem sinken die Codekosten pro Flow mit jedem neuen Flow. Zum Zeitpunkt des Schreibens wurde der Anteil des Python-Quellcodes pro Flow um 45 % reduziert – zugunsten der Flow Registry, und der Wert wird sich mit jedem neu gebauten Flow weiter verbessern.

Schließlich müssen KI-Entwickler(innen) und Fachexpert(inn)en keine der zugrunde liegenden Implementierungsdetails der Plattform mehr verstehen, noch müssen sie sich wiederholenden Boilerplate-Python-Code schreiben, der eine eigene Testsuite und Wartung bräuchte. Das bewiesen die fast 7.000 Entwickler(innen), die sich Anfang dieses Jahres für den GitLab AI Hackathon anmeldeten und über 600 Agenten und Flows einreichten.

Wichtigste Erkenntnisse

Eine zentrale Beobachtung war für uns, dass modernes KI-Engineering noch ein sehr junger Zweig der Softwareentwicklung ist, in dem sich gängige Architekturmuster und Paradigmen noch nicht vollständig herausgebildet haben. Das heißt aber nicht, dass sich bereits etablierte gute Praktiken der Softwareentwicklung nicht auf das KI-Engineering anwenden ließen. Tatsächlich zeigt die Geschichte der Flow Registry, dass der Rückgriff auf vorhandene Paradigmen und Praktiken der Softwareentwicklung (etwa wiederkehrenden Code zu identifizieren, ihn in benannte Einheiten mit klaren Rollen im System zu extrahieren und daraus Abstraktionsschichten zu bilden) kraftvolle Ergebnisse liefern kann.

Darüber hinaus möchten wir einige weitere Erkenntnisse teilen, die breit für jedes Team gelten, das agentische Systeme baut, während andere praktische Ansatzpunkte für Teams sind, die mit Low-Level-Frameworks wie LangGraph arbeiten.

Allgemeine Prinzipien

1. Manche aktuellen agentischen Frameworks arbeiten trotz großer Mächtigkeit auf einer für den Bedarf des KI-Engineerings zu niedrigen Abstraktionsebene und vermischen Plattformbelange mit der Agentenentwicklung.
2. Die Trennung der Ausführungsplattform vom KI-Engineering ermöglicht es Fachleuten beider Domänen, mit mehr Sicherheit und Tempo zu arbeiten.

Praktische Ansatzpunkte für Nutzer(innen) von Low-Level-Frameworks

1. Die Trennung von KI-Flows und Plattformimplementierung lässt sich beginnen, indem wiederkehrende Strukturen aus bestehenden KI-Flows extrahiert werden – Agenten-Schleifen sind ein guter Anfang.
2. Ein flexibles gemeinsames Datenmodell gelingt dank eines Key-Value-Store-artigen Attributs, das dem Modell hinzugefügt wird und Mustern folgt, die andere Orchestrierungs-Frameworks auch außerhalb der KI-Domäne etabliert haben.

Flow Registry ausprobieren

Um ein Gefühl dafür zu bekommen, wie das alles in der Praxis funktioniert, besuche den AI Catalog, in dem GitLab das daraus entstandene Orchestrierungs-Framework Flow Registry für alle bereitstellt, um eigene Flows zu bauen.

Du kannst GitLab Duo Agent Platform auch kostenlos ausprobieren.