Die erste Fehlannahme über Agentic AI lautet: Man könne die Kosten wie bei einer API-Funktion schätzen. Eingabe rein, Ausgabe raus, Preis pro Token multiplizieren, fertig. Für Chat-Interaktionen ist das schon grob. Für Agenten ist es falsch.

Agenten arbeiten nicht nur mit einem Prompt. Sie laden Kontext, rufen Tools auf, planen Zwischenschritte, schreiben Dateien, lesen Logs, prüfen Ergebnisse, verwerfen Hypothesen, starten neue Läufe und erzeugen Review-Artefakte. Ein scheinbar kleiner Coding-Task kann dadurch zu einer Sequenz aus Millionen Tokens werden.

Der Tokenpreis ist nicht die Kostenrechnung

Tokenpreise sind sichtbar, aber nicht ausreichend. Entscheidend ist die Architektur der Arbeit. Ein Agent braucht Systemprompt, Entwicklerprompt, Aufgabenbeschreibung, Repository-Kontext, Tool-Ausgaben, Zwischenergebnisse, Testlogs und Review-Kommentare. Jeder dieser Bausteine erweitert den Kontext oder erzeugt neue Läufe.

Bei Multi-Agent-Systemen steigt diese Dynamik noch einmal. Anthropic beschreibt für sein Multi-Agent Research System einen etwa 15-fach höheren Tokenverbrauch gegenüber Chat-Interaktionen. Das kann sich bei hochwertigen Rechercheaufgaben lohnen. Für Standard-Coding, Routine-Triage oder einfache Zusammenfassungen ist es oft eine teure Überkonstruktion.

Wo die Kosten entstehen

Kostentreiber	Warum er wächst	Kontrollhebel
Kontext	Agenten laden Code, Dokumente, Tickets, Logs und frühere Antworten.	Kontextbudget, Retrieval-Filter, Cache-Strategie
Tool-Calls	Jeder Shell-, Browser-, Datenbank- oder API-Aufruf erzeugt Ausgaben und Folgekontext.	Tool-Rechte, Rate Limits, Trace-Auswertung
Retries	Unklare Anforderungen führen zu Korrekturschleifen.	Akzeptanzkriterien, Definition of Done, Human Gate
Validierung	Tests, Evals, Review-Agenten und menschliche Freigaben sind notwendig, aber kostenintensiv.	Risikoklassen, Eval-Suites, Sampling
Wartung	Prompts, Modelle, Tool-Schnittstellen und Policies verändern sich.	Versionierung, Regression Tests, Prompt-Migration

Build ist nur der Anfang

Bei klassischer Software lässt sich ein Projekt oft um Features, Story Points, Personentage oder Function Points organisieren. Bei Agentic AI verschiebt sich der Schwerpunkt. Der erste Build ist nur ein Teil der Gesamtkosten. Danach entstehen laufende Kosten für Modellaufrufe, Evaluationsläufe, Observability, Prompt- und Policy-Pflege, Datenqualität, Sicherheitsprüfungen und menschliche Review-Kapazität.

In der Praxis ist deshalb eine TCO-Sicht nötig. Ein realistisches Modell trennt mindestens drei Ebenen: Entwicklung, Betrieb und Wartung.

Ebene	Kostenobjekte	Typischer Fehler
Entwicklung	Agentenlogik, Prompts, Tool-Adapter, Tests, Eval-Datensätze	Nur Modellkosten und Developer-Zeit zählen
Betrieb	Inference, Kontext, Cache, Tool-Calls, Monitoring, Human Review	Retry- und Review-Volumen unterschätzen
Wartung	Prompt-Migration, Modellwechsel, Regression, Policy Updates, Audit-Nachweise	Agenten wie stabile Softwarekomponenten behandeln

Warum klassische Schätzmodelle nicht reichen

Function Points, Story Points oder COCOMO messen bekannte Softwarearbeit. Sie sind damit nicht wertlos. Sie bleiben nützlich, um funktionale Größe, Datenbewegungen, Akteurskomplexität und relative Roadmap-Größen zu prüfen. Was sie nicht liefern, ist eine belastbare direkte Antwort auf die Frage: Wie viele Tokens verbraucht ein agentischer Entwicklungs- oder Betriebsprozess?

Agentic AI bringt Arbeit in das System hinein, die erst während der Ausführung entsteht. Ein Agent entscheidet, welche Dateien relevant sind, welche Tools er aufruft, welche Tests er startet und wie viele Korrekturen nötig sind. Der Aufwand ist nicht nur eine Eigenschaft der Aufgabe, sondern eine Eigenschaft der Interaktion zwischen Aufgabe, Modell, Kontext, Toolchain und Governance.

Frontiers in Artificial Intelligence argumentiert deshalb für LLM-bewusste Aufwandsschätzung. Klassische Modelle erfassen nicht ausreichend, dass Validierung, Korrektur, Prompt-Iteration, Modellunsicherheit und Kontextmanagement selbst zu Aufwandstreibern werden. In agentischen Systemen wird Schätzung damit weniger zu einer Vorhersage von Arbeitsstunden und stärker zu einer Budgetierung von Unsicherheit.

Was etablierte Methoden weiterhin leisten

Methode	Einheit	Stärke	Grenze bei Agentic AI
IFPUG Function Points	External Input, External Output, External Inquiry, Internal Logical File, External Interface File	Industrie-Standard für funktionale Größe transaktionaler Systeme.	Algorithmische Arbeit, Prompt-Iteration und Validierung werden nur indirekt sichtbar.
COSMIC Function Points	Datenbewegungen: Entry, Exit, Read, Write	Gut für Ledgers, Gates, Adapter, API-Flüsse und moderne Datenbewegungslogik.	Kein eigener Maßstab für LLM-Reasoning, Kontextqualität oder Retry-Schleifen.
Use Case Points	Use-Case-Gewichte, Akteursgewichte, technische und Umweltfaktoren	Passt gut zu User Stories, Rollen und Spezifikationen.	Der Stundenfaktor ist teamspezifisch; Token werden nicht direkt abgeleitet.
T-Shirt-Sizing	XS bis XXL	Schnell, kommunikativ, nützlich für Roadmaps und Priorisierung.	Relative Größe ohne absolute Betriebs- oder Tokenkosten.

Der methodische Kern ist deshalb nicht die Ersetzung klassischer Schätzung, sondern ihre Entkopplung von der Token-Prognose. COSMIC, IFPUG und Use Case Points liefern Größen- und Plausibilitätskontrollen. Die Token-Schätzung braucht zusätzlich Messdaten aus realen Läufen.

Kein Standard: Tokens pro Function Point

Die LLM-Token-Forschung ist noch jung. Die Tokenomics-Studie untersucht, wo Tokens in agentischen Software-Engineering-Systemen verbraucht werden. Die Forschung zu LLM-aware effort estimation beschreibt, warum klassische Aufwandstreiber nicht mehr stabil mit tatsächlichem Entwicklungsaufwand korrelieren. Ein veröffentlichter, breit validierter Konversionsfaktor wie X Tokens pro COSMIC Function Point oder X Tokens pro Use Case Point existiert aber nicht.

Jede konkrete Token-Prognose muss deshalb als Kalibrierung gelesen werden: Sie gilt für einen bestimmten Stack, ein bestimmtes Modell, eine bestimmte Toolchain, eine bestimmte Review-Disziplin und ein bestimmtes Team. Sie ist nützlich, solange sie regelmäßig gegen reale Läufe zurückgerechnet wird.

Beispiel: Watchdog Editorial OS

Als Plausibilitätsmodell lässt sich ein agentisches Editorial-System in drei Schichten schätzen: COSMIC für Datenbewegungen, Use Case Points für User Stories und Akteure, T-Shirt-Sizing für relative Roadmap-Größe. Die Token-Prognose bleibt danach eine eigene, lokale Kalibrierung.

Epic	COSMIC CFP	T-Shirt	Token-Forecast
Evidenz	11	L	130.000-170.000
Skeptiker	11	M	70.000-110.000
Audit	11	M	80.000-120.000
Dashboard	18	XL	220.000-340.000
Adapter	9	S	50.000-80.000
Phase 8-10	–	M	80.000-130.000
MVP gesamt	60	–	630.000-950.000

Der interne Kalibrierungsfaktor aus einem beobachteten Arbeitslauf liegt bei etwa 12.000 Tokens pro COSMIC Function Point bei mittlerem Schwierigkeitsgrad. Dieser Faktor ist ausdrücklich kein wissenschaftlicher Standard, sondern ein Startwert. Für Frontend- und Dashboard-Epics ist ein Zuschlag plausibel, weil Render-Output, Screenshot-QS und Korrekturschleifen zusätzlich Kontext erzeugen.

Das robuste Schätzmodell: Größe, Risiko, Kontext, Kontrolle

Ein brauchbares Schätzmodell für Agentic AI sollte nicht nur mit Story Points beginnen, sondern mit vier Fragen:

Erstens: Wie hoch ist der Task-Wert? Je höher der Wert eines gelösten Problems, desto eher rechtfertigen sich teure Agentenläufe, Multi-Agent-Architekturen und aufwendige Review-Schichten.

Zweitens: Wie hoch ist das Risiko? Ein SAR-Entwurf, eine Kundensperrung oder ein produktiver Code-Change braucht andere Gates als eine interne Zusammenfassung.

Drittens: Wie groß ist der Kontext? Kleine Aufgaben mit großem Repository-Kontext können teurer werden als große Aufgaben mit sauber begrenztem Input.

Viertens: Wie viel Kontrolle ist erforderlich? Tests, Evals, Review-Agenten, Human Review und Audit Logs sind kein Overhead. Sie sind der Preis der Produktionsfähigkeit.

Agentic FinOps wird zur Kontrollfunktion

FinOps übersetzt Cloud-Verbrauch in wirtschaftliche Verantwortung. Agentic AI braucht eine ähnliche Disziplin: Kosten pro Task, Kosten pro akzeptiertem Output, Retry-Rate, Cache-Hit-Rate, Tool-Call-Kosten, Eval-Kosten und Human-Review-Aufwand. Ohne diese Kennzahlen bleibt Agentic AI eine Blackbox mit Monatsrechnung.

Die wirksamsten Hebel sind selten spektakulär: bessere Acceptance Criteria, kleinere Kontextfenster, konsequentes Caching, klare Tool-Rechte, harte Abbruchbedingungen, risikobasierte Review-Pfade und laufende Eval-Suites. Genau dort treffen sich Scrum, Governance und Kostenkontrolle.

Fazit

Agentic AI wird nicht dadurch teuer, dass Tokens teuer sind. Sie wird teuer, weil unklare Arbeit in Schleifen gerät, weil Kontext ungefiltert wächst, weil Multi-Agent-Systeme vorschnell eingesetzt werden und weil Validierung erst nachträglich eingebaut wird.

Das Schätzmodell der nächsten Jahre wird deshalb kein besseres Story-Point-Schema sein. Es wird eine Kombination aus funktionaler Größe, Datenbewegungen, Use-Case-Komplexität, Task-Wert, Risikoklasse, Kontextbudget, Eval-Kosten, Retry-Wahrscheinlichkeit und Wartungsannahme. Wer Agentic AI produktiv einsetzen will, muss nicht nur fragen, ob ein Agent die Aufgabe lösen kann. Die wichtigere Frage lautet: Wie oft, mit welchem Kontrollaufwand und zu welchem Preis?

Quellen

• Anthropic Engineering: Multi-Agent Research System
• IFPUG: Function Point Analysis
• COSMIC: IFPUG Function Points oder COSMIC Function Points?
• Mountain Goat Software: Estimating With Use Case Points
• Teaching Agile: T-Shirt Sizing
• ArXiv 2601.14470: Tokenomics
• ArXiv 2604.22750: How Do AI Agents Spend Your Money
• Frontiers in Artificial Intelligence 2026: LLM-aware Software Effort Estimation
• Applied Sciences 2025: Large Language Models for Early-Stage Software Project Estimation
• METR: Time Horizon 1.1
• Watchdog-Dossier: Agentic AI