Managed Agent Runs: Autonome Agenten, die an Ihrer Architektur arbeiten, waehrend Sie schlafen

Vor zwei Wochen haben wir den Agent Hub mit Conformance-Guardrails gestartet — Regeln, die KI-Agenten sagen, was sie tun duerfen und was nicht. Das war die defensive Ebene. Heute fuegen wir die offensive hinzu.

Mit Managed Agent Runs koennen Sie autonome KI-Agenten direkt aus Archyl heraus starten. Geben Sie ihnen eine Aufgabe, verbinden Sie sie mit Ihren Tools, legen Sie einen Zeitplan fest und lassen Sie sie arbeiten. Sie klonen Ihr Repository, lesen Ihre Architektur, rufen externe Dienste auf und berichten alles, was sie getan haben — jeden Tool-Aufruf, jede Entscheidung, jeden verbrauchten Token.

Das ist kein "Chatten mit Ihrer Architektur." Das ist ein Agent, der echte Arbeit leistet, autonom, an Ihrer Codebasis.

Warum Managed Runs?

Das Muster, das wir immer wieder sahen, war folgendes: Teams richteten Conformance-Regeln ein, generierten ihre CLAUDE.md-Datei und fuehrten dann Agenten manuell in ihrem Terminal aus. Kontext kopieren, in Claude Code einfuegen, Aufgabe ausfuehren, Ergebnis pruefen. Jedes einzelne Mal.

Das fehlende Stueck war Automatisierung. Sie sollten keinen Agenten beaufsichtigen muessen, der eine Routineaufgabe erledigt. Jeden Montagmorgen auf veraltete Abhaengigkeiten pruefen? Das sollte ein Zeitplan sein. Offene PRs nach jedem Merge gegen Architekturregeln pruefen? Das sollte automatisch passieren. Einen woechentlichen Bericht ueber Architektur-Drift erstellen? Einrichten und vergessen.

Managed Runs schliessen diese Luecke. Definieren Sie die Aufgabe, waehlen Sie einen Zeitplan, und Archyl uebernimmt den Rest — Klonen, Kontextinjektion, Ausfuehrung und Ueberwachung.

Anatomie eines Runs

Jeder Managed Run folgt demselben Lebenszyklus:

  1. Klonen — Der Agent klont das Repository Ihres Projekts in einen isolierten Arbeitsbereich. Frische Kopie, keine Kontamination durch fruehere Runs.

  2. Kontextinjektion — Bevor der Agent eine einzige Zeile Code schreibt, erhaelt er Ihren vollstaendigen architektonischen Kontext: C4-Modell, ADRs, Conformance-Regeln, Technologie-Stack, API-Vertraege. Dieselben get_agent_context-Daten, die auch die Guardrails antreiben, werden automatisch injiziert.

  3. Ausfuehrung — Der Agent arbeitet Ihre Aufgabe ab. Er kann Dateien lesen, Code schreiben, externe Tools aufrufen und Entscheidungen treffen. Jede Aktion wird als Ereignis in einem Echtzeit-Feed protokolliert.

  4. Berichterstellung — Wenn der Run abgeschlossen ist (oder das Iterationslimit erreicht), erhalten Sie eine vollstaendige Ablaufverfolgung: jeden Tool-Aufruf mit Ein- und Ausgabe, Status-Badges, Token-Zaehler, verstrichene Zeit.

Die Run-Detailseite zeigt alles. Tool-Aufrufe sind aufklappbare Karten mit syntaxhervorgehobenem JSON. Jede Karte zeigt, von welchem Connector das Tool stammt — "github" fuer GitHub-API-Aufrufe, "archyl" fuer Architektur-Abfragen, "linear" fuer Issue-Tracking. Sie koennen genau nachvollziehen, was der Agent getan hat und warum.

Connectors: Beliebige MCP-Dienste anbinden

Hier wird es interessant. Managed Runs kommunizieren nicht nur mit Archyl. Sie koennen mit allem kommunizieren, das MCP (Model Context Protocol) spricht.

Mit Connectors koennen Sie externe Dienste an Ihre Agent Runs anbinden. Standardmaessig unterstuetzen wir:

  • GitHub — PRs lesen, CI-Status pruefen, Issues auflisten, Code reviewen
  • GitLab — Dieselben Funktionen fuer GitLab-gehostete Projekte
  • Linear — Issues lesen und aktualisieren, Sprint-Fortschritt pruefen
  • Slack — Nachrichten senden, Channels lesen, Teams benachrichtigen
  • Jeder MCP-Server — Wenn er MCP-Tools bereitstellt, koennen Sie ihn verbinden

Das Einrichten eines Connectors dauert dreissig Sekunden. Geben Sie ihm einen Namen, fuegen Sie die Server-URL ein, ergaenzen Sie bei Bedarf Authentifizierungs-Header, und Archyl wird den Server abfragen, um verfuegbare Tools zu ermitteln. Sie sehen jedes Tool, das der Connector bereitstellt, bevor Sie speichern.

Wenn Sie einen Run oder Zeitplan erstellen, waehlen Sie aus, welche Connectors angebunden werden sollen. Der Agent erhaelt Zugriff auf alle Tools aller angebundenen Connectors, per Connector-Name als Namespace. Ein GitHub-Tool erscheint als github__list_pull_requests. Ein Linear-Tool erscheint als linear__get_issue. Keine Kollisionen, keine Mehrdeutigkeiten.

Dieses Namespacing ist wichtig. Wenn Sie den Event-Feed eines Runs betrachten, zeigt jeder Tool-Aufruf seine Quelle. Sie koennen sofort erkennen, ob der Agent Ihr Architekturmodell abgefragt, einen GitHub-PR gelesen oder eine Nachricht in Slack gepostet hat. Volle Transparenz darueber, was der Agent beruehrt hat und wo.

Zeitplaene: Cron-basierte Automatisierung

Manche Aufgaben sollten nicht darauf warten, dass ein Mensch auf "Run" klickt. Mit Zeitplaenen koennen Sie wiederkehrende Agent Runs mit Standard-cron-Ausdruecken definieren.

Einige Beispiele, was Teams bereits tun:

Woechentliche Architektur-Review — Jeden Montag um 9 Uhr prueft ein Agent die Codebasis auf Architektur-Drift. Er vergleicht die tatsaechliche Code-Struktur mit dem C4-Modell, markiert neue Abhaengigkeiten, die nicht dokumentiert sind, und identifiziert Komponenten, die ueber ihren vorgesehenen Umfang hinausgewachsen sind.

PR-Conformance-Check — Nach jedem Merge in main prueft ein Agent den Diff gegen Conformance-Regeln. Er erkennt Muster, die durch die CI gerutscht sind — keine Syntaxfehler, sondern architektonische Verstoesse, die nur im Kontext des Gesamtsystems Sinn ergeben.

Abhaengigkeits-Audit — Jeden Mittwoch scannt ein Agent den Abhaengigkeitsbaum auf bekannte Schwachstellen, veraltete Pakete und Versionskonflikte zwischen Diensten. Er erstellt eine Zusammenfassung mit Schweregrad-Bewertungen und vorgeschlagenen Updates.

Dokumentations-Synchronisation — Jeden Freitagnachmittag vergleicht ein Agent die aktuelle Codebasis mit der Projektdokumentation. Fehlende Endpunkte, veraltete Beschreibungen, neue Dienste ohne Dokumentation — alles wird markiert.

Jeder Zeitplan zeigt seinen cron-Ausdruck, die naechste Ausfuehrungszeit, die letzte Ausfuehrungszeit und den Aktiv-/Pausiert-Status. Sie koennen einen Zeitplan pausieren, ohne ihn zu loeschen, ihn manuell ausserhalb seines normalen Rhythmus ausloesen oder Aufgabentext und Timing jederzeit bearbeiten.

Die Run-Detailseite

Wir haben viel Zeit in das Monitoring-Erlebnis investiert, denn Transparenz ist alles, wenn Sie einen Agenten autonom arbeiten lassen.

Die Run-Detailseite bietet Ihnen:

  • Status auf einen Blick — Laufend, abgeschlossen, fehlgeschlagen oder abgebrochen. Farbcodiertes Badge, sofort sichtbar.
  • Token-Verbrauch — Eingangs- und Ausgangs-Tokens, damit Sie die Kosten pro Run verfolgen koennen.
  • Verstrichene Zeit — Wie lange der Agent gearbeitet hat, waehrend der Ausfuehrung in Echtzeit aktualisiert.
  • Run-ID — Fuer Nachverfolgbarkeit und Debugging.
  • Live-Event-Feed — Jede Aktion des Agenten erscheint als aufklappbare Karte. Tool-Aufrufe zeigen die Connector-Quelle, den Tool-Namen, Eingabeparameter und Ausgabe. Nachrichten zeigen das Reasoning des Agenten. Fehler werden hervorgehoben.

Der Feed ist fuer schnelles Scannen konzipiert. Eingeklappte Zeilen zeigen den Ereignistyp und eine einzeilige Zusammenfassung. Hovern Sie, um das Connector-Badge zu sehen, und klappen Sie fuer volle Details auf. Wenn etwas schiefgeht, graben Sie sich nicht durch Logs — Sie scrollen durch eine strukturierte Zeitleiste dessen, was genau passiert ist.

Architektur-bewusst von Anfang an

Jeder Managed Run erhaelt automatisch Zugriff auf den MCP-Server Ihres Archyl-Projekts. Das bedeutet, der Agent kann:

  • Das C4-Modell abfragen, um Systemgrenzen zu verstehen
  • ADRs lesen, um vergangene Entscheidungen nachzuvollziehen
  • Conformance-Regeln pruefen, um zu wissen, welche Muster einzuhalten sind
  • API-Vertraege durchsuchen, um Service-Schnittstellen zu verstehen
  • Technologie-Zuweisungen nachschlagen, um die richtigen Tools zu waehlen

Das ist keine optionale Integration. Es ist das Fundament. Der Agent startet nicht bei null — er startet bei Ihrer Architektur. Wenn er einen neuen Service erstellen muss, weiss er, zu welchem Container er gehoert. Wenn er Code schreibt, weiss er, welche Muster durchgesetzt werden. Wenn er eine Abhaengigkeit hinzufuegt, weiss er, welche Technologien freigegeben sind.

In Kombination mit externen Connectors entstehen so Agenten, die sowohl architekturbewusst als auch operativ leistungsfaehig sind. Sie kennen Ihr System und koennen mit Ihren Tools interagieren.

Erste Schritte

Managed Agent Runs sind ab sofort im Agent Hub fuer Business- und Scale-Plaene verfuegbar.

  1. Connector erstellen — Gehen Sie zu Agent Hub → Connectors. Fuegen Sie Ihren GitHub-, Linear- oder einen beliebigen MCP-kompatiblen Dienst hinzu.
  2. Run starten — Gehen Sie zu Runs → New Run. Beschreiben Sie Ihre Aufgabe, binden Sie Connectors an und starten Sie.
  3. Zeitplan einrichten — Gehen Sie zu Schedules → New Schedule. Waehlen Sie einen cron-Ausdruck, binden Sie Connectors an und lassen Sie es laufen.

Die Agenten sind bereit. Ihre Architektur ist der Kontext. Ihre Tools sind die Connectors. Setzen Sie sie jetzt ein.