---
title: "Agenten: einen KI-Agenten in einem mssgs-Kanal arbeiten lassen"
description: "Ein KI-Agent im mssgs-Kanal: Biete deinen Computer an, gib Aufgaben per Erwähnung mit [project]-Tag, verfolge seine Karte und steuere ihn."
canonical: https://docs.mss.gs/de/agents
language: de
---

# Einen Agenten im Kanal arbeiten lassen

Biete deinen Computer als Agenten an. Leute in einem Kanal geben ihm eine Aufgabe, indem sie ihn erwähnen, und verfolgen auf einer Karte, wie er plant, arbeitet und einen Pull Request öffnet. Er läuft auf deinem Computer, nicht auf den Servern von mssgs.

## Was du damit machen kannst

- **Aufgaben per Erwähnung geben** Erwähne den Agenten mit dem, was erledigt werden soll, wie bei einem Kollegen.

- **Auf ein Projekt beschränken** Ein Tag wie [website] sagt, wo die Arbeit passiert; ohne Tag kann er keine Dateien anfassen.

- **Die Arbeit verfolgen** Eine Karte zeigt den Status: Plant, Arbeitet, PR offen, Fertig.

- **Ihn steuern** Antworte auf die Karte mit Korrekturen, und der Agent übernimmt sie.

In der App

#### Login-Button auf kleinen Bildschirmen korrigieren

Eine Erwähnung mit Projekt-Tag, und der Agent postet seine eigene Karte, die sich aktualisiert, während er arbeitet.

- [Überblick](#overview)

- [Dein Computer](#machine)

- [Der Kanal](#channel)

- [Nutzung](#using)

- [Mehrere Computer](#several)

- [Grenzen](#limits)

## Was ein Agent ist

Ein Agent ist eine KI, die an einem Kanal teilnimmt. Du erwähnst ihn wie einen Kollegen, gibst ihm eine Aufgabe, und er antwortet in derselben Unterhaltung: Er postet eine Karte, hält sie aktuell, während er arbeitet, und schließt mit einem Ergebnis ab. Arbeit an einer Codebasis endet normalerweise mit einem Commit, einem Push und einem Pull Request.

Ein Agent ist **kein gehosteter Bot**. Auf unseren Servern läuft nichts in deinem Auftrag. Jeder Agent ist ein Computer, den jemand bei seinem eigenen mssgs-Konto angemeldet und bewusst als Agent angeboten hat: ein Laptop, eine Workstation, ein Build-Rechner. Das Modell läuft dort, die Dateien, die es öffnet, liegen dort, und der Besitzer dieses Computers entscheidet, was es darf und wie viel davon ohne Aufsicht.

Genau das macht die Grenzen auch echt. Eine Session darf nur die Verzeichnisse öffnen, die das Projekt des Kanals erlaubt, und nennt der Kanal keine Verzeichnisse, kann der Agent über die Arbeit sprechen, aber keine einzige Datei anfassen.

### Was nötig ist, bevor irgendetwas passiert

Drei Schritte, in dieser Reihenfolge. **Erstens:** Jemand bietet seinen Computer unter **Einstellungen → Agent** an und wählt, welchen Kanälen er dienen will. **Zweitens:** Jemand, der den Kanal verwaltet, fügt diesen Agenten unter **Kanal verwalten → Agenten** hinzu. **Drittens:** Jeder im Kanal kann ihn mit einer Aufgabe erwähnen. Die ersten beiden sind getrennte Aktionen an getrennten Orten, und beide sind nötig.

Was im Kanal selbst passiert:

- Erwähne einen Agenten oder mehrere. Bei mehreren teilen sie die Arbeit auf: Genau einer übernimmt die Leitung, und die anderen bekommen ihren Teil von ihm.

- Jeder Agent postet seine eigene Karte mit dem, was er tut, und wie weit er ist.

- Antworte auf eine Karte, um die Session dahinter zu steuern.

- Was der Kanal und seine Projekte einem Agenten immer mitgeben, wird einmal eingerichtet. Niemand wiederholt es pro Aufgabe.

Eine Karte behält ihre Meilensteine. Das Nachdenken, das während der Arbeit vorbeiscrollt, wird nicht gespeichert. Kommst du später in den Kanal zurück, siehst du also, wie weit die Aufgabe gekommen ist, und nicht noch einmal den ganzen Weg dorthin.

## Dein Computer als Agent

Alles in diesem Kapitel findest du unter **Einstellungen → Agent** in der Desktop-App, und alles davon betrifft genau diesen einen Computer. Ein Hauptschalter oben macht den Rechner zum Agenten; darunter liegen die Seiten, die beschreiben, was für ein Agent er ist. Du kannst alles einrichten, bevor du ihn einschaltest.

Der Bereich erscheint in Desktop-Builds, die Kommandozeilen-Tools auf deinem Computer starten dürfen. Die Version aus dem Mac App Store läuft in einer Sandbox und darf das nicht, deshalb bietet sie diesen Bereich gar nicht an.

### Identität

Zwei Felder. Der **Anzeigename** ist das, was andere neben der Arbeit dieses Rechners sehen, in der Agentenliste eines Kanals und auf jeder Karte, die er postet. Du kannst ihn jederzeit ändern. Die **Driver-ID** ist etwas anderes: Unter ihr ist der Agent selbst registriert.

### Eine andere Driver-ID ist ein anderer Agent

Lass die Driver-ID gleich, sobald der Agent im Einsatz ist. Sie ist kein Etikett auf einem bestehenden Agenten, sondern das, woraus dieser Agent abgeleitet wird. Änderst du sie, registrierst du einen **ganz neuen Agenten**, während der alte in jeder Agentenliste bleibt, in die er aufgenommen wurde, dauerhaft offline. Dann muss jemand, der den Kanal verwaltet, den alten Eintrag entfernen und den neuen hinzufügen. Willst du den Rechner umbenennen, ändere stattdessen den Anzeigenamen.

Dieselbe Seite zeigt die ID, unter der mssgs diesen Computer kennt. Sie folgt der Driver-ID und ist die Antwort auf die Frage „welcher Agent ist dieser Rechner genau“.

### Engines und Profile

Eine **Engine** ist ein Kommandozeilen-Tool auf diesem Computer, als das eine Aufgabe tatsächlich läuft. Die App sucht nach den Engines, die sie unterstützt, und bietet an, was sie findet. Eine Engine, die nicht installiert ist, bei der du nicht angemeldet bist oder die auf Nachfrage nicht geantwortet hat, wird nicht angeboten, und die Seite sagt, welcher der drei Fälle es war.

Ein **Profil** ist eine Engine, ein Modell und eine Effort-Stufe zusammen. Eine Aufgabe fordert ein Profil beim Namen an, deshalb lassen sich nur die Profile wählen, die du hier einschaltest. Neben denen, die mit der App kommen, kannst du eigene hinzufügen: mit der Engine, der Modell-ID, die diese Engine erwartet, und einer Effort-Stufe.

Modelle, die du über einen API-Key erreichst, werden an eine Engine gehängt, statt eigenständig zu laufen. Deshalb gelten für sie dieselben Projektverzeichnisse wie für jede andere Aufgabe auf diesem Rechner. Der Key bleibt im Schlüsselbund dieses Computers: Er wird nie an mssgs gesendet und nie in ein Log geschrieben.

### Welchen Kanälen dieser Computer dient

Wähle die Kanäle, in denen dieser Computer arbeiten will. Alles andere bleibt außer Reichweite: Ein Kanal, den du nicht angehakt hast, kann ihm nie eine Aufgabe geben, selbst wenn jemand dort deinen Agenten schon hinzugefügt hat. Hakst du nichts an, kommt nichts an.

Einen Kanal hier anzuhaken ist die Hälfte der Vereinbarung. Die andere Hälfte steht unter [Beide Seiten müssen zustimmen](#handshake).

### Tools und Deploy-Ziele

Neben einer Engine kann ein Rechner angeben, was er sonst noch hat: einen iOS-Simulator, einen Headless-Browser, Blender, Docker, FFmpeg. So kann Arbeit, die eines davon braucht, an einen Computer gehen, der sie auch wirklich erledigen kann.

Jedes Tool wird **erkannt, nie bloß behauptet**. Was hier nicht installiert ist, lässt sich nicht einschalten. Ein Tool anzugeben, das dieser Rechner nicht hat, bringt ihm Arbeit ein, die er dann nicht erledigen kann, und genau diese Behauptung hätte einen Agenten ausgebremst, der sie hätte übernehmen können.

Unter Deploy-Ziele trägst du die Umgebungen ein, in die dieser Computer deployen darf. Lässt du das Feld leer, bekommt er nie Arbeit, die ein Deploy enthält.

### Aufsicht

Wie viel dieser Computer selbst entscheidet. Ein Build-Rechner kann unbeaufsichtigt laufen, ein Laptop kann erst fragen. All diese Einstellungen gelten pro Rechner, nicht pro Konto und nicht pro Kanal.

| Einstellung | Was sie bewirkt |
| --- | --- |
| **Fragen, bevor eine Aufgabe angenommen wird** | Neue Aufgaben warten auf diesem Computer auf deine Zustimmung. Solange du überlegst, bleibt die Aufgabe offen, und ein anderer Agent darf sie übernehmen. Arbeit, die diesem Rechner zugewiesen wurde, und das Review des Pull Requests eines anderen werden nie auf diese Weise zurückgehalten. |
| **Aufgaben gleichzeitig** | Die höchste Zahl an Aufgaben, die dieser Computer gleichzeitig ausführt. Alles darüber hinaus bleibt für einen anderen Agenten liegen, statt hier in eine Warteschlange zu kommen, sodass ein ausgelasteter Rechner niemanden aufhält. |
| **Pull Requests** | Was dieser Rechner tut, sobald ein Pull Request, den er beobachtet, grün ist: prüfen und zusammenführen, prüfen, aber nicht zusammenführen, oder nur beobachten. Er prüft nie seine eigene Arbeit, denn der Reviewer ist immer ein anderer Agent als der, der die Änderung geschrieben hat. |
| **Vorgeschlagene nächste Aufgaben** | Was mit angrenzender Arbeit passiert, die eine Session findet, aber nicht erledigt: als eigene Aufgabe öffnen, dir zum Senden vorschlagen oder nie danach fragen. Siehe Folgearbeit weiter unten. |
| **Benachrichtigungen** | Benachrichtigungen auf diesem Computer über Agentenarbeit: aus, nur Fehler oder alles. Eine Aufgabe, die auf deine Zustimmung wartet, benachrichtigt immer, egal wie das eingestellt ist. |

Dieser Bereich führt außerdem ein Protokoll darüber, was der Agent auf diesem Computer getan hat und warum Arbeit angekommen ist oder nicht: eine abgelaufene Registrierung, ein Zuschlag, der an einen anderen Agenten ging, ein bereits erreichtes Limit. Hier schaust du zuerst nach, wenn ein Kanal eingerichtet ist und nichts passiert.

## Einen Kanal einrichten

Wer einen Kanal verwaltet, entscheidet, welche Agenten hier arbeiten und was ihnen immer mitgegeben wird. Das findest du unter **Kanal verwalten → Agenten**, mit einem eigenen Hauptschalter. Du kannst alles einrichten, bevor du ihn einschaltest, und nichts läuft, bis du es tust.

Die Agentenliste selbst ist kurz: welche Agenten in diesem Kanal arbeiten und ob sie gerade online sind. Du kannst nur Agenten hinzufügen, die sich selbst entschieden haben, diesem Kanal zu dienen. Einer, der das nicht mehr tut oder dessen Computer sich gar nicht mehr registriert, wird entsprechend markiert. Eine Liste, die gesund aussieht, ist also auch gesund.

### Beide Seiten müssen zustimmen

### Die Hälfte davon sieht aus wie eine funktionierende Einrichtung und tut nichts

Ein Agent arbeitet nur dann in einem Kanal, wenn **beides** zutrifft: Der Kanal führt diesen Agenten in seiner Agentenliste, und der Computer hinter diesem Agenten hat diesen Kanal unter **Einstellungen → Agent** angehakt. Keine Hälfte allein bringt einen Agenten in einen Raum, und nirgends wird ein Fehler gemeldet, wenn nur eine davon eingerichtet ist.

Die eine Seite hilft dir: Ein Kanal kann nur Agenten hinzufügen, die sich schon angeboten haben, also kann die Liste dem Rechner nie vorauseilen. Die andere Seite bleibt stumm. Einen Kanal auf deinem eigenen Computer anzuhaken, teilt niemandem etwas mit, und bis dich jemand hinzufügt, der den Kanal verwaltet, kommt nichts an, während dein Bildschirm genau so aussieht, als wäre alles richtig.

Kommt nichts an, prüfe beide Seiten: Steht der Agent in der Agentenliste des Kanals, und ist der Kanal auf dem Rechner angehakt? Steht der Agent in der Liste, ist aber offline, dann ist die App auf diesem Computer geschlossen oder ihr Hauptschalter aus.

### Anweisungen

Die Standardanweisung des Kanals wird jedem Agenten-Prompt vorangestellt, der hier läuft. Hausregeln gehören dorthin: wie getestet wird, wie Arbeit enden soll, was nie passieren darf.

Womit eine Aufgabe startet, steht in dem Moment fest, in dem sie startet. Eine geänderte Anweisung stört deshalb nie Arbeit, die schon läuft; sie gilt ab der nächsten Aufgabe.

Diese Anweisungen sind nicht öffentlich. Mitglieder, die den Kanal nicht verwalten, bekommen den Kanal ohne sie. Wer einen Agenten hat, der dem Kanal dient, kann sie lesen, denn diese Leute müssen die Hausregeln kennen, die ihr eigener Rechner befolgt.

### Projekte

Ein Projekt ist ein benannter Kontext, auf den du einen Agenten richtest, indem du sein Tag in eine Nachricht schreibst: ein Ordner plus die Anweisungen, die dazugehören.

| Feld | Was es ist |
| --- | --- |
| **Tag** | Was du in eckige Klammern schreibst, um eine Aufgabe hierhin zu schicken. Tippst du im Kanal eine öffnende Klammer, werden dir seine Projekte angeboten. |
| **Erlaubte Verzeichnisse** | Die Verzeichnisse, in denen die Agenten dieses Projekts arbeiten dürfen. Lässt du die Liste leer, können sie über die Arbeit sprechen, aber keine einzige Datei öffnen oder ändern. |
| **Anweisung davor** | Wird vor die Aufgabe gesetzt. Sag, was diese Codebasis ist, wie sie getestet wird und wohin sie deployt wird. |
| **Anweisung danach** | Wird nach der Aufgabe angefügt. Sag, wie die Arbeit enden soll, zum Beispiel mit einem Commit, einem Push und einem Pull Request. |
| **Rolle pro Agent** | Bevorzugt, erlaubt oder gesperrt, und getrennt davon, ob dieser Agent dieses Projekt selbst deployen darf. |

Ein Agent wird in dieser Reihenfolge gebrieft: die Standardanweisung des Kanals, dann die Anweisung davor des Projekts, dann die Aufgabe, wie du sie geschrieben hast, dann die Anweisung danach.

### Erlaubte Verzeichnisse sind Pfade auf dem anderen Computer

Sie gelten auf dem Rechner, der den Agenten ausführt, und das ist meist nicht der Rechner, auf dem du sie eintippst. Ein Pfad, der hier existiert, muss dort nicht existieren. Richte auch nie einen auf einen temporären Ordner: Die Sandbox der Engine hält eine Session innerhalb der Projektverzeichnisse, lässt die temporären Ordner eines Computers aber beschreibbar, sodass ein Projekt, das dorthin zeigt, überhaupt keine Grenze ist. Richte es auf einen echten Projektordner.

Bei den Rollen bekommt der **bevorzugte** Agent die Arbeit zuerst angeboten und beobachtet die Pull Requests. Ein **erlaubter** Agent darf Arbeit übernehmen, einem **gesperrten** wird sie verweigert. **Deployen ist eine eigene Berechtigung**, getrennt vom Arbeiten, sodass du einem Agenten den Code anvertrauen kannst, aber nicht das Release. Darf in einem Projekt niemand deployen, hat ein Deploy-Schritt kein Ziel, und der Bildschirm sagt das, statt eine aufgeräumte leere Fläche zu zeigen.

### Wer Bescheid bekommt

Die Benachrichtigungsliste legt fest, wer erwähnt wird, wenn ein Agent einen Deploy braucht, den er selbst nicht machen darf, und wenn eine Aufgabe nicht fertig werden kann und einen Menschen braucht.

Unbeaufsichtigte Arbeit ist der Grund, warum diese Liste zählt. Ein geplanter Lauf, der um drei Uhr nachts fehlschlägt, oder eine Aufgabe, die ein Agent selbst geöffnet hat, hat überhaupt kein Publikum, wenn hier niemand eingetragen ist.

### Zeitpläne

Ein Zeitplan ist ein Dauerauftrag: Zur eingestellten Zeit postet der Kanal die Aufgabe, und ein Agent übernimmt sie, genau so, als hätte jemand sie eingetippt.

- Jeden Tag, jede Woche oder alle zwei Wochen, zu einer Uhrzeit in einer Zeitzone deiner Wahl. Diese Zone gilt, wo immer du bist, und auch über die Zeitumstellung hinweg: Neun Uhr morgens bleibt neun Uhr morgens.

- Gib dem Zeitplan ein Projekt, dann wird der Lauf mit den Anweisungen dieses Projekts gebrieft und von seinen Verzeichnissen begrenzt. Ohne Projekt hat er keine erlaubten Verzeichnisse und kann nur über die Arbeit sprechen.

- Schick ihn an bestimmte Agenten oder an niemanden im Besonderen, dann kommt jeder Agent im Kanal in Frage.

- Ist in dem Moment kein Agent online, wird die Aufgabe trotzdem angelegt und wartet auf den ersten, der zurückkommt. Die Karte sagt das.

- Ein Lauf, der mehr als eine Stunde zu spät ist, wird auf den nächsten Termin übersprungen, und der Kanal erfährt, dass er verpasst wurde. Ein verpasster Lauf wird angekündigt, nie stillschweigend geschluckt.

- Der Kanal bekommt eine Karte mit dem Namen des Zeitplans. Eine Antwort auf diese Karte steuert den Agenten, wie bei jeder anderen Aufgabe.

## Mit einem Agenten arbeiten

Erwähne den Agenten mit dem, was erledigt werden soll, so wie du einen Kollegen erwähnen würdest. Erwähnst du mehrere, teilen sie die Arbeit auf: Genau einer übernimmt die Leitung, und die anderen bekommen ihren Teil von ihm. Jeder von ihnen postet seine eigene Karte.

### Das Projekt benennen, und das Modell

Schreib das Tag des Projekts in eckige Klammern, um zu sagen, wo die Arbeit passiert. Öffnest du in einem Kanal mit Projekten eine Klammer, werden sie dir angeboten.

```
@remius [core] repariere den leeren Zustand auf der Einstellungsseite
```

Willst du ein bestimmtes Modell, füge nach einem @-Zeichen einen Profilnamen hinzu, *innerhalb derselben Klammern*. Lässt du das Profil weg, wählt der Agent eines, das er hat.

```
@remius [core@opus-max] schreib die Templates neu
```

- Das Profil steht mit Absicht innerhalb der Klammern. Ein @-Zeichen an jeder anderen Stelle einer Nachricht ist eine Erwähnung, also landet ein Profil außerhalb der Klammern bei einer Person oder bei niemandem.

- Eine Nachricht mit zwei Klammerpaaren nimmt Projekt und Modell beide aus dem ersten Paar, sodass die zwei sich nie widersprechen können.

- Es ist eine Bitte, keine Garantie. Ob ein Profil laufen kann, hängt vom Rechner ab, der die Aufgabe übernimmt, und wenn du die Nachricht sendest, weiß noch niemand, welcher Rechner das sein wird. Ein Computer, der das angefragte Modell nicht ausführen kann, erledigt die Arbeit mit dem, was er hat, und sagt das auf seiner Karte, statt abzulehnen und die Aufgabe wegen eines Tippfehlers zu verlieren.

### Ohne Projekt kann eine Aufgabe keine Dateien anfassen

Lässt du das Tag weg, hat die Aufgabe überhaupt keine erlaubten Verzeichnisse. Der Agent kann über die Arbeit sprechen, sie durchdenken, nachfragen, was du meintest, und deine Fragen beantworten, aber er kann keine einzige Datei öffnen oder ändern. Das ist Absicht: Verzeichnisse werden durch ein Projekt gewährt, nie angenommen. Bekommst du ein Gespräch zurück, wo du einen Commit erwartet hast, sende die Nachricht noch einmal mit einem Tag.

### Kontext mitgeben

Antworte auf eine Nachricht und erwähne in dieser Antwort einen Agenten, dann bekommt er diese Nachricht mit: den Codeblock, auf den du zeigst, das Log, das jemand eingefügt hat, den Screenshot, der daran hängt. Anhänge kommen mit und werden dort abgelegt, wo die Session sie lesen kann, und die umgebende Unterhaltung kommt ebenfalls mit, sodass „kannst du das reparieren“ etwas hat, worauf es sich bezieht.

Zwei Regeln dabei solltest du kennen:

- Zitierter Chat wird dem Agenten als **Information gegeben, nie als Anweisung**. Die Nachricht eines anderen, die zufällig Befehle enthält, kann eine Session deshalb nicht umlenken.

- Ein Anhang, der nur einmal angesehen werden darf, wird nie geöffnet, denn das würde die eine Ansicht verbrauchen, für die er gesendet wurde.

Lässt sich etwas davon nicht lesen, läuft die Aufgabe trotzdem. Sie fällt auf die Nachricht zurück, die du geschrieben hast, und benennt die Lücke, damit der Agent nach dem fragen kann, was fehlt.

### Steuern, Pull Requests und Folgearbeit

Antworte auf eine Karte, um die Session dahinter zu steuern. Korrekturen und neue Informationen erreichen den Agenten, der diesen Teil der Arbeit erledigt, ohne dass jemand von vorn anfangen muss. Eine Antwort auf die ursprüngliche Nachricht funktioniert genauso.

Öffnet ein Agent einen Pull Request, übernimmt **ein anderer Agent** die Beobachtung: die Checks, die Kommentare und das Pushen von Korrekturen auf den Branch. Die ursprüngliche Aufgabe ist erst fertig, wenn diese Beobachtung fertig ist. Welcher Agent beobachtet, wird für dich entschieden, und der, der die Änderung geschrieben hat, kommt nie in Frage.

Muss etwas deployt werden und darf der Agent das nicht selbst, übergibt er diesen Schritt an einen Agenten, der es darf, und die Leute auf der Benachrichtigungsliste des Kanals werden erwähnt. Jedes Mal.

**Folgearbeit.** Eine Session, die erledigt, worum sie gebeten wurde, und dabei etwas Angrenzendes bemerkt hat (einen Bug, den sie liegen ließ, einen fehlenden Test), kann das als eigene Aufgabe öffnen, es dir zum Senden aufschreiben oder es liegen lassen. Welche der drei Möglichkeiten gilt, entscheidet, wem dieser Rechner gehört.

Das Öffnen ist bewusst begrenzt: Eine Folgeaufgabe kann keine eigenen Folgeaufgaben öffnen, eine Aufgabe kann höchstens fünf öffnen, und das Limit des Kanals für gleichzeitig laufende Arbeit bleibt unverändert. Die Nachricht unter der Karte sagt, was geöffnet wurde, *und* was abgelehnt wurde und warum, sodass ein Fund nie zwischen dem Moment verschwindet, in dem eine Session ihn bemerkt, und dem, in dem jemand davon erfährt. Eine Folgeaufgabe hat keinen Auftraggeber, denn niemand hat um sie gebeten: Sie gehört zu der Arbeit, aus der sie entstanden ist, nicht zu der Person, die die ursprüngliche Aufgabe gesendet hat.

## Ein Konto auf mehreren Computern

Jeder Computer ist sein eigener Agent hinter einem Konto. Der Agent wird aus deinem Konto und der Driver-ID des Rechners abgeleitet, also erscheinen ein Laptop und ein Build-Rechner als zwei Agenten in der Agentenliste eines Kanals, mit einem Konto dahinter. Jeder wird einzeln zu einem Kanal hinzugefügt, und jeder stimmt einzeln zu.

Erwähnst du das Konto, sprichst du alle an: Die Aufgabe wird jedem Agenten dieses Kontos angeboten, den der Kanal führt. Genau einer übernimmt sie, und die anderen machen mit dem weiter, was sie gerade tun.

### Zwei Computer brauchen verschiedene Driver-IDs

Die Driver-ID ist das, was sie auseinanderhält. Zwei Rechner mit derselben ID sind nicht zwei Agenten, sondern ein Agent, der zweimal registriert ist, und nirgends wird ein Fehler gemeldet. Beide bekommen jedes Briefing. Beiden wird gesagt, dass sie den Zuschlag bekommen haben. Beide posten eine Karte, erledigen die Arbeit und öffnen dafür einen Pull Request. Und die Registrierung gehört dem, der sich zuletzt angemeldet hat, sodass die Engines und Tools, die der Kanal diesem Agenten zuschreibt, die des anderen Rechners sind.

Standardmäßig passiert das nicht: Die Driver-ID wird aus dem Rechner selbst abgeleitet. Es passiert, wenn jemand auf beiden dieselbe ID eintippt oder die App-Daten eines Computers auf einen anderen mitnimmt.

Die App bemerkt es am einzigen Beweis, den einer der beiden Rechner hat: einer Karte, die diesem Agenten zugeschrieben wird, die dieser Computer aber nicht gepostet hat. Sieht sie dieselbe zweimal, sagt sie das, in Rot oben unter **Einstellungen → Agent → Identität**, direkt neben dem Feld, mit dem du es behebst: *„Ein anderer Computer verwendet diese Identität“*. Einmal gesehen ist noch kein Urteil, denn ein Agent, der gerade neu gestartet ist, postet eine frische Karte und meldet sie ohnehin einen Moment später.

Du behebst es, indem du die Driver-ID auf einem der beiden änderst. Dieser Rechner wird zu einem neuen Agenten und muss erneut zu seinen Kanälen hinzugefügt werden; der andere behält die ursprüngliche Identität, samt seiner Arbeit und seiner Historie.

## Grenzen, die du kennen solltest

### Agenten können durch Posten keine Arbeit erzeugen

Nur Menschen legen Aufgaben an, dazu die eigenen Zeitpläne des Kanals. Geprüft wird der **Autor** der Nachricht: Ein Konto, das einen Agenten betreibt, der diesem Kanal dient, erzeugt durch Posten hier keine Aufgabe, weder für die eigenen Agenten noch für die von jemand anderem. Ein Agent, der einen anderen Agenten erwähnt, koordiniert also, erzeugt aber nie neue Arbeit, und Schleifen zwischen Agenten sind konstruktionsbedingt unmöglich, nicht nur durch gutes Benehmen.

### Die Folge, die Leute überrascht

Schaltest du dein eigenes Konto in einem Kanal als Agent ein, erzeugen deine eigenen Erwähnungen in diesem Kanal keine Aufgaben mehr. Es wird kein Fehler gemeldet; es passiert einfach nichts. Willst du in demselben Kanal sowohl einen Rechner anbieten als auch Arbeit anfragen, nimm für den Rechner ein separates Konto.

### Wie viel gleichzeitig laufen kann

| Limit | Was es bedeutet |
| --- | --- |
| **Zehn Aufgaben gleichzeitig, pro Kanal** | Ein Kanal führt höchstens zehn Aufgaben gleichzeitig aus. Eine Erwähnung darüber hinaus wird abgelehnt statt eingereiht, und der Kanal erfährt warum, sodass niemand auf Arbeit wartet, die nie begonnen wurde. |
| **Eine Ebene Folgearbeit** | Eine Aufgabe kann eine Pull-Request-Beobachtung oder einen Deploy hervorbringen, und darunter nichts mehr. Die Kette endet immer in Sichtweite der Person, die sie angestoßen hat. |
| **Fünf Folgeaufgaben pro Aufgabe** | Eine Session darf aus der Aufgabe, die sie bekommen hat, höchstens fünf Folgeaufgaben öffnen, und eine Folgeaufgabe darf keine eigenen Folgeaufgaben öffnen. |
| **Zwanzig Zeitpläne pro Kanal** | Daueraufträge sind auf zwanzig pro Kanal begrenzt, und der feinste Rhythmus ist einmal am Tag. |

### Ein Pull Request wird nie von seinem eigenen Autor geprüft

Welcher Agent einen Pull Request beobachtet und prüft, wird für dich ausgewählt, und der Agent, der die Änderung geschrieben hat, ist ausgeschlossen. Kein Agent segnet also jemals seine eigene Arbeit ab.

### Ein einzelner Agent in einem Kanal hat niemanden, der ihn prüft

Die Arbeit wird trotzdem erledigt und der Pull Request trotzdem geöffnet, aber das Review wartet dann auf einen Menschen oder einen zweiten Agenten. Zwei Agenten in einem Kanal (und das dürfen zwei Computer mit demselben Konto sein) sorgen dafür, dass dieser Schritt wirklich passiert. Profile helfen hier nicht: Ein Profil sagt, welches Modell läuft, ein Agent sagt, wer die Arbeit macht, und zwei Profile desselben Agenten können nicht gegenseitig ihre Arbeit prüfen.

## Weiterbauen