Arbeit aus Slack und Teams an einen Agenten übergeben

Ein Thread in #payments, am Vormittag. Jemand fragt @Archyl, was den Webhook-Sender aufruft, und der Bot antwortet: die Container Checkout und Billing, beide über die Payments API. Zwei Nachrichten später kommt der Satz, mit dem jeder dieser Threads endet: „Da sollten wir Retries einbauen, kann das jemand übernehmen?“

Dann wird es still im Thread. Jemand muss Archyl öffnen, das Projekt finden, ein Agentenprofil auswählen und eine Aufgabe neu abtippen, die schon dasteht, Wort für Wort, drei Nachrichten weiter oben.

Seit Juni beantwortet der Archyl-Bot Fragen in Slack und Microsoft Teams. Ab heute kann er auch handeln. Derselbe Thread kann die Arbeit an einen verwalteten Agenten übergeben:

@Archyl run [Payments API] add retries with backoff to the webhook sender

Der Agent läuft als die Person, die das geschrieben hat, und der Bot verfolgt den Run im Thread, bis es einen Pull Request gibt.

Ein Thread, von Anfang bis Ende

Hier ist der Rest dieses Austauschs. Die Nachrichten von Archyl sind die Formate, die der Bot tatsächlich postet. Die Namen, die Frage und der Pull Request sind Beispiele.

Marie:   @Archyl run [Payments API] add retries with backoff to the webhook sender

Archyl:  🚀 Agent `backend-fixer` started on Payments API. Follow it in Archyl
         — I'll post here when it needs you or when it's done.

„Follow it in Archyl“ verlinkt auf die Run-Seite, wo sich der Plan als Checkliste füllt und jeder Tool-Aufruf im Aktivitäts-Feed erscheint. Niemand muss sie offen halten.

Zwanzig Minuten später stößt der Agent auf eine Entscheidung, die er nicht allein treffen sollte:

Archyl:  @Marie ❓ The agent has a question:
         > Should retries also cover 4xx responses from receivers, or only
         > 5xx and timeouts?
         Answer in Archyl.

Marie klickt sich durch, wählt „only 5xx and timeouts“ aus den vorgeschlagenen Antworten und macht mit dem weiter, woran sie gerade war. Wenn der Run endet:

Archyl:  @Marie ✅ The agent finished and opened a pull request:
         https://github.com/acme/payments-api/pull/412
         See the run.

Wenn im Profil Plan zuerst prüfen eingeschaltet ist, gibt es vor jeder Codeänderung noch einen Halt: „📋 The agent proposed a plan and is waiting for your review“, mit einem Link. Wenn der Run fehlschlägt oder sein Zeit- oder Kostenlimit erreicht, sagt die letzte Nachricht, warum, und verlinkt den Draft-Pull-Request mit der bis dahin erledigten Arbeit.

In Slack @erwähnt jedes dieser Updates die Person, die den Run gestartet hat, damit es in ihren Benachrichtigungen landet. In Teams kommen die Updates als Antworten im selben Thread an, ohne Erwähnung.

Was zwischen diesen Nachrichten passiert ist

Der Thread zeigt drei Nachrichten. Der Run hat einiges mehr getan, und genau dieser Teil ist der Kern dieses Releases.

Bevor er eine Datei angefasst hat, hat der Run eine Arbeitssitzung auf den Architekturelementen geöffnet, die die Aufgabe berührt, hier die Webhook-Sender-Komponente in der Payments API. Er hat Leases darauf genommen, sodass ein Entwickler, der später Claude Code auf derselben Komponente startet, erfährt, dass dort schon jemand arbeitet. Sein Briefing enthielt die ADRs, Konformitätsregeln und API-Verträge, die an diesen Elementen hängen, dazu alles, was frühere Sitzungen sich darüber gemerkt haben. Jede Datei, die er geschrieben hat, ging durch den Guard, der einen Schreibvorgang ablehnt, wenn er eine kritische Konformitätsregel verletzt. Als er fertig war, wurde seine Zusammenfassung zu Memory auf den Elementen, zu denen die geänderten Dateien tatsächlich gehören, und jede Entscheidung, die er festgehalten hat, hat einen Architecture Change Request als Draft geöffnet, den jemand prüfen kann.

Nichts davon ist spezifisch für den Chat. Das macht jeder Archyl-Run. Geändert hat sich, woher die Anfrage kommt.

Das ist die Wette hinter diesem Feature. Ein gehosteter Ort, an dem ein Agent laufen kann, wird zu etwas, das man aus einer Liste auswählt: Wie wir vor zwei Wochen festgestellt haben, bieten Anthropic, OpenAI und Cursor inzwischen jeweils einen an. Was eine Runtime nicht kennt, ist dein System: zu welchem Container der Webhook-Sender gehört, wem er gehört, welche Regel sagt, dass ausgehendes HTTP über den gemeinsamen Client läuft, und welcher andere Agent gerade dort drin ist. Dieses Wissen steckt im Architekturmodell. Im Chat wird die Arbeit angefragt. Dieses Release verbindet beides, sodass eine Anfrage aus einem Thread mit dem Kontext ankommt, den ein Agent braucht, um sie gut zu erledigen.

Warum der Run als du angelegt wird

Wenn der Bot eine Frage beantwortet, nutzt er die Berechtigungen des Admins, der den Workspace verbunden hat. Zum Lesen funktioniert das. Jeder im Kanal bekommt dieselbe Sicht auf die Architektur, pro Kanal eingegrenzt, wenn du ihn beschränkt hast.

Handeln ist etwas anderes. Ein Run schreibt Code und öffnet einen Pull Request. Würde @Archyl run sich die Berechtigungen der Person leihen, die den Bot installiert hat, könnte jeder in einem Slack-Kanal einen Agenten ein Projekt ändern lassen, das er selbst nicht bearbeiten darf, und die Run-Historie würde bei jedem dieser Runs den Admin nennen.

Deshalb werden Runs als die Person angelegt, die den Befehl geschrieben hat, begrenzt durch deren Bearbeitungsrechte am Projekt. Der Bot kann nicht wissen, wer ein Chat-Nutzer in Archyl ist, bis dieser es ihm sagt. Das bedeutet einen Schritt pro Person, einmalig:

1. Geh in Archyl zu Profil → Chat-Konten und klicke auf Mein Slack-Konto verknüpfen oder Mein Microsoft Teams-Konto verknüpfen.
2. Sende den angezeigten Befehl, @Archyl connect <code>, irgendwo, wo der Bot auf dieser Plattform vertreten ist.

Der Code ist einmalig nutzbar und 15 Minuten gültig, und du hast ihn selbst erzeugt, während du angemeldet warst. Genau das beweist, dass das Chat-Konto dir gehört. Slack und Teams werden getrennt verknüpft. @Archyl disconnect entfernt die Verknüpfung; der Bot beantwortet weiter deine Fragen und startet keine Agenten mehr für dich.

Wenn du das überspringst und trotzdem run schreibst, sagt dir der Bot, was fehlt, statt zu raten:

I don't know who you are on Archyl yet, and agents run as the person who asks.
Generate a code in Profile → Chat accounts, then send @Archyl connect <code>.

Wie der Befehl gelesen wird

@Archyl run [Project name] <task>, mit zwei optionalen Teilen.

Das Projekt steht in eckigen Klammern. Vorerst sind die Klammern Pflicht, damit der Bot nie raten muss, wo dein Projektname endet und die Aufgabe beginnt. In einem Kanal, der auf ein einzelnes Projekt beschränkt ist, kannst du das Projekt weglassen: @Archyl run fix the flaky login test. Ein Kanal, der auf mehrere Projekte beschränkt ist, akzeptiert nur Projekte innerhalb seines Geltungsbereichs. Fragst du nach einem anderen, antwortet der Bot, dass er dieses Projekt im Geltungsbereich dieses Kanals nicht finden kann.

Das Profil steht vor der Aufgabe. Ohne Angabe nutzt der Run das Standardprofil deiner Organisation. Um ein anderes zu wählen, setze profile:<name> an den Anfang:

@Archyl run [Web] profile:frontend-fixer align the pricing cards

Ein Profilname, den es nicht gibt, bekommt eine Antwort mit der Liste der vorhandenen.

Alles andere verhält sich wie in der App. Du brauchst Bearbeitungsrechte für das Projekt. Der Run zählt zu den monatlichen Agent-Runs deiner Organisation, wie ein Run, der unter Agent Hub → Ausführungen gestartet wurde (und wie in der App werden Organisationen mit eigenem KI-Anbieter nicht gezählt). Wenn im Profil Arbeit anderer Agenten berücksichtigen aktiv ist und ein anderer Agent einen Lease auf dieselben Elemente hält, antwortet der Bot, dass das Preflight-Gate den Run abgelehnt hat. Gibt das Gate nur eine Warnung aus, wird der Run zur Freigabe zurückgehalten, und der Bot verlinkt dich dorthin.

Zwei kleine Dinge, bei denen wir aufgepasst haben

Nicht vertrauenswürdiger Text kann nicht den ganzen Raum anpingen. Die Aufgabe, der Projektname und die Fragen des Agenten landen alle zitiert wieder im Kanal. Jedes davon wird vor dem Posten für seine Plattform escaped, sodass eine Aufgabe oder Frage, die in Slack <!channel> oder in Teams eine <at>-Erwähnung enthält, als reiner Text ankommt, statt alle zu benachrichtigen.

Der Thread, an den ein Run berichtet, lässt sich von keinem Client ändern. In welchen Kanal und Thread ein Run postet, wird beim Anlegen des Runs auf dem Server gespeichert, nicht in den Metadaten des Runs, die API-Clients schreiben können. Updates gehen außerdem nur an einen Workspace, der mit der Organisation verbunden ist, der der Run gehört.

Was es noch nicht kann

Planprüfung und Antworten passieren in Archyl, nicht im Thread. Der Bot sagt dir, dass der Agent wartet, und verlinkt die Run-Seite. Du kannst einen Plan nicht aus Slack oder Teams freigeben und dort auch keine Frage beantworten. Das wiegt schwerer, als es klingt: Eine Frage, die niemand innerhalb einer Stunde beantwortet, lässt den Agenten nach eigenem Ermessen weitermachen, und ein Plan, den niemand innerhalb einer Stunde prüft, lässt den Run fehlschlagen. Die @Erwähnung ist dafür da, dass diese Stunde nicht unbemerkt vergeht.

Projektnamen müssen genau ein Projekt treffen. Es gibt kein Fuzzy Matching, und wenn zwei Projekte denselben Namen tragen, bittet dich der Bot, eines umzubenennen oder aus der App zu starten.

Teams-Updates erwähnen dich nicht. Es sind Antworten im Thread, wie sichtbar sie sind, hängt also davon ab, wie du diesem Thread folgst.

Ein Pull Request braucht einen unterstützten Host. Runs öffnen Pull Requests auf github.com, gitlab.com und bitbucket.org. Bitbucket kennt keine Draft-Pull-Requests, deshalb pusht ein Run, der dort fehlschlägt, seinen Branch, ohne einen zu öffnen. Ein Repository auf einem selbst gehosteten Git-Server bekommt keinen Pull Request; die letzte Nachricht sagt dann, dass der Agent fertig ist, und verlinkt den Run.

Ausprobieren

Runs aus dem Chat zu starten setzt verwaltete Agenten voraus, die in den Plänen Scale und Custom enthalten sind, sowie einen verbundenen Slack- oder Teams-Workspace. Verknüpfe dein Chat-Konto unter Profil → Chat-Konten, such dir dann einen Thread, in dem gerade jemand um etwas Kleines, klar Umrissenes gebeten hat, und schreib @Archyl run.

Die vollständige Referenz, auch dazu, wie Berechtigungen und Kanal-Geltungsbereiche greifen, steht in der Doku unter Agent-Runs aus Slack oder Teams starten.

Weiterlesen: der Launch des Slack- und Teams-Bots, den Bot pro Kanal beschränken, verwaltete Agenten unterstehen jetzt dem Harness und einen Run live verfolgen und steuern.