Warum Projektplanung agentische KI erst steuerbar macht

Agentische KI verändert die Logik von Projektarbeit. Ein klassischer Assistent wartet auf den nächsten Prompt. Ein agentisches System kann dagegen Aufgaben zerlegen, Werkzeuge benutzen, Zwischenergebnisse erzeugen, weitere Arbeit anstoßen und über längere Strecken selbstständig auf ein Ziel hinarbeiten. Genau darin liegt sein Wert – und genau darin liegt das Steuerungsproblem.

Je mehr Handlungsspielraum ein System erhält, desto weniger reicht eine vage Aufgabenbeschreibung. „Mach das Projekt fertig" ist für einen Chat schon unpräzise. Für einen Agentenverbund ist es eine Einladung, fehlende Entscheidungen selbst zu ergänzen. Das kann produktiv wirken, solange die impliziten Annahmen stimmen. Sind sie falsch, skaliert die Autonomie nicht Qualität, sondern Abweichung.

Die Praxis entwickelt deshalb eine klare Gegenposition zur Idee, Agenten müssten vor allem „frei" arbeiten dürfen. Die Rolle des Projektmanagers lässt sich bereits sehr präzise beschreiben: Der Mensch setzt Richtung, Ziele und Erfolgsdefinition und trifft die Entscheidungen; spezialisierte Agenten können Daily Flow, Qualitätssicherung, Dokumentation oder Feedbackverarbeitung übernehmen. Im Juli wird diese Logik weiter formalisiert: Orchestrator, Reviewer, Spezialist und Human Authority werden als definierte Rollen gedacht, menschliche Eingriffe an Gates gebündelt und agentische Arbeit auf einen Projektplan mit Evidenz- und Stopplogik ausgerichtet.

Die zentrale These dieses Artikels lautet daher: Projektplanung ist bei agentischer KI nicht vorgelagerte Bürokratie. Sie ist die Steuerungsschicht, die Autonomie überhaupt erst verantwortbar macht.

Autonomie verstärkt, was im Auftrag bereits angelegt ist

Bei manueller Arbeit kann ein unklarer Auftrag lange durch Rückfragen kompensiert werden. Menschen merken häufig, wenn ein Ziel widersprüchlich ist, Kontext fehlt oder eine Entscheidung politisch sensibel wird. Sie halten an, fragen nach oder handeln aus Erfahrung vorsichtig.

Ein Agent kann ebenfalls Unsicherheit erkennen. Aber wenn sein Auftrag auf Fortsetzung optimiert ist und keine Eskalationslogik besitzt, wird er Lücken oft durch plausible Annahmen schließen. Das ist nicht zwangsläufig ein Fehler des Modells. Es ist häufig ein Fehler des Projektdesigns.

Agentische Systeme machen damit eine alte Managementregel sichtbar: Delegation funktioniert nur, wenn Auftrag, Entscheidungsspielraum und Rückkehrpunkt geklärt sind.

Je autonomer die Ausführung wird, desto wichtiger werden sechs Planungsfragen:

1. Welches Ergebnis soll erreicht werden?

2. Welche Informationen und Ressourcen sind verbindliche Inputs?

3. Welche Outputs müssen in welcher Qualität entstehen?

4. Welche Rolle darf welche Entscheidung treffen?

5. An welchen Punkten muss geprüft, eskaliert oder freigegeben werden?

6. Unter welchen Bedingungen muss das System stoppen?

Diese Fragen bilden keine zusätzliche Dokumentationsschicht neben dem Projekt. Sie sind der operative Rahmen des Projekts.

Der Projektplan wird zum Steuerungsvertrag

Ein klassischer Plan wird oft als Zeit- und Aufgabenübersicht verstanden. Für agentische Arbeit reicht das nicht. Ein agentenfähiger Plan muss zusätzlich festlegen, wie Arbeit interpretiert werden darf.

Man kann ihn als Steuerungsvertrag lesen. Dieser Vertrag beschreibt nicht jede einzelne Aktion. Er definiert vielmehr die Bedingungen, unter denen Aktionen gültig sind.

Ein solcher Steuerungsvertrag besteht mindestens aus:

Ziel und Zweck: Was soll erreicht werden – und warum?

Scope und Non-Scope: Welche Resultate gehören zum Projekt, welche ausdrücklich nicht?

Inputs: Welche Daten, Quellen, Dateien, Entscheidungen und Vorbedingungen gelten als Ausgangslage?

Outputs: Welche Artefakte oder Zustände müssen entstehen?

Qualitätskriterien: Woran wird erkannt, dass ein Output ausreichend ist?

Rollen: Wer oder was plant, erzeugt, prüft, dokumentiert und entscheidet?

Gates: Welche Evidenz muss vorliegen, bevor die nächste Stufe freigegeben wird?

Stop-Bedingungen: Wann darf das System nicht einfach weitermachen?

Eskalation: Wer wird aufgerufen, wenn ein Gate scheitert, Regeln kollidieren oder Kontext fehlt?

Der Unterschied zu einer langen Promptfolge ist fundamental. Eine Promptfolge sagt dem System nacheinander, was es tun soll. Ein Steuerungsvertrag sagt ihm, innerhalb welcher Architektur es selbstständig handeln darf.

Ziele müssen handlungsfähig sein

„Erstelle eine gute Website" ist ein Wunsch. „Entwickle einen klickbaren Prototypen für drei definierte Nutzerpfade, der auf fünf festgelegten Aufgaben getestet werden kann" ist ein handlungsfähiges Ziel.

Agenten brauchen Ziele, die gleichzeitig offen genug für Problemlösung und eng genug für Bewertung sind. Zu enge Ziele führen zu Mikromanagement. Zu breite Ziele zwingen das System, Produktstrategie, Priorisierung und Qualitätsdefinition selbst zu erfinden.

Ein handlungsfähiges Ziel enthält typischerweise vier Elemente:

• den gewünschten Zustand,

• die relevante Zielgruppe oder Nutzungssituation,

• beobachtbare Erfolgskriterien,

• eine Grenze, was nicht Teil des aktuellen Auftrags ist.

Der Mensch muss dabei nicht jede Methode vorgeben. Im Gegenteil: Ein guter agentischer Auftrag lässt Methodenwahl dort offen, wo Varianten sinnvoll sind. Er hält aber Zweck und Bewertung stabil.

Das ist der Unterschied zwischen Richtung und Route. Der Projektplan bestimmt die Richtung, die Leitplanken und die Kontrollpunkte. Der Agent darf innerhalb dieses Rahmens die Route optimieren.

Inputs sind nicht nur Dateien, sondern gültiger Kontext

Agentische Systeme arbeiten selten nur mit einer Aufgabe. Sie arbeiten mit Projektordnern, Wissensbasen, Repositories, Research-Ergebnissen, bestehenden Entscheidungen, Toolzugängen und Zwischenständen. Diese Inputs müssen als Teil des Plans verstanden werden.

Ein Input ist jedoch nicht automatisch gültig, nur weil er verfügbar ist. Ein Projektordner kann veraltete Versionen enthalten. Eine Wissensbasis kann widersprüchliche Quellen enthalten. Ein früheres Konzept kann durch eine spätere Entscheidung überholt sein.

Deshalb sollte ein agentischer Arbeitsblock klären:

• Welche Quellen sind verbindlich?

• Welche Version ist aktuell?

• Welche Informationen dienen nur als Hintergrund?

• Welche Annahmen sind noch offen?

• Welche Daten dürfen benutzt werden?

• Welche Werkzeuge oder Umgebungen sind freigegeben?

Damit wird Kontext zu einer kontrollierten Ressource. Spätere Artikel dieser Serie werden sich ausführlicher mit Projektordnern, Handoffs und Wissensräumen beschäftigen. Für die Planung genügt hier der entscheidende Punkt: Ein Agent kann nur so zuverlässig handeln, wie der gültige Kontext identifizierbar ist.

Outputs müssen prüfbar statt nur plausibel sein

Ein Agent kann sehr schnell viel produzieren. Deshalb ist die Menge der Ergebnisse ein schlechter Steuerungsindikator.

Gute Planung definiert Outputs so, dass sie prüfbar sind. „Recherche abschließen" ist kein sauberer Output. Besser wäre beispielsweise: „Eine konsolidierte Quellenübersicht mit fünf offenen Streitpunkten, drei Entscheidungshypothesen und Verweisen auf die Primärquellen."

„Landingpage bauen" ist ebenfalls zu breit. Ein belastbarer Output könnte lauten: „Responsive klickbare Landingpage mit definiertem Conversion-Pfad, funktionierendem Formular, dokumentierten Abhängigkeiten und bestandenem Review gegen die Akzeptanzkriterien."

Ein agentischer Output braucht damit mindestens:

Artefakt: Was liegt nach der Arbeit konkret vor?

Format: Wie muss es übergeben werden?

Akzeptanzkriterien: Welche Eigenschaften müssen erfüllt sein?

Nachweis: Welche Tests, Quellen oder Logs belegen die Qualität?

Status: Ist das Ergebnis Entwurf, geprüft, freigegeben oder blockiert?

Je klarer diese Felder sind, desto weniger muss der Mensch jede Zwischenaktion beobachten. Er kann sich auf die Qualität der Übergaben konzentrieren.

Rollen trennen Produktion von Kontrolle

Einer der stärksten Gedanken dieses Ansatzes ist die Trennung spezialisierter Rollen. Dazu gehören unter anderem QA-, Dokumentations- und Feedback-Agenten. Die Logik dahinter ist wichtiger als die konkreten Rollennamen: Das System, das produziert, sollte nicht automatisch die einzige Instanz sein, die seine eigene Arbeit bewertet.

Im Juli wird daraus ein klareres Rollenbild mit Orchestrator, Reviewer, Spezialist und Human Authority.

Für die Projektplanung bedeutet das:

Orchestrator: hält Ziel, Reihenfolge, Abhängigkeiten und Zustände zusammen.

Spezialist: bearbeitet einen klar abgegrenzten fachlichen Arbeitsblock.

Reviewer: prüft Output gegen definierte Kriterien und Evidenz.

Dokumentation: hält Entscheidungen, Änderungen, Versionen und Nachweise fest.

Human Authority: entscheidet dort, wo Projektwert, Risiko, Priorität oder irreversible Konsequenzen betroffen sind.

Nicht jedes Projekt braucht fünf getrennte Agenten. Rollen können technisch zusammengelegt werden. Wichtig ist die funktionale Trennung. Der Plan muss wissen, wann gerade produziert, geprüft, dokumentiert oder entschieden wird.

Ein späterer Artikel dieser Serie wird diese Rollenarchitektur ausführlich behandeln. Hier ist sie vor allem als Planungsprinzip relevant: Rollen machen Verantwortung adressierbar.

Gates ersetzen Dauerüberwachung

Viele Teams reagieren auf autonome Systeme mit dem Wunsch, alles mitzulesen. Das skaliert schlecht. Wenn ein Agent jede Minute kontrolliert werden muss, wurde zwar Arbeit delegiert, aber keine Steuerung gewonnen.

Gates lösen dieses Problem anders. Sie bündeln menschliche Aufmerksamkeit an Stellen, an denen Entscheidungen tatsächlich wertvoll sind.