In jedem Projektboard Ihres Teams steckt eine stille Annahme: Jeder Zugewiesene ist ein Mensch. Jede Statusänderung wurde von jemandem angeklickt. Jedes „Fertig“ bedeutet, dass ein Mensch die Arbeit erledigt und ein zweiter Mensch einen Blick darauf geworfen hat. Diese Annahme hat zwanzig Jahre Projektmanagement-Software getragen – und sie gerät an ihre Grenzen, sobald Ihr Team beginnt, echte Arbeit an KI-Coding-Agents zu vergeben.
Agenten verhalten sich nicht wie die Zugewiesenen, für die Ihr Board gebaut wurde. Sie arbeiten um 2 Uhr nachts. Sie sind in Minuten fertig und warten dann still darauf, dass jemand es bemerkt. Sie liefern einen Diff, einen Testlauf und eine Zusammenfassung statt eines Standup-Updates. Kann Ihr Tracker davon nichts abbilden, findet Agenten-Arbeit außerhalb des Boards statt: in privaten Terminals, privaten Chats und privaten Bauchentscheidungen. Die Arbeit wird erledigt, aber niemand kann sie sehen, verantworten oder abnehmen.
Diese Lücke zu schließen ist eine Disziplin mit einem Namen: KI-Agent-Projektmanagement. Dieser Leitfaden definiert sie, grenzt sie von Begriffen ab, mit denen sie verwechselt wird, geht ihren Betriebszyklus durch und zeigt, was sich bei jedem vertrauten PM-Grundbaustein ändert. Als Referenzimplementierung nutzen wir Sharkly – genauso wie in unserem Leitfaden zur KI-Agenten-Orchestrierung: erst die Kategorie, dann das Produkt.
TL;DR: Was ist KI-Agent-Projektmanagement?
KI-Agent-Projektmanagement ist die Praxis, von KI-Agenten ausgeführte Arbeit parallel zu menschlicher Arbeit zuzuweisen, zu verfolgen und zu prüfen – sodass jede Agenten-Aufgabe einen Verantwortlichen, einen Status, vollständigen Kontext und einen Menschen hat, der das Ergebnis annimmt oder ablehnt. Es behandelt Agenten als Zugewiesene innerhalb eines gemeinsamen Arbeitssystems und nicht als Werkzeuge in privaten Terminals. Es unterscheidet sich von der Agenten-Orchestrierung, die Agenten zum Laufen bringt; Agenten-PM macht ihre Arbeit sichtbar, verantwortbar und abnehmbar. Sie brauchen es, sobald Agenten-Arbeit Teamarbeit wird: mehrere Agenten, mehrere Menschen und Ergebnisse, die wichtig genug sind, um geprüft zu werden.
Die Definition im Detail
KI-Agent-Projektmanagement ist die Disziplin, Arbeit zu steuern, deren Zugewiesene KI-Agenten einschließen: Aufgaben definieren, die Agenten ausführen können, sie dem richtigen Agenten oder der richtigen Person zuweisen, Kontext und Ausführungsprotokoll an einem gemeinsamen Ort halten und jedes Ergebnis durch menschliche Prüfung und Abnahme leiten.
Auf fünf Wörtern in diesem Satz liegt das eigentliche Gewicht:
- Zuweisung. Ein Agent bekommt eine Aufgabe wie ein Teammitglied – mit angehängtem Ziel, Rahmenbedingungen und Akzeptanzkriterien, nicht hineinkopiert in einen Prompt, der verschwindet, wenn das Terminal geschlossen wird.
- Verfolgung. Agenten-Arbeit hat einen Status, den das ganze Team sieht – von „in der Warteschlange“ über „läuft“ bis „wartet auf Review“ – und zwar im selben Plan wie die menschliche Arbeit.
- Kontext. Der Agent liest seine Aufgabe so, wie ein neues Teammitglied es tun würde: Beschreibung, Kommentare, verlinkter Code, frühere Entscheidungen. Und sein Output landet wieder in genau diesem Datensatz.
- Prüfung. Ein Mensch liest, was der Agent produziert hat, bevor es zählt.
- Verantwortlichkeit. Für jede Agenten-Aufgabe gibt es einen Menschen, der dafür geradesteht. Der Agent hat ausgeführt; die Verantwortung für das Ergebnis trägt eine Person.
Wenn Ihr Setup diese fünf Dinge liefert, betreiben Sie KI-Agent-Projektmanagement – unabhängig vom Tooling. Wenn es keines davon liefert, haben Sie Agenten, aber kein Management.
Was KI-Agent-Projektmanagement nicht ist
Drei verwandte Begriffe werden mit diesem einen vermischt, und diese Vermischung sorgt für echte Verwirrung, wenn Teams nach Tools suchen.
Kein klassisches Projektmanagement mit angeflanschten Agenten
Jira, Linear und ihre Verwandten wurden auf der Annahme menschlicher Zugewiesener gebaut: eine einzige Art von Zugewiesenem, Status, die menschliche Arbeitsrhythmen abbilden, und keine Unterscheidung im Datenmodell zwischen „wer ist verantwortlich“ und „was führt aus“. Einige haben sich in Richtung Agenten bewegt (Linear kann ein Issue an einen verbundenen Coding-Agenten delegieren, der Fortschritt und einen Diff zum Issue zurückmeldet), doch die Ausführung findet weiterhin in dem gehosteten Agenten des Anbieters statt, den Sie verbunden haben – zu dessen Bedingungen. Was Ihnen fehlt, ist eine neutrale Ebene, um Ihren eigenen Mix aus Runtimes auf Maschinen laufen zu lassen, die Sie kontrollieren, mit einem gemeinsamen Datensatz für jeden Lauf. Wie weit die klassischen Tracker reichen, vergleichen wir in unserem Leitfaden zu Jira-Alternativen für Mensch-Agent-Teams.
Keine Agenten-Orchestrierung
Das ist die wichtigste Unterscheidung, denn die beiden Disziplinen liegen nah beieinander und ergänzen sich. Bei der Agenten-Orchestrierung geht es um die Ausführung: eine Aufgabe an einen Agenten weiterleiten, den Arbeitsbereich jedes Agenten isolieren, damit sich parallele Läufe nicht in die Quere kommen, und die Maschinerie am Laufen halten. Beim Agenten-Projektmanagement geht es um die Arbeit selbst: Wer hat sie angefordert, was muss sie erreichen, in welchem Zustand ist sie, wer prüft sie und wurde sie abgenommen?
Eine saubere Trennung: Orchestrierung bringt Agenten zum Laufen; Agenten-PM macht ihre Arbeit sichtbar, verantwortbar und abnehmbar. Ein Team kann exzellente Orchestrierung und kein Agenten-PM haben – dann laufen zehn Agenten reibungslos parallel, während niemand sagen kann, woran sie arbeiten oder wer am Ende absegnet.
Kein Agenten-Framework
Frameworks wie LangGraph oder die Multi-Agenten-Muster in Agenten-SDKs sind Code-Bibliotheken zum Bauen von Agenten-Anwendungen. Sie richten sich an Entwickler, die einen Agenten konstruieren. Agenten-PM richtet sich an Teams, die Agenten einsetzen – meist fertige Coding-Runtimes wie Claude Code oder Codex – und die diese Arbeit in einen Team-Plan integrieren müssen. Sie können KI-Agent-Projektmanagement einführen, ohne eine Zeile Framework-Code zu schreiben. Wenn es neu für Sie ist, Coding-Arbeit an autonome Tools zu delegieren, beginnen Sie mit unserer Einführung dazu, was agentisches Coding ist.
Der Betriebszyklus: definieren, zuweisen, ausführen, prüfen, abnehmen
Zerlegen Sie jedes Agenten-PM-Setup bis auf sein Skelett, finden Sie denselben fünfstufigen Zyklus. Jede Stufe hat eine menschliche und eine Agenten-Hälfte, und der Zyklus funktioniert nur, wenn beide explizit sind.
1. Definieren. Eine Person schreibt die Aufgabe: das Ziel, warum es wichtig ist, was zum Umfang gehört und was nicht, und wie die Fertigstellung beurteilt wird. Bei Agenten zählt das mehr als bei Menschen, denn ein Agent kann Flurfunk-Kontext nicht aufsaugen. Ein Teammitglied, das ein vages Ticket erhält, stellt beim Mittagessen eine Rückfrage; ein Agent fragt entweder in einem Kommentar nach oder rät einfach.
2. Zuweisen. Die Aufgabe geht an einen Zugewiesenen – und hier teilt sich der Grundbaustein in zwei. Die Verantwortung geht an eine Person: den Menschen, der das Ergebnis verantwortet. Die Ausführung geht an einen Agenten oder an eine Person, wenn es Arbeit ist, die Agenten nicht anfassen sollten. Diese beiden als getrennte Felder zu führen statt als ein überladenes „Assignee“ ist die wichtigste Datenmodell-Änderung im Agenten-PM. Sie erhält die Verantwortlichkeit, während die Ausführung in Software wandern kann. Unsere Schritt-für-Schritt-Anleitung zum Zuweisen eines Jira-Tickets an einen KI-Agenten und zum Zurückbekommen eines PR zeigt diese Stufe von Anfang bis Ende.
3. Ausführen. Der Agent liest die Aufgabe, untersucht den Code, nimmt Änderungen vor, führt Checks aus. Diese Stufe gehört der Orchestrierung, und das Agenten-PM verlangt nur eines von ihr: dass Fortschritt, Blocker und Ergebnisse zur Aufgabe zurückkehren, statt im Terminal wegzuscrollen. Eine Ausführung ohne gemeinsamen Datensatz ist eine Ausführung, die das Team nicht steuern kann.
4. Prüfen. Der Agent hält an, und ein Mensch liest: den Diff, die Testergebnisse, die Zusammenfassung des Agenten darüber, was er getan hat und was unsicher bleibt. Beim Review trifft Agenten-Geschwindigkeit auf menschliches Urteilsvermögen, und zur ehrlichen Version dieser Stufe gehört auch die Ablehnung. Wer nur auf „Genehmigen“ klicken kann, ist ein Abnickstempel, keine Prüfinstanz.
5. Abnehmen. Die verantwortliche Person entscheidet: annehmen, Änderungen anfordern oder neu zuweisen. Die Abnahme unterscheidet sich von der Prüfung wie das Mergen vom Lesen eines Pull Requests. Sie ist der Moment, in dem Verantwortlichkeit eingelöst wird, und sie ist bewusst menschlich. Agenten recherchieren, führen aus, testen und berichten. Menschen geben die Richtung vor, erteilen Befugnisse und nehmen das Ergebnis ab.
Dann nährt sich der Zyklus selbst: Abgenommene Arbeit definiert die nächste Aufgabe, und abgelehnte Arbeit kehrt mit schärferen Kriterien zum Definieren zurück.
Was sich bei jedem PM-Grundbaustein ändert
Das Vokabular des Projektmanagements übersteht die Ankunft von Agenten. Die Mechanik darunter ändert sich fast vollständig.
| Grundbaustein | Annahme im klassischen PM | Agenten-natives PM |
|---|---|---|
| Aufgabe | Geschrieben für einen Menschen, der im Umfeld nach Kontext fragen kann | In sich geschlossenes Briefing mit Ziel, Umfang, Links und überprüfbaren Akzeptanzkriterien |
| Zugewiesener | Ein Feld, immer eine Person | Zwei Felder: eine verantwortliche Person plus ein ausführender Agent oder eine ausführende Person |
| Status | Manuell im menschlichen Rhythmus bewegt (Tage) | Workflow-Status plus ein Live-Ausführungsstatus (in der Warteschlange, läuft, fehlgeschlagen), der sich in Minuten aktualisiert |
| Sprint | Auf die menschliche Verfügbarkeit zugeschnitten | Gemischter Umfang; Agenten-Durchsatz begrenzt durch Maschinenkapazität und Review-Kapazität |
| Kapazität | Mitarbeiterzahl und Stunden | Personen-Stunden plus Agenten-Parallelität, wobei der menschliche Review die eigentliche Obergrenze ist |
| Audit-Trail | Kommentare und manuelle Status-Historie | Ausführungsprotokolle, Traces, Diffs und Agenten-Berichte, die am Aufgaben-Datensatz hängen |
Aufgaben sind keine Erinnerungen mehr, sondern Briefings. Ein menschlicher Zugewiesener toleriert Mehrdeutigkeit; ein Agent verwandelt sie in selbstsicher falsche Antworten. Aufgaben mit explizitem Umfang und Akzeptanzkriterien zu schreiben – lange gepredigt und selten praktiziert – wird zur tragenden Anforderung.
Der Status teilt sich in zwei Ebenen. Der Workflow-Status beschreibt weiterhin, wo die Arbeit für das Team steht. Darunter hat die Agenten-Ausführung eigene Zustände: in der Warteschlange, läuft, abgeschlossen, fehlgeschlagen, abgebrochen. Eine Aufgabe kann auf „In Arbeit“ stehen, während ihr Agenten-Lauf fehlgeschlagen ist und es niemand gemerkt hat. Agenten-natives Tooling macht beide Ebenen sichtbar und leitet die Momente „wartet auf Ihren Review“ und „Lauf fehlgeschlagen“ an die verantwortliche Person weiter, statt darauf zu hoffen, dass jemand nachschaut.
Sprints behalten ihre Form und ändern ihre Physik. Ein Sprint ist weiterhin ein zeitlich begrenzter Umfang mit einem Ziel. Doch wenn ein Teil des Umfangs in Minuten statt in Tagen ausgeführt wird, verschiebt sich die Planung von „Was können die Menschen fertigstellen?“ zu „Was können die Menschen definieren und prüfen?“ Die Mechanik dahinter behandeln wir in Wie Sprints in Sharkly funktionieren.
Kapazität wird zu einer zweiseitigen Zahl. Die Kapazität auf Agentenseite ist eine Rechnung aus Maschinen und Parallelität. Die Kapazität auf menschlicher Seite ist die Review-Kapazität: Wie viele Agenten-Ergebnisse kann Ihr Team sorgfältig lesen? Die zweite Zahl ist fast immer die kleinere – und wenn man das Gegenteil annimmt, mergen Teams am Ende Arbeit, die niemand gelesen hat.
Der Audit-Trail wandelt sich von optionaler Hygiene zur Kernanforderung. Wenn ein Mensch die Arbeit erledigt hat, können Sie ihn fragen, was passiert ist. Wenn ein Agent sie erledigt hat, ist die einzige ehrliche Antwort das Ausführungsprotokoll: die Aufgabe, der Trace, die durchgeführten Checks und der hinterlassene Bericht.
Wann Sie kein KI-Agent-Projektmanagement brauchen
Ein ehrlicher Leitfaden nennt auch die Fälle, in denen die Antwort „noch nicht“ lautet. Überspringen Sie die Agenten-PM-Ebene, wenn Sie als Solo-Entwickler einen einzigen Agenten betreiben, wenn das Agenten-Volumen bei ein paar Aufgaben pro Woche liegt, die als ganz normale Tickets leben können, oder wenn es sich um Wegwerf-Prototyping handelt, das nie geprüft oder gepflegt wird. Prozess sollte dem Volumen folgen, nicht vorausgehen.
Führen Sie es ein, wenn die Signale kippen: Mehr als eine Person muss Agenten-Arbeit sehen, es laufen mehr als ein Agent gleichzeitig, oder eine ungeprüfte Agenten-Änderung hat bereits Schaden angerichtet. Nutzen Sie ein gemeinsames System, wenn Agenten-Arbeit Teamarbeit wird – und nicht früher.
Wie Agenten-PM in der Praxis aussieht: Sharkly
Die Kategorie ist tool-agnostisch; die Mechanik ist in einem konkreten System leichter zu erkennen. Sharkly ist ein Work-Management-System für Menschen und Agenten. Es ersetzt nicht Claude Code, Codex oder andere Ausführungstools. Es ergänzt die Ebene für gemeinsame Aufgaben, Kontext, Steuerung und Review um die Runtimes herum, die Ihr Team bereits nutzt – die Modellnutzung läuft weiterhin über die Abos oder API-Keys, die in diesen Tools konfiguriert sind.
Die Aufgabe ist die Einheit der Aufzeichnung: Ziel, Beschreibung, Status, Priorität, Kommentare sowie Ausführungsstatus, Trace und Ergebnis des Agenten – alles an einem Ort. Die Zuweisung setzt die oben beschriebene Trennung um: Eine Person trägt die menschliche Verantwortung, während ein Agent oder eine Crew der ausführende Zugewiesene ist, und eine Aufgabe kann beides gleichzeitig tragen. Das Backlog fungiert als Parkzustand: Einen Agenten zuzuweisen startet noch keinen Lauf, bis die Aufgabe in einen Status wechselt, der für die Arbeit bereit ist.
Während ein Agent arbeitet, bleiben Run-Zustände vom Workflow-Status der Aufgabe getrennt, und beide sind auf dem Board sichtbar. Ergebnisse, Blocker und Folge-Diskussionen kehren zur Aufgabe zurück: Der Bericht des Agenten wird als Kommentar gespeichert, der mit seinem Ausführungs-Trace verknüpft ist, und die Inbox leitet „wartet auf Ihren Review“-Momente an die verantwortliche Person weiter. Die Abnahme bleibt menschlich. Die Sharkly-Dokumentation geht auf jedes Konzept ausführlicher ein.
Das Fazit
Projektmanagement hat sich bewährt, weil es menschliche Arbeit sichtbar, verantwortbar und prüfbar macht. KI-Agent-Projektmanagement dehnt denselben Vertrag auf Zugewiesene aus, die zufällig Software sind: Definieren Sie die Arbeit klar, trennen Sie Verantwortung und Ausführung, lassen Sie Ergebnisse in einen gemeinsamen Datensatz zurückfließen und behalten Sie die Abnahme in menschlicher Hand. Orchestrierung macht Ihre Agenten schnell. Diese Disziplin macht ihre Ergebnisse vertrauenswürdig. Fangen Sie klein an: Nehmen Sie eine wiederkehrende Agenten-Arbeit, die heute in einem Terminal lebt, formulieren Sie dafür eine Aufgabe mit echten Akzeptanzkriterien und lassen Sie sie einmal durch den Zyklus laufen.
FAQ
Was ist KI-Agent-Projektmanagement in einem Satz?
Es ist die Praxis, von KI-Agenten ausgeführte Arbeit parallel zu menschlicher Arbeit zuzuweisen, zu verfolgen und zu prüfen, sodass jede Agenten-Aufgabe einen Verantwortlichen, einen Status, vollständigen Kontext und einen Menschen hat, der das Ergebnis abnimmt. Kurz gesagt: Es behandelt Agenten als Zugewiesene in einem gemeinsamen Arbeitssystem statt als Werkzeuge in privaten Terminals.
Wie unterscheidet sich KI-Agent-Projektmanagement von Agenten-Orchestrierung?
Orchestrierung bringt Agenten zum Laufen: Routing, Isolation der Arbeitsbereiche, parallele Ausführung, Maschinenkapazität. Agenten-PM macht ihre Arbeit sichtbar, verantwortbar und abnehmbar: Aufgaben, Status, Review und Verantwortlichkeit. Es sind komplementäre Ebenen, und ein vollständiges Setup braucht beide. Unser Orchestrierungs-Leitfaden behandelt die Ausführungsseite ausführlich.
Kann ich KI-Agent-Projektmanagement in Jira oder Linear betreiben?
Teilweise. Sie können Agenten-Aufgaben als Tickets abbilden, und einige Tracker delegieren Issues inzwischen an verbundene Coding-Agenten. Was sie Ihnen nicht bieten, ist eine neutrale Ausführungsebene über Ihren eigenen Mix aus Runtimes und Maschinen hinweg, mit einem gemeinsamen Datensatz für jeden Lauf. Siehe unseren Vergleich der Jira-Alternativen für Mensch-Agent-Teams.
Wer ist verantwortlich, wenn ein KI-Agent die Arbeit erledigt?
Immer ein Mensch. Im Agenten-PM sind der verantwortliche Mensch und der ausführende Agent getrennte Felder derselben Aufgabe: Der Agent führt aus, und die Person verantwortet das Ergebnis, prüft es und entscheidet über die Abnahme. Ein Agent ist nie die endgültige Antwort auf die Frage „Wer hat das abgesegnet?“.
Worauf sollte ich bei einem Tool für KI-Agent-Projektmanagement achten?
Vier Dinge entsprechen dem Betriebszyklus: eine Zuweisung, die den vollständigen Aufgabenkontext zum Agenten bringt, Live-Tracking, das sowohl Workflow-Status als auch Ausführungsstatus zeigt, ein Audit-Trail, bei dem Traces und Ergebnisse zur Aufgabe zurückkehren, und ein integrierter Schritt für menschliches Review und Abnahme. Dazu kommt hybride Sprint-Planung, wenn Sie Agenten innerhalb eines Team-Rhythmus laufen lassen.
