Niemand vertraut einem neuen Teammitglied wegen seines Lebenslaufs. Vertrauen entsteht durch Struktur: ein klar abgegrenzter Verantwortungsbereich, Arbeit, die dort stattfindet, wo das Team sie sehen kann, und ein Review, bevor irgendetwas ausgeliefert wird. Fällt einer dieser Punkte weg, wird selbst ein brillanter Kollege zum Risiko. Für KI-Agenten als Teammitglieder gilt dasselbe. Die Frage ist nie: „Ist das Modell klug genug?“ Sondern: „Weiß ich, worauf dieses Ding zugreifen darf, kann ich sehen, was es getan hat, und wird irgendetwas ausgeliefert, ohne dass ein Mensch Ja sagt?“
Sharkly beantwortet das mit Konfiguration statt mit Versprechen. Ein Agent in Sharkly ist eine gespeicherte Arbeitskonfiguration und kein einmaliger Prompt: Seine Anweisungen, Runtime, Skills, Repositories, Umgebung und Run-Einstellungen bestimmen, wie er Arbeit erledigt. Ein Prompt verschwindet, sobald das Terminal geschlossen wird. Eine Konfiguration ist überprüfbar, teilbar und bei jedem Run stabil.
Wenn du zuerst den Überblick über die Plattform möchtest, beginne mit was Sharkly ist und komm dann zurück.
TL;DR
Ein Agent in Sharkly ist eine gespeicherte, wiederverwendbare Arbeitskonfiguration für einen KI-Akteur: Betriebsanweisungen, eine Bindung an Computer und Runtime, zugewiesene Skills, Git-Repositories, Umgebungsvariablen und Run-Einstellungen wie Parallelität, Timeouts und Arbeitsverzeichnis-Modus. Man vertraut ihm so, wie man einem Teammitglied vertraut – durch Struktur statt durch Glauben: Sein Wirkungsbereich steht explizit in der Konfiguration, seine Ausführungszustände und sein Trace sind sichtbar, und seine Ergebnisse landen wieder im Task, wo ein Mensch sie prüft und abnimmt. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.
Was ein Agent ist (und was nicht)
Ein Agent ist ein KI-Akteur, der so konfiguriert ist, dass er Arbeit in Sharkly übernimmt. Er kann zugewiesene Tasks erhalten, Kommentare schreiben, den Task-Status über den verfügbaren Workflow aktualisieren und einen Ausführungs-Trace erzeugen. Weil die Konfiguration gespeichert wird, kann ein Team separate Agenten für Code-Änderungen, Review, Tests, Dokumentation oder operatives Triage pflegen, ohne dieselben Anweisungen für jeden Task neu zu schreiben.
Zwei Grenzen sind von Anfang an wichtig.
Ein Agent ist nicht der Ausführungs-Host. Seine Arbeit läuft über eine ausgewählte Runtime auf einem verbundenen Computer. Der Agent definiert, wie Arbeit erledigt werden soll; der Computer stellt den Host bereit; die Runtime führt die eigentliche Session aus; der Task bleibt der gemeinsame Datensatz. Jede Rolle hat genau eine Aufgabe – deshalb kann ein einzelner Computer mehrere Agenten bedienen.
Ein Agent wählt sein Modell nicht selbst. Er folgt dem Standardmodell der Runtime; am Agenten gibt es weder eine Modellauswahl noch eine Steuerung der Denktiefe. Um ein anderes Modell zu verwenden, ändere es in der Konfiguration des Runtime- oder Computer-Tools, zum Beispiel direkt in Claude Code oder Codex.
Vertrauen ist eine Eigenschaft des Systems, nicht des Modells
Das ist die These, auf der dieser Artikel aufbaut: Ein Agent ist vertrauenswürdig, wenn seine Arbeit klar abgegrenzt, sichtbar und überprüfbar ist. Nicht, wenn das Modell beeindruckend ist.
Abgegrenzt bedeutet, dass die Befugnisse des Agenten festgeschrieben sind, bevor er läuft: welche Repositories er anfassen darf, auf welchem Computer er ausgeführt wird, was seine Anweisungen erlauben, wie viele Tasks er gleichzeitig bearbeiten darf und wie lange ein Run dauern darf. Sichtbar bedeutet, dass Run-Zustände, Trace-Events und Ergebnisse zum Task zurückkehren, wo jeder sie einsehen kann, statt in einem privaten Terminal zu verschwinden. Überprüfbar bedeutet, dass am Ende des Kreislaufs ein Mensch sitzt: Ein Agent kann einen Task im Zustand „wartet auf menschliche Antwort“ oder „wartet auf menschliches Review“ belassen, und diese Signale landen in der Inbox der verantwortlichen Person.
Das ist der Mensch-Agent-Vertrag in der Praxis. Automatisierung endet dort, wo das Urteilsvermögen des Teams gefragt ist. Wenn du den Workflow selbst noch abwägst: Unser Grundlagenartikel zum agentischen Coding behandelt den Wandel vom Prompten hin zum Zuweisen von Arbeit.
Die Konfigurationsoberfläche eines Agenten
Ein Agent kann einen Namen, eine Beschreibung, einen Avatar und einen Owner enthalten; dazu Betriebsanweisungen, Sichtbarkeit und Space-Zuordnung, eine Computer-Verbindung und einen Runtime-Anbieter, zugewiesene Skills, Agent-spezifische Git-Repositories, einfache und geheime Umgebungsvariablen, zusätzliche Runtime-Argumente, Einstellungen für das Task-Arbeitsverzeichnis sowie ein Maximum für parallel laufende Tasks und einen Timeout pro Task. Jeder dieser Bausteine ist ein Hebel für Vertrauen.
Anweisungen werden in jeden Run übernommen. Nutze sie für Verhalten, das bei jedem Task gelten soll: Wirkungsbereich und Rolle, wie ein Task vor dem Handeln geprüft wird, wann menschlicher Input gefragt ist, erwartete Checks und das Berichtsformat. Die Docs ziehen eine hilfreiche Dreiteilung: Taskspezifische Anforderungen gehören in die Task-Beschreibung oder in Kommentare, eine wiederverwendbare Vorgehensweise, die mehrere Agenten teilen können, gehört in einen Skill, und die eigenen Anweisungen des Agenten tragen seine stabile Identität. „Lies die Task-Beschreibung und die aktuellen Kommentare, bevor du etwas bearbeitest. Halte Änderungen auf das angeforderte Verhalten begrenzt. Führe die nächstliegenden relevanten Checks aus und melde Fehler, ohne sie zu verbergen“ gehört zum Agenten, weil es am Montag gelten soll und im März immer noch. Die Beschreibung hat einen anderen Leser: Sie sagt Menschen, was sie zuweisen können, während die Anweisungen dem Agenten sagen, wie er arbeiten soll.
Sichtbarkeit ist entweder „Personal“ – nur für den aktuellen Owner verfügbar – oder „Space“ – verfügbar für Personen, die auf den Space des Agenten zugreifen können. Sie steuert außerdem, wer den Agenten zuweisen, mit ihm einen Agent Chat starten oder ihn per Kommentar oder Mention auslösen darf. Beginne mit „Personal“, solange du noch feinjustierst; wechsle zu „Space“, sobald die Konfiguration teilenswert ist. Diese Beförderung ist der Moment, in dem die Arbeitsweise eines Entwicklers zur Team-Infrastruktur wird.
Computer und Runtime bilden zusammen das Ausführungsziel. Dass ein Computer online ist, bedeutet nur, dass sein lokaler Dienst Heartbeats sendet; es heißt nicht, dass die ausgewählte Runtime einen Task ausführen kann. Ist der Computer offline, warten neue Runs normalerweise, bis er sich wieder verbindet; fehlt die ausgewählte Runtime, wähle eine andere infrage kommende. Die komplette Einrichtung findest du in Computer in Sharkly.
Skills bündeln wiederverwendbare Anweisungen und begleitende Dateien: Review-Regeln, Liefer-Checklisten, einen Teamprozess. Lokale Runtime-Skills bleiben auf diesem Computer automatisch verfügbar; geteilte Space-Skills müssen explizit zugewiesen werden. Eine Warnung, die man ruhig wiederholen kann: Binde nicht viele sich überschneidende Skills, denn widersprüchliche Anweisungen machen die Ausführung schwerer vorhersehbar. Mehr dazu im Deep Dive zu Skills in Sharkly.
Repositories sind der sauberste Hebel zur Abgrenzung, den du hast. Binde sie an den Agenten, wenn er einen engeren Code-Umfang braucht als der Space-Standard; ohne Bindungen greift Sharkly auf die Repositories zurück, die für den Space des Tasks konfiguriert sind. Ein Dokumentations-Agent, der an das Docs-Repository gebunden ist, hat keinen Weg zu deinem Zahlungsdienst.
Umgebung und Run-Einstellungen begrenzen, was ein Run verbrauchen kann. Einfache und geheime Umgebungsvariablen sowie zusätzliche Runtime-Argumente erlauben es einem Run, Konfiguration mitzuführen, ohne dass jemand Zugangsdaten in einen Task einfügt. Lege niemals Repository-Tokens, private Schlüssel oder Install-Tokens in einer Task-Beschreibung, einem Kommentar, einer Agent-Anweisung oder einem Skill ab. Die Task-Run-Einstellungen steuern parallele Tasks, die maximale Run-Dauer und den Arbeitsverzeichnis-Modus:
| Temporärer Modus | Festgelegter Modus | |
|---|---|---|
| Was ein Run erhält | Ein isoliertes Verzeichnis pro Task; repository-gestützte Runs können einen frischen Worktree vorbereiten | Ein konfiguriertes absolutes lokales Verzeichnis aus dem Verzeichnis-Pool des Agenten |
| Parallelität | Sicherere parallele Ausführung; Standard ist 50 % des Computer-Limits | Ein Run pro Verzeichnis gleichzeitig; Standard entspricht der Anzahl der Verzeichnisse |
| Verfügbarkeit | Jeder verbundene Computer | Nur lokale Computer |
| Am besten geeignet für | Die meisten Repository-Arbeiten und immer dann, wenn mehrere Tasks dieselbe Codebasis parallel verändern könnten | Sehr große Repositories, teure lokale Caches oder Tasks, die an lokale Dienste gebunden sind |
Setzt du einen manuellen Parallelitätswert höher als die Anzahl der Verzeichnisse, warnt das Produkt, dass Schreibvorgänge kollidieren können. Die Isolationsmechanik behandelt der Artikel wie Sharkly Agenten parallel ohne Merge-Konflikte ausführt.
Unterhaltungen vs. Tasks: zwei Oberflächen, eine Regel
Der Agent Chat ist eine eigenständige Unterhaltung, um eine Frage zu stellen, ein Thema zu untersuchen oder einen Plan zu formen, bevor irgendetwas einen getrackten Task braucht. Der Chat unterstützt drei Modi: Explore für reine Lese-Recherche, Plan für Vorschläge, die du prüfst und bestätigst, bevor Sharkly den geplanten Task und seine Subtasks anlegt, und Execute für direktes Handeln über die konfigurierte CLI des Agenten. Jede Session gehört der Person, die sie erstellt hat.
Ein Task ist der Ort, an den Arbeit gehört, wenn sie Ownership, Status, Ausführungshistorie oder Review braucht. Das Entscheidungspaar: Nutze den Chat zum Erkunden, Planen oder Handeln, bevor die Arbeit einen getrackten Task braucht; nutze den Task, wenn die Arbeit einen Assignee, einen Status, Abnahmekriterien oder eine dauerhafte Aufzeichnung braucht.
Eine Grenze verhindert, dass Teams den Kontext verlieren. Eine Nachricht im Agent Chat erzeugt keinen Task-Kommentar, und Nachrichten im Agent-Chat eines Tasks erscheinen nicht als Kommentare in der Activity. Wenn das Team eine Schlussfolgerung sehen soll, kopiere sie in die Task-Beschreibung oder in einen Kommentar. Vertrauen hängt am gemeinsamen Datensatz – und der gemeinsame Datensatz ist der Task.
Was dir die Statuszustände verraten
Sichtbarkeit bedeutet hier eine konkrete Menge von Zuständen, die du ablesen kannst – kein Dashboard-Slogan.
Ein Task-Run durchläuft die Zustände in der Warteschlange, an die Ausführung übergeben, wartet auf lokales Verzeichnis, läuft, abgeschlossen, fehlgeschlagen und abgebrochen. Run-Zustände sind vom Workflow-Status des Tasks getrennt: Ein Run kann fehlschlagen, während der Task für einen weiteren Versuch offen bleibt. Das Ausführungsprotokoll hält fest, warum ein Run in die Warteschlange kam, wann er gestartet und beendet wurde, welche Tool-Calls und Runtime-Events auftraten, woher der Auslöser kam und welche Fehlerdetails es gab.
Die Verfügbarkeit des Agenten ist ein drittes, eigenes Signal. Ein Agent, der online ist, kann trotzdem Arbeiten in der Warteschlange haben, weil Parallelität oder Verzeichniskapazität ausgeschöpft sind. Und das Backlog fungiert als Parkplatz: Ein einem Agenten zugewiesener Task wartet, solange er im Backlog liegt, und erst das Verschieben in einen Status, der für Arbeit bereit ist, startet den Run. Das Zuweisen eines Agenten löst nie überraschend Arbeit aus.
Dein erster Agent: ein Durchlauf, dem du vertrauen kannst
Der schnellste Weg, Vertrauen aufzubauen, ist der kleinste sinnvolle Kreislauf aus den Sharkly Docs: einen Computer verbinden, einen Agenten anlegen und einen risikoarmen Task zuweisen.
- Verbinde einen Computer. Öffne die Einstellungen, dann Computer, und wähle „Computer verbinden“. Warte, bis er als verbunden mit mindestens einer verfügbaren Runtime angezeigt wird.
- Lege den Agenten mit einer engen Rolle an. Name: Code Reader. Beschreibung: liest ein Repository, erklärt die aktuelle Implementierung und meldet Risiken, ohne Dateien zu ändern. Sichtbarkeit: Personal.
- Schreibe Anweisungen, die den Wirkungsbereich durchsetzen: „Lies den vollständigen Task und die relevanten Kommentare, bevor du handelst. Bleib im Rahmen der Anfrage. Bearbeite beim ersten Task keine Dateien. Berichte, was du geprüft hast, die Belege für jede Schlussfolgerung und alles, was ungewiss bleibt.“
- Binde den Code. Hänge ein Git-Repository an oder konfiguriere ein festgelegtes lokales Verzeichnis, das es bereits enthält. Skills können warten.
- Erstelle einen kleinen, rein textlichen Task: Prüfe den Fehlerpfad der Authentifizierung, identifiziere drei für Nutzer sichtbare Fehlerfälle, nenne für jeden die relevante Datei und ändere nichts.
- Weise zu und starte – über einen Status, der für Arbeit bereit ist, nicht über das Backlog. Beobachte, wie der Run-Zustand von „in der Warteschlange“ auf „läuft“ wechselt, und lies dann das Ergebnis im Task.
- Prüfe es richtig. Kontrolliere, dass der Agent den beabsichtigten Code untersucht hat, innerhalb der Nicht-Bearbeiten-Grenze geblieben ist, Belege geliefert und Unsicherheiten festgehalten hat, statt zu raten.
Genau dieser letzte Schritt ist der Punkt. Ein erster Task im Nur-Lesen-Modus lässt den Agenten sich Befugnisse verdienen, bevor er welche besitzt. Wenn der Kreislauf funktioniert, erweitere den Umfang bewusst. Die vollständige Mechanik der Zuweisung findest du in wie du deinen ersten Task an einen KI-Coding-Agenten zuweist.
Und wenn ein Agent dieses Vertrauen nicht mehr verdient, ist der Entzug sauber. Archivieren entfernt ihn aus Zuweisungen und Mentions und bricht seine laufenden Arbeiten ab, während seine früheren Tasks, Kommentare und die Run-Historie verfügbar bleiben. Ein Teammitglied, das man offboarden kann, ohne die Aufzeichnung seiner Arbeit zu verlieren, ist ein Teammitglied, dessen Onboarding man sich leisten kann.
FAQ
Was genau ist ein Agent in Sharkly?
Ein Agent ist ein KI-Akteur, der so konfiguriert ist, dass er Arbeit in Sharkly übernimmt: eine gespeicherte Konfiguration aus Anweisungen, einer Bindung an Computer und Runtime, Skills, Repositories, Umgebungsvariablen und Run-Einstellungen. Er kann zugewiesene Tasks erhalten, Kommentare schreiben, den Task-Status aktualisieren und einen Ausführungs-Trace erzeugen. Weil die Konfiguration gespeichert ist, wird die Arbeitsweise einer Person wiederverwendbar, sobald der Agent in einen Space geteilt wird.
Welches Modell verwendet ein Sharkly-Agent?
Der Agent folgt dem Standardmodell seiner ausgewählten Runtime, etwa Claude Code oder Codex, und zeigt oder verspricht keinen bestimmten Modellnamen. Am Agenten gibt es weder eine Modellauswahl noch eine Steuerung der Denktiefe. Um das Modell zu wechseln, aktualisiere die Konfiguration des Runtime- oder Computer-Tools.
Was ist der Unterschied zwischen dem Chatten mit einem Agenten und dem Zuweisen eines Tasks?
Der Agent Chat ist eine eigenständige Unterhaltung zum Erkunden, Planen oder Handeln, bevor die Arbeit eine getrackte Aufzeichnung braucht. Ein Task ist die gemeinsame Arbeitseinheit – mit Assignee, Status, Ausführungshistorie und Review. Chat-Nachrichten werden nicht zu Task-Kommentaren; team-sichtbare Schlussfolgerungen gehören daher in den Task.
Wie begrenze ich, was ein Agent tun kann?
Der Wirkungsbereich wird in der Konfiguration festgelegt: Anweisungen definieren Rolle und Vorsichtsregeln, Repository-Bindungen begrenzen, welchen Code der Agent sieht, und die Task-Run-Einstellungen deckeln parallele Tasks und die Run-Dauer. Der temporäre Arbeitsverzeichnis-Modus schafft zusätzliche Isolation, indem jeder Task sein eigenes Verzeichnis bekommt. Die endgültige Abnahme liegt weiterhin bei einem Menschen.
Warum startet mein zugewiesener Task nicht?
Prüfe drei Dinge. Ein Task im Backlog wartet absichtlich; verschiebe ihn in einen Status, der für Arbeit bereit ist. Dass ein Computer online ist, heißt nur, dass Heartbeats ankommen – prüfe also, ob die ausgewählte Runtime als verfügbar angezeigt wird. Und ein Agent, der online ist, kann Arbeit dennoch in die Warteschlange stellen, wenn seine Parallelität oder seine festgelegten Verzeichnisse ausgelastet sind.
