How we build autonomous AI agents

Im ersten Teil dieser Serie haben wir Muro vorgestellt. Er lebt in Slack, kümmert sich um Dependency-Updates und übernimmt Aufgaben, für die sonst jemand ein Ticket erstellen, ein Repository öffnen und loslegen müsste.

Die interessantere Frage ist: Was passiert zwischen einem @muro in Slack und einem erledigten Task?

Denn ein LLM allein ist noch kein Agent. Du kannst Claude schreiben:

«Prüfe unsere offenen Dependency Updates und behebe sie.»

Claude findet das vermutlich eine gute Idee. Nur fehlen ihm Repository, Git-Zugriff, Shell, Credentials, Projektkontext und die Berechtigung, etwas zu verändern. Also bauen wir ihm einen Arbeitsplatz.

Vom @muro zum erledigten Task

Wir wollten für Muro kein neues Interface schaffen. Deshalb lebt er dort, wo wir unsere Arbeit sowieso koordinieren: in Slack.

«@muro kannst du dich um dieses Dependency-Update kümmern?»

Für die Person im Thread ist das eine Nachricht. Dahinter beginnt ein klarer Ablauf:

1. Identity: Unser Connector bindet die Slack-Identität der Person an die Anfrage. Ein Agent sollte nicht unabhängig davon handeln, wer ihm etwas aufträgt.
2. Session: Der Thread erhält eine isolierte OpenCode-Session. So bleibt der Kontext über mehrere Nachrichten und Arbeitsschritte erhalten.
3. Kontext: Muro liest die relevanten AGENTS.md-Informationen und lädt passende Skills.
4. Repository: Unsere Git-Integration bereitet den Code in einem eigenen Workspace vor.
5. Ausführung: Muro verändert Code, führt Checks aus und öffnet bei Bedarf einen Merge Request.
6. Resultat: Status und Ergebnis landen wieder im ursprünglichen Slack-Thread.

Slack Thread
     ↓
Connector + Identity
     ↓
OpenCode Session
     ↓
Context + Skills
     ↓
Git Proxy / Repository
     ↓
Code + Tests + Actions
     ↓
MR / Resultat
     ↓
Slack Thread

Der Slack-Thread ist damit Interface und Session-Grenze zugleich.

Der Arbeitsplatz ist ein Docker-Container

Muro läuft bei uns nicht auf irgendeinem Entwickler-Laptop. Er läuft in einem Docker-Container namens smartcode-assistant auf unserer eigenen Infrastruktur.

Darin laufen isolierte OpenCode-Sessions. Jeder Slack-Thread besitzt einen eigenen Arbeitskontext und einen eigenen Workspace. Tasks beeinflussen sich nicht gegenseitig, und wir bestimmen genau, was in der Linux-Umgebung verfügbar ist.

Es ist der Arbeitsplatz eines Entwicklers. Nur kontrolliert und wegwerfbar.

Git Credentials dürfen nicht herumliegen

Einer der unangenehmeren Teile beim Bau war Git Authentication. Muro soll Repositories lesen und Branches pushen können. Langlebige Git-Tokens im Container wären dafür eine ziemlich schlechte Ausgangslage.

Unsere Lösung ist deshalb ein Integrations-Git-Proxy. Der Agent interagiert mit Git über diesen Proxy. Credentials werden dynamisch an die jeweilige Identität und Aktion gebunden und müssen nicht dauerhaft im Container oder auf Disk liegen.

Das war deutlich mehr Arbeit als:

«Gib Claude halt einen Git Token.»

Aber genau solche Details unterscheiden eine Demo von einem Agenten, den wir tatsächlich arbeiten lassen.

Tools machen aus dem Modell einen Mitarbeiter

Muro kann Repositories lesen, Code pushen, Shell Commands ausführen, Tests starten, Slack-Threads beantworten und je nach Aufgabe mit Jira, Notion, DatoCMS oder Deployments arbeiten.

Das klingt nach einer Feature-Liste. Technisch ist es die wichtigste Sicherheitsfrage des ganzen Systems: Tool Access ist die eigentliche Macht eines Agents. Das Modell kann überlegen. Die Tools bestimmen, was daraus tatsächlich passiert.

Ein Coding Agent braucht die Shell nicht nur, um Code zu schreiben. Er muss auch Builds, Linter und Tests ausführen können. Sonst produziert er Änderungen, kann aber nicht feststellen, ob sie funktionieren.

Nicht jeder Agent braucht jedes Tool

Wir geben deshalb nicht jedem Agenten Zugriff auf alle Systeme. Ein Coding Task braucht Git und Shell. Ein Support Task vielleicht Jira, Notion und Logs. Je kleiner die Werkzeugkiste, desto klarer der Kontext und desto kleiner die Angriffsfläche.

Dasselbe Prinzip wie bei Software Permissions generell: Least Privilege. Nur jetzt für Agents.

Skills machen aus Tools Arbeitsabläufe

Dass ein Agent Git verwenden kann, bedeutet noch nicht, dass er weiss, wie wir Git verwenden. Genau dafür haben wir Skills. Sie verbinden Fähigkeiten mit unseren Abläufen.

Das Tool sagt: «Ich kann Git bedienen.» Der Skill sagt: «So bereitest du bei smartive ein Repository vor, erstellst einen Branch und öffnest einen Merge Request.»

Daneben gibt es agentenweite Regeln und projektspezifischen Kontext in Dateien wie AGENTS.md. Diese Trennung verhindert einen gigantischen Master-Prompt, in dem Dependency Management, CMS-Regeln und die halbe Firmengeschichte gleichzeitig stehen.

Autonomie ist kein Boolean

Einer der schwierigsten Teile beim Bau war nicht das Modell. Es war die Frage: Was darf der Agent einfach tun?

Muro darf Code verändern, Branches pushen, Merge Requests erstellen, Checks ausführen und je nach Aufgabe externe Systeme verändern.

Aber: Er darf niemals selbstständig einen Merge Request mergen oder direkt auf geschützte Branches wie main pushen. Dasselbe gilt für finale Production Approvals.

Warum wir den Merge beim Menschen lassen

Bis zum Merge kann Muro fast die ganze Arbeit übernehmen: Problem analysieren, Lösung bauen, Tests ausführen und die Änderung überprüfbar bereitstellen. Danach greifen Mechanismen, die wir bereits haben: CI, Code Review und Approval.

Ein Merge Request ist der etablierte Übergabepunkt zwischen «Jemand hat etwas gebaut» und «Wir akzeptieren diese Änderung». Ob dieses Jemand ein Mensch oder ein Agent war, ist für den Prozess zweitrangig.

Human-in-the-Loop ist deshalb kein Rückschritt. Ein Agent kann 90 Prozent einer Aufgabe übernehmen und vor der irreversiblen Aktion stoppen. Wie weit er gehen darf, hängt vom Risiko ab. Ein Slack-Reminder ist keine Datenbankmigration in Production.

Wir bauen nicht einen grossen Agenten

Muro ist nicht interessant, weil irgendwo ein riesiger Prompt sitzt, der alles kann. Seine Fähigkeiten sind modular: Interface, Session, Modell, Tools, Skills, Permissions und Execution Environment.

Je nach Use Case kombinieren wir daraus andere Agents mit anderen Werkzeugen und Autonomiegrenzen. Der Agent wird zur konfigurierten Arbeitsumgebung statt zur allwissenden AI-Persönlichkeit.

Und dann stösst du auf das nächste Problem

Irgendwann kann dein Agent ein Repository auschecken, Code verändern, Tests ausführen und Merge Requests öffnen. Dann sollte alles super sein.

Ist es natürlich nicht.

Denn im echten Softwareprojekt findet er implizite Architekturregeln, drei Patterns für dasselbe Problem, veraltete Dokumentation, toten Code und globale CSS-Regeln aus dem Jahr 2019.

Und plötzlich wird nicht mehr der Agent zum grössten Problem. Sondern das Repository.

Genau darum geht es in Teil 3 dieser Serie: Wie wir Repositories für autonome Agents bauen.

Denn unsere aktuelle Erkenntnis ist: Einen Agenten autonom zu machen ist nur die halbe Arbeit. Die andere Hälfte ist eine Umgebung, in der er zuverlässig arbeiten kann.