TL;DR: Routing bedeutet zu entscheiden, welcher Coding-Agent eine bestimmte Aufgabe übernimmt. Route anhand der Eigenschaften der Aufgabe, nicht anhand der Bestenliste von letzter Woche: was sie ändert, wie umkehrbar sie ist, ob sie Dateien berührt, die ein anderer Agent gerade bearbeitet, wie lange sie unbeaufsichtigt läuft und welches Abo sie abdeckt. Ordne diese Eigenschaften dem Agenten zu, dessen Verhalten in deiner Codebasis dazu passt. Mit ein oder zwei Agenten funktioniert das noch im Kopf. Ab drei braucht die Routing-Entscheidung einen gemeinsamen Ort, an dem sie leben kann. Dieser Leitfaden liefert dir die Regeln und eine Checkliste.
Du hast Claude Code in einem Terminal, Codex in einem anderen, vielleicht Gemini CLI in einem dritten. Eine Aufgabe kommt rein: einen flaky Test reparieren, einen Endpoint hinzufügen, ein Modul refactoren, das drei andere Dateien importieren. Welcher Agent bekommt sie? Die meisten von uns antworten aus Gewohnheit oder nehmen einfach das Fenster, das gerade im Fokus ist. Das funktioniert so lange, bis du dich nicht mehr erinnern kannst, welchem Agenten du die Migration übergeben hast – oder bis zwei von ihnen dieselbe Datei bearbeiten.
Den „besten“ Agenten auszuwählen ist eine einmalige Entscheidung, die am Tag veraltet, an dem ein neues Modell erscheint. Zu entscheiden, welcher Agent diese Aufgabe bekommt, ist eine Entscheidung, die du dutzende Male pro Woche triffst – und sie hängt weit mehr von der Aufgabe ab als vom Ranking. Sobald du mehr als einen Agenten hast, fließt deine Zeit ins Routing.
Sharkly ist rund um diese Entscheidung gebaut. Sharkly ist eine All-in-One-Plattform zur Steuerung und Verwaltung von Agenten: Du verbindest deinen eigenen Computer, definierst einen Agenten einmal als Rolle, die an eine Runtime gebunden ist, und weist ihm eine Task zu. Sie steht über den Coding-Agenten, die du bereits nutzt, nicht neben ihnen. Dieser Artikel zeigt, wie du eine Aufgabe gut routest – zuerst als Regeln, die du von Hand anwendest, dann bis zu dem Punkt, an dem die Routing-Entscheidung einen gemeinsamen Ort braucht, an dem sie leben kann.
Routing ist eine Entscheidung, keine Vorliebe
Beginnen wir mit einer klaren Definition. Routing bedeutet, eine Aufgabe dem Agenten zuzuordnen, der sie ausführen soll. Es ist nicht dasselbe wie die Wahl deines Lieblingsagenten, und es ist nicht dasselbe wie die Wahl eines Modells. Welches Modell für welche Coding-Aufgabe ist eine separate, engere Frage, die eine Ebene tiefer liegt; hier entscheiden wir, welcher Agent (Claude Code, Codex, Gemini CLI, OpenCode und die übrigen) die Arbeit erhält.
Eine Aufgabe bringt Eigenschaften mit, die ihre Route festlegen, noch bevor es um Fähigkeiten geht:
- Was sie ändert. Ein Ein-Datei-Fix, ein querschnittliches Refactoring, ein Greenfield-Feature, Tests, Docs. Jedes hat einen anderen Blast Radius.
- Wie umkehrbar sie ist. Ein Tippfehler-Fix und eine Datenbankmigration erzeugen beide einen Diff. Nur eine davon ruiniert deinen Nachmittag, wenn der Agent es vermasselt.
- Dateiüberlappung. Berührt sie Dateien, die ein anderer Agent gerade bearbeitet?
- Autonomiehorizont. Ein schneller interaktiver Edit oder ein langer unbeaufsichtigter Lauf, der planen, ausführen und sich selbst überprüfen muss.
- Kostendeckel. Welches Abo oder API-Budget soll ihn tragen.
Lies eine Aufgabe durch diese fünf Eigenschaften, und die Route wählt sich meist von selbst. Der Fehler ist, direkt zu „Welcher Agent ist der beste“ zu springen – eine Frage ohne feste Antwort, die sich mit jedem Release eines Labs ändert.
Route nach Aufgabenform, bevor du nach Fähigkeit routest
Coding-Agenten unterscheiden sich tatsächlich. Der eine plant lange mehrstufige Aufgaben gut; ein anderer ist vielleicht schärfer bei chirurgischen Edits oder schneller in kurzen Schleifen. Aber die ehrliche Version ist: Sie unterscheiden sich in deiner Codebasis, und die einzige Möglichkeit, das herauszufinden, ist, ihnen bei der Arbeit daran zuzusehen. Benchmarks messen eine feste Problemmenge zu einem festen Zeitpunkt – weder dein Repository noch der nächste Monat. Vergleiche Agenten in deiner eigenen Codebasis, bevor du einem Ranking vertraust.
Route also zuerst nach Form. Ein Entscheidungspaar als Anker: Nutze einen schnellen, interaktiven Agenten, wenn die Aufgabe klein und gut abgegrenzt ist und du zuschaust; greife zum autonomeren Agenten, wenn die Aufgabe groß genug ist, dass du sie lieber einmal beschreibst und das Ergebnis reviewst, als jeden Schritt zu babysitten.
| Aufgabenform | Route zu | Warum |
|---|---|---|
| Klein, gut abgegrenzt, du schaust zu | Dein schnellster interaktiver Agent | Geringer Overhead, enge Schleife |
| Groß, mehrstufig, einmal beschreiben | Dein zuverlässigster autonomer Agent | Er plant und prüft sich selbst unbeaufsichtigt |
| Berührt Dateien, die ein anderer Agent offen hat | Jeder Agent, in einem isolierten Worktree | Vermeidet die Merge-Kollision |
| Hochriskant oder irreversibel | Der Agent, dessen Output du genau reviewst, enge Berechtigungen | Der Blast Radius dominiert, nicht die Geschwindigkeit |
| Günstig und repetitiv | Was auch immer dein Budget bevorzugt | Der Kostendeckel entscheidet |
Nichts davon nennt einen Sieger, denn es gibt keinen. Es gibt eine Passung zwischen einer Aufgabe und dem beobachteten Verhalten eines Agenten – und nach dieser Passung routest du.
Die Constraints, die das Routing vor der Fähigkeit entscheiden
Zwei Constraints übertrumpfen jedes Mal die Fähigkeit, und beide drehen sich um Koordination, nicht um Können.
Der erste ist die Dateiüberlappung. Fünf Agenten, die an einem Repository arbeiten, klingt effizient – bis zwei dieselben Dateien berühren und du einen Merge-Konflikt auflöst, den du absichtlich erzeugt hast. Die Lösung ist Isolation: Gib jeder Aufgabe ihr eigenes Checkout, damit Agenten nicht kollidieren. Coding-Agent-Worktrees, ein Checkout pro Aufgabe erklärt den Mechanismus, und mehrere Agenten in einem Repository ausführen erklärt, was ohne ihn kaputtgeht. Wenn zwei Aufgaben dieselben Dateien berühren würden, ist die Route nicht „der bessere Agent“, sondern „irgendein Agent, in einem separaten Worktree“.
Der zweite ist Risiko. Eine Aufgabe, die Daten migriert, die Auth ändert oder einen Hot Path umschreibt, sollte dorthin geroutet werden, wo dein Review am engsten und die Berechtigungen des Agenten am schmalsten sind – unabhängig davon, welcher Agent technisch am stärksten ist. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und akzeptieren das Ergebnis. Eine riskante Aufgabe zum schnellsten Agenten zu routen, optimiert die falsche Variable.
Wo Routing im Kopf nicht mehr skaliert
Mit einem Agenten gibt es kein Routing-Problem. Mit zwei hältst du die Tabelle im Kopf, und das ist in Ordnung. Der Ärger beginnt bei etwa drei Agenten und mehreren offenen Tasks: Die Routing-Entscheidung hat keinen Ort, an dem sie leben kann, außer deinem Kurzzeitgedächtnis.
Du kannst dich nicht erinnern, welcher Agent die Migration bekam. Ein abgeschlossener Lauf scrollt oben aus dem Terminal heraus, bevor du ihn gelesen hast. Du entscheidest dieselbe Route dreimal neu, weil es keine Aufzeichnung gibt, dass du sie einmal entschieden hast. Zwei Agenten bearbeiten dieselbe Datei, weil keinem gesagt wurde, dass der andere da war. Nichts davon sind Agenten-Fehler. Es ist der Preis dafür, eine Routing-Tabelle im Kopf zu behalten, während die Terminals zunehmen. Zu viele Terminals sind echte Kosten, und beim Routing zeigen sie sich zuerst.
Hier verdient sich ein Task-Board seinen Platz, denn es holt die Routing-Entscheidung aus deinem Kopf in eine gemeinsame Aufzeichnung. Sharkly macht das mit drei Begriffen. Eine Task ist die gemeinsame Arbeitseinheit. Ein Agent ist eine Rolle, die an eine Runtime gebunden ist und einmal definiert wird, damit die Routing-Entscheidung wiederverwendbar wird, statt in jedem Terminal neu getroffen zu werden. Du weist einem Agenten eine Task zu, und Ausführung, Blocker und Ergebnisse kehren zu dieser Task zurück, statt wegzuscrollen. Du siehst, welcher Agent woran arbeitet, ohne Fenster zu wechseln, und der Diff und die Testausgabe warten an einem Ort auf dein Review. Agentenarbeit zuweisen, tracken und reviewen ist das, was dieses Gedächtnisspiel ersetzt.
Du brauchst nichts davon, um einen Agenten gut zu betreiben. Du kannst Claude Code und Codex auch von Hand zusammen in einer Codebasis ausführen, und für zwei Agenten ist das vernünftig. Die Gleichung ändert sich, wenn Routing-Entscheidungen das übersteigen, was du im Kopf behalten kannst: mehrere Agenten, mehrere Tasks, mehrere Repositories, ein Team, das dasselbe Board sehen muss.
Eine Routing-Checkliste, die du heute durchgehen kannst
Bevor du einem Agenten eine Aufgabe übergibst, lass sie durch diese Punkte laufen:
- Benenne die Form der Aufgabe. Ein-Datei-Fix, Refactoring, Greenfield, Tests oder Docs? Das legt den Blast Radius fest.
- Prüfe die Umkehrbarkeit. Schwer rückgängig zu machen? Route zu deinem engsten Review und den schmalsten Berechtigungen, nicht zu deinem schnellsten Agenten.
- Prüfe die Dateiüberlappung. Ist ein anderer Agent schon in diesen Dateien? Wenn ja, isoliere diese Aufgabe zuerst in ihrem eigenen Worktree.
- Passe den Autonomiehorizont an. Kurz und beobachtet oder lang und unbeaufsichtigt? Route zu dem Agenten, dessen Verhalten in deinem Repo passt.
- Setze den Kostendeckel. Entscheide, welches Abo oder Budget den Lauf trägt.
- Halte die Route an einem gemeinsamen Ort fest. Ab zwei Agenten schreib sie dorthin, wo du und dein Team sie sehen können: in eine Task, nicht in ein Terminal, das du schließen wirst.
- Schicke Ergebnisse an einen Ort zurück. Diff, Testausgabe und Review sollten zur Task-Aufzeichnung zurückkehren und sich nicht über Fenster verteilen.
Route nach der Aufgabe, nicht nach dem Ranking. Der beste Agent für eine Aufgabe ist der, dessen Form zur Arbeit vor dir passt – und die Routing-Entscheidung bleibt nur günstig, wenn sie an einem Ort lebt, den du sehen kannst.
Wenn du bereits mehrere Coding-Agenten betreibst, gibt dir Sharkly einen Ort, um ihre Tasks zu routen und ihre Ergebnisse zu lesen. Du kannst Sharkly herunterladen und die Agenten verbinden, die du nutzt.
FAQ
Ist Routing dasselbe wie den besten Coding-Agenten auszuwählen? Nein. Den besten Agenten auszuwählen ist ein einmaliges Urteil, das schnell veraltet. Routing bedeutet zu entscheiden, welcher Agent jede Aufgabe übernimmt – basierend auf ihrer Form, ihrem Risiko, ihrer Dateiüberlappung und ihrem Autonomiehorizont. Du routest dutzende Male für jedes eine Mal, in dem du auswählst.
Wie unterscheidet sich das von der Wahl eines Modells? Die Wahl eines Modells findet eine Ebene tiefer statt, innerhalb des Agenten. Routing entscheidet, welcher Agent die Aufgabe bekommt; die Modellfrage entscheidet, was in der Session dieses Agenten läuft. Siehe welches Modell für welche Coding-Aufgabe für die engere Entscheidung.
Wann brauche ich dafür tatsächlich ein Tool? Wenn Routing-Entscheidungen das übersteigen, was du im Kopf verfolgen kannst – meist bei etwa drei Agenten und mehreren offenen Tasks – oder wenn ein Team dieselben Entscheidungen sehen muss. Für ein oder zwei Agenten reichen eine mentale Tabelle und separate Terminals.
Ersetzt Sharkly Claude Code oder Codex? Nein. Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungstools. Es ergänzt die gemeinsame Task-, Computer-, Kontext- und Review-Ebene um die Coding-Agenten, die dein Team bereits nutzt.
