KI-Agenten-Preise: Was Kunden zahlen sollten

Inhaltsverzeichnis

Veröffentlicht im August 2026.

TL;DR: Bepreise einen KI-Agenten-Build nicht nach Stunden. Teile ihn in zwei Posten: eine feste Baugebühr für das ursprüngliche System und eine monatliche Wartungspauschale, damit es am Laufen bleibt. Die Baugebühr deckt Entwicklung, Tests und Integrationsarbeit ab. Die Pauschale existiert, weil Agenten kaputtgehen — Prompts driften, APIs ändern sich, Edge Cases tauchen auf — und „fertig” ist bei nichts, das ein Modell berührt, ein echter Zustand. Lässt du die Pauschale weg, leistest du innerhalb eines Monats kostenlosen Support.

[Sicht des Operators] Ich betreibe mehr als 30 Agenten in Produktion für eine Beratungsmarke und Pickleland, eine Pickleball-Anlage in Pflugerville, TX, und habe auf dieser Erfahrung aufbauend Agenten-Bauarbeit für Kunden bepreist. Der mit Abstand häufigste Fehler, den ich sehe — bei Freelancern wie bei Agenturen —, ist, einen KI-Agenten wie eine Website zu behandeln: anbieten, bauen, übergeben, Rechnung voll bezahlt. Agenten sind keine Websites. Es sind Systeme, die ständig Aufmerksamkeit brauchen, weil sich das, worauf sie aufbauen (ein Modell, eine API, der Workflow eines Kunden), ständig ändert. Bepreise diese Realität, oder du trägst die Kosten dafür selbst.

Warum Stundenabrechnung bei Agentenarbeit nicht funktioniert

Stundenabrechnung bestraft dich dafür, schneller zu werden. Je mehr Agenten-Builds du ausgeliefert hast, desto mehr wiederverwendbare Prompts, Evals und Grundgerüste sammelst du an — und desto schneller geht der nächste Build. Wenn du nach Stunden abrechnest, kürzt jeder Effizienzgewinn deine Rechnung. Das ist verkehrt.

Sie bestraft auch den Kunden — nur in die andere Richtung. Ein Kunde, der einen KI-Agenten in Auftrag gibt, kann nicht beurteilen, ob „12 Stunden” für einen Workflow fair, schnell oder aufgebläht sind. Er kauft eine Black Box, deren Preis auf einer Zahl beruht, die er nicht überprüfen kann. Diese Unsicherheit bringt Kunden dazu, den Preis zu drücken, die Freigabe zu verzögern oder das billigste Stundenangebot statt des besten zu wählen.

Die Lösung ist dieselbe, die bei jedem produktisierten Angebot funktioniert: nach definiertem Umfang und Ergebniswert bepreisen, nicht nach Zeit. Für Agentenarbeit bedeutet das konkret zwei getrennte Festpreis-Komponenten — denn ein Build und seine Instandhaltung sind tatsächlich zwei unterschiedliche Produkte mit unterschiedlichen Kostenstrukturen.

Die zweiteilige Struktur: Baugebühr plus Wartungspauschale

1. Baugebühr — ein einmaliger Festpreis für Konzeption, Bau, Test und Deployment des Agenten. Wird einmal bezahlt, meist in zwei Raten (Anzahlung zum Start, Restzahlung bei Lieferung).

2. Wartungspauschale — eine wiederkehrende monatliche Gebühr, die im Monat nach dem Launch beginnt. Sie deckt Monitoring, Prompt-Korrekturen bei Änderungen am Modell oder einer vorgelagerten API sowie kleine Anpassungen ab, die den Umfang nicht sprengen.

Beides in einer einzigen Zahl zu bündeln, ist der größte Preisfehler in dieser Nische. Ein Kunde, der nur einmal zahlt, hat keinen finanziellen Grund, nach der Lieferung noch etwas zu erwarten — und du hast keinen finanziellen Grund, einen Agenten weiter im Blick zu behalten, für den du vor einem Monat bezahlt wurdest. Die Trennung macht den Anreiz ehrlich: Du wirst dafür bezahlt, dass etwas funktioniert — also sorgst du dafür, dass es funktioniert.

Das spiegelt das Framework, mit dem ich entscheide, ob ich eine Automatisierung überhaupt baue — siehe KI-Agenten-ROI: Lohnt sich eine Automatisierung?. Dieser Beitrag ist aus Käufersicht geschrieben: wie ein Unternehmen bewerten sollte, ob sich ein Agent amortisiert. Dieser Beitrag hier ist die Verkäuferseite derselben Rechnung — die Baukosten und die Wartungssteuer aus jenem Framework sind genau die zwei Dinge, die du hier bepreist.

Die Baugebühr bemessen

Bemisst die Baugebühr nach Umfangsstufe, nicht durch Schätzen von Stunden. Drei Stufen decken die meisten Kundenprojekte ab:

Diese Spannen setzen eine klar definierte Umfangsgrenze voraus — dieselbe Disziplin, die ich in Produktisierte Dienstleistungen aufbauen beschreibe: eine schriftliche Liste dessen, was enthalten ist, eine schriftliche Liste dessen, was nicht enthalten ist, und eine feste Anzahl an Workflows oder Tool-Integrationen. Ein Kunde, der nach „einem KI-Agenten für mein Unternehmen” fragt, ohne einen definierten Workflow zu haben, ist noch nicht bereit für einen Build — er ist bereit für ein Scoping-Gespräch, ein eigenes, kleineres Deliverable (ich bepreise meins als Pauschal-Audit für $500–$1,000, das das Scope-Dokument liefert, gegen das die Baugebühr anschließend angeboten wird).

Innerhalb jeder Stufe bewegt sich die tatsächliche Zahl an drei Dingen: wie viele unterschiedliche Tools der Agent aufruft, wie viel des Testens gegen echte, unordentliche Kundendaten statt gegen saubere Testfälle laufen muss, und wie nachsichtig der Fehlermodus ist. Ein Agent, der einen Social-Post zur menschlichen Prüfung entwirft, darf gelegentlich zu geringen Kosten falsch liegen. Ein Agent, der eine Bestätigungs-E-Mail verschickt oder Geld bewegt, darf das nicht — und das verändert das Testbudget stärker als den Code.

Die Wartungspauschale bemessen

Ich lege die Pauschale als Prozentsatz der Baugebühr fest, nicht als feste Zahl, weil die Instandhaltungskosten mit der Systemkomplexität genauso skalieren wie die Baukosten.

maintenance_retainer_per_month = build_fee × monthly_rate

monthly_rate:
  stable integrations, low API-change risk        → 3–5%
  volatile APIs (social platforms, scraped data)   → 6–10%
  multi-agent systems, custom eval suite to keep up → 8–12%

Bei einem $6,000-Build mit mehreren Schritten auf einem einigermaßen stabilen Stack sind das etwa $250–$400 pro Monat. Diese Zahl sollte eng mit der Wartungssteuer, die ich auf meine eigenen Automatisierungen anwende zusammenhängen — pauschal 20% der Baukosten pro Jahr, was am unteren Ende auf dieselbe monatliche Spanne von 3–5% hinausläuft. Die kundenseitige Pauschale liegt in derselben Größenordnung, weil der zugrunde liegende Kostentreiber — Prompt-Drift, Änderungen an vorgelagerten APIs, Edge Cases, die nach dem Launch auftauchen — sich nicht ändert, nur weil jemand anderes dafür bezahlt.

Was die Pauschale ausdrücklich nicht abdeckt: neue Workflows, neue Integrationen oder Umfangsänderungen. Dafür gibt es neue Angebote für die Baugebühr. Eine Pauschale, die stillschweigend „kannst du ihn auch für diesen anderen Fall bauen” absorbiert, wird innerhalb eines Quartals zu unbezahlter Feature-Arbeit — derselbe Fehlermodus, den ich unter warum produktisierte Angebote eine harte Umfangsgrenze brauchen beschreibe, hier angewandt auf laufende Arbeit statt auf den ursprünglichen Build.

Den Preis an dem verankern, was er ersetzt — nicht daran, was der Bau kostet

Die Baugebühr sollte dem Kunden gegenüber nicht mit deinen Stunden begründet werden — sondern mit den manuellen Kosten, die sie beseitigt. Führe vor dem Angebot dieselbe Manualkosten-Berechnung aus dem ROI-Framework für die Kundenseite durch:

manual_cost_per_year = time_per_instance × hourly_rate × frequency_per_year
                      + error_cost_per_year

Wenn das Team eines Kunden 5 Stunden pro Woche für eine Aufgabe aufwendet, die ein Agent übernehmen kann, ergibt das bei $40/Stunde voll beladen $10,400/Jahr an manuellen Kosten. Eine Baugebühr von $6,000 mit einer Pauschale von $300/Monat ($3,600/Jahr) amortisiert sich in deutlich unter einem Jahr und zahlt sich danach jedes Jahr weiter aus. Dieser Vergleich — manuelle Kosten gegen Bau-plus-Pauschale-Kosten — ist der eigentliche Pitch. Führe ihn in jedem Angebot an erster Stelle an. Ein Preis ohne Vergleichspunkt ist nur eine Zahl; ein Preis neben dem, was er ersetzt, ist ein Argument.

Das setzt auch eine natürliche Obergrenze: Wenn die ersetzten manuellen Kosten klein sind, sollte der Kunde kein $15,000-Multi-Agenten-System kaufen — und du solltest ihm keins verkaufen. Die Stufe an die tatsächlich verdrängten Kosten anzupassen, ist es, was die Preisgestaltung in beide Richtungen ehrlich hält.

Vertragsklauseln, die Scope Creep verhindern

Vier Klauseln stehen neben dem Preis in jedem Agenten-Build-Vertrag, den ich aufsetze:

1. Eine schriftliche Definition von „fertig”. Konkrete Testfälle, die der Agent bestehen muss, bevor die Schlusszahlung fällig wird — nicht „funktioniert gut”, sondern eine Liste: „klassifiziert 9 von 10 Beispiel-Leads aus dem bereitgestellten Datensatz korrekt”, „postet erfolgreich auf der verbundenen Facebook-Seite, ohne dass manuell eingegriffen werden muss”. Mehrdeutige Abnahmekriterien sind mit Abstand die häufigste Quelle unbezahlter Zusatzarbeit.
2. Eigentumsrechte, klar benannt. Der Kunde besitzt die Workflow-Logik und alle kundenspezifischen Daten. Du behältst wiederverwendbare Grundgerüste, Prompt-Vorlagen und Eval-Harnesses, die nicht spezifisch für sein Geschäft sind — derselbe Punkt zur IP-Wiederverwendung, den ich in Liefersystemen für produktisierte Dienstleistungen behandle. Sprich das von Anfang an offen an; das erspart später ein unangenehmes Gespräch.
3. Eine definierte Übergabe bei Kündigung der Pauschale. Wenn der Kunde die Wartung kündigt, lege klar fest, was passiert: Der Agent läuft unverändert weiter, ohne weitere Korrekturen, oder er wird nach einer Ankündigungsfrist deaktiviert. Lässt du das offen, bleibst du für ein System verantwortlich, für dessen Beobachtung dich niemand bezahlt.
4. Änderungswünsche werden separat, schriftlich und vor Arbeitsbeginn bepreist. Nicht „das klären wir dann” — sondern ein Satz oder ein Mindestpreis pro Anfrage, im Vertrag festgehalten, damit eine Umfangsänderung nicht jedes Mal eine neue Verhandlung wird.

Die zwei Einwände, die jedes Mal kommen

„Warum kostet es extra, etwas zu warten, das bereits funktioniert?” Weil „funktioniert” eine Momentaufnahme ist, kein Zustand. Der Modellanbieter kann das Verhalten eines Modells ändern oder es einstellen, die Plattform, auf der der Agent postet, kann ihre API ändern, und das Geschäft des Kunden selbst kann den Workflow ändern, um den herum der Agent gebaut wurde. Nichts davon ist ein Bug in dem, was du geliefert hast — es ist die normale Verfallsrate jedes Systems, das mit externen, sich bewegenden Teilen verbunden ist. Ich stelle die Pauschale ausdrücklich als Versicherung gegen diesen Verfall dar, nicht als laufenden „Support” — Support impliziert, dass etwas kaputt ist; eine Pauschale bedeutet, dass jemand hinschaut, bevor es so weit kommt.

„Kann ich nicht einfach ein No-Code-Tool nutzen und die Baugebühr ganz überspringen?” Manchmal ja — und das sage ich dann auch. Wenn der Workflow wirklich einfach ist (ein einziger Trigger, eine Aktion, keine individuelle Logik), ist eine No-Code-Automatisierungsplattform die ehrliche Antwort, und ich verweise einen Kunden lieber darauf, als einen Build anzubieten. Die Baugebühr ist gerechtfertigt, wenn echte Logik, Integrationsarbeit oder Urteilsvermögen im Spiel sind, die ein Drag-and-Drop-Tool nicht abbilden kann. Genau das Ablehnen unpassender Aufträge ist es, was die Aufträge, die ich annehme, glaubwürdig macht.

Die Tools, mit denen ich das betreibe

Notion — hier lebt das Scope-Dokument: was enthalten ist, was nicht, die Liste der Abnahmetests und die Eigentumsklauseln, geteilt mit dem Kunden, bevor irgendeine Anzahlung eingesammelt wird.

Airtable — eine Zeile pro aktivem Auftrag, mit Build-Status, Abrechnungsdatum der Pauschale und dem letzten Zeitpunkt, zu dem die Ausgabe jedes Agenten stichprobenartig geprüft wurde.

Claude ist die Grundlage, auf der ich die meisten dieser Agenten baue — die Pauschalpreise oben setzen einen Modell-Stack mit einigermaßen stabilen Preisen und stabilem Verhalten voraus, was die Volatilitätsannahme in der Monatssatz-Formel verändert, wenn du bei einem weniger stabilen Anbieter bist.

FAQ

Sollte die Anzahlung 50% betragen oder etwas anderes?

50% zum Start, 50% bei Lieferung gegen die schriftlichen Abnahmekriterien ist die einfachste Struktur und die, die ich standardmäßig verwende. Bei größeren Multi-Agenten-Builds (der $15,000+-Stufe) teile ich in drei auf: Anzahlung, eine Meilensteinzahlung bei einem funktionierenden Prototyp und die Restzahlung bei Lieferung — vor allem, um zu vermeiden, dass eine große Schlussrechnung bei einem Kunden landet, der mitten im Projekt verstummt ist.

Was, wenn der Kunde nur für die Wartung bezahlen will, ohne dass ich den ursprünglichen Agenten gebaut habe?

Ich übernehme solche Aufträge, bepreise aber den ersten Monat höher, um ein Audit abzudecken: die vorhandenen Prompts und den Code lesen, die Abnahmetests durchführen, die ich selbst geschrieben hätte, und dokumentieren, was ich finde. Man kann sich nicht verantwortungsvoll auf eine Wartungspauschale für ein System festlegen, das man nicht gebaut und nicht überprüft hat — der Audit-Monat ist es, der aus einem Unbekannten eine echte Zahl macht.

Woran erkenne ich, ob meine Monatssatz-Annahme (3–12%) zu niedrig ist?

Erfasse ein Quartal lang die tatsächlichen Wartungsstunden gegen das, was die Pauschale abgedeckt hat. Wenn du konsequent mehr Zeit aufwendest, als die Pauschale deckt, erhöhe den Satz bei der Verlängerung — absorbiere es nicht stillschweigend. Die Formel ist ein Ausgangspunkt, kalibriert nach derselben Wartungssteuer-Logik, die ich für meine eigenen Agenten verwende; deine tatsächliche Häufigkeit von API-Änderungen und die Toleranz des Kunden für Edge Cases werden sie verschieben.

Brauche ich einen eigenen Vertrag für das Scoping-Gespräch?

Für alles über ein kurzes Gespräch hinaus: ja — bepreise das Scoping-Audit als eigenes kleines Deliverable mit eigenem schriftlichem Ergebnis (dem Scope-Dokument), selbst wenn du vorhast, die Kosten dafür auf die Baugebühr anzurechnen, falls der Kunde weitermacht. So wird die Scoping-Phase selbst nicht zu unbezahlter Vertriebsarbeit.

Nächste Schritte: Mein AI Agents for Beginners-Kurs behandelt den Bau der Agenten, die dieses Preis-Framework als bereits lieferbar voraussetzt. Das Cowork-Programm ist für Operatoren, die eine strukturierte Umgebung wollen, um diese Art von Arbeit zu bauen und zu bepreisen. Wenn du lieber zuerst das Audit und das Scope-Dokument für dich erstellen lassen möchtest, buche eine 30-minütige Session.