So schreibst du ein Scope-Dokument für KI-Agenten

Veröffentlicht im August 2026.

TL;DR: Ein Scope-Dokument macht aus „Ich will einen KI-Agenten für mein Unternehmen“ eine Zahl, die du anbieten kannst, und die ein Kunde absegnen kann. Es braucht sechs Teile: den Auslöser, die Eingaben, die Ausgaben, die Tools, mit denen der Agent arbeitet, was explizit ausgeschlossen ist, und eine schriftliche Liste von Abnahmetests. Schreib es, bevor du eine Baugebühr anbietest, nicht danach. Ich berechne es als pauschales Audit-Deliverable von 500–1.000 $, getrennt vom eigentlichen Build.

[Sicht des Operators] Ich betreibe über 30 produktive Agenten quer über eine Consulting-Marke und Pickleland, eine Pickleball-Anlage in Pflugerville, TX, und habe darüber hinaus Agenten-Builds für Kunden gescopt. Der mit Abstand häufigste Grund, warum ein Agenten-Projekt schiefläuft, ist nicht der Code — sondern dass niemand aufgeschrieben hat, was „fertig“ bedeutet, bevor die Rechnung rausging. Ein Scope-Dokument löst das in einer einzigen Sitzung. Es ist das unglamouröseste Deliverable, das ich produziere, und dasjenige, das die meisten Streitigkeiten vermeidet.

Inhaltsverzeichnis

Warum ein Scope-Dokument, keine Angebots-E-Mail

Eine Angebots-E-Mail beschreibt, was du tun wirst. Ein Scope-Dokument definiert, wie „fertig“ aussieht — konkret genug, dass du und der Kunde es beide mit dem fertigen Agenten abgleichen und ohne weiteres Gespräch einig werden könnt, ob er bestanden hat.

Dieser Unterschied ist wichtig, weil KI-Agenten-Pricing nur funktioniert, wenn die Baugebühr an etwas Festes gebunden ist. Bietest du einen Festpreis für einen undefinierten Scope an, hast du eine Zahl versprochen, die du gar nicht liefern kannst — das mentale Modell des Kunden von „ein KI-Agent für mein Unternehmen“ wächst so lange kostenlos weiter, bis du widersprichst, und Widerspruch nach der Anzahlung ist ein deutlich unangenehmeres Gespräch als die Grenze vorher zu ziehen.

Ich schreibe für jeden Build eines, auch für kleine. Ein Agent mit einem einzigen Workflow bekommt eine halbe Seite. Ein Multi-Agenten-System bekommt das vollständige Dokument. Das Format ändert sich nicht — nur die Länge.

Die sechs Dinge, die ein Scope-Dokument braucht

1. Der Auslöser. Was den Agenten anlaufen lässt — eine Formulareingabe, ein geplanter Zeitpunkt, eine eingehende E-Mail, ein Webhook aus einem anderen Tool. Benenne den genauen Auslöser, nicht eine Kategorie von Auslösern. „Läuft, wenn ein Lead-Formular abgeschickt wird“ ist Scope. „Verarbeitet eingehende Leads“ ist es nicht.

2. Die Eingaben. Welche Daten der Agent erhält und woher sie kommen. Liste die Felder auf, nicht nur die Quelle — „Name, E-Mail, Unternehmensgröße und das Freitextfeld aus der Typeform-Einreichung“, nicht „die Formulardaten“.

3. Die Ausgaben. Was der Agent produziert und wohin es geht. Gleiche Regel: benenne das Ziel und das Format. „Postet einen Antwortentwurf im #leads-Slack-Kanal zur menschlichen Freigabe“ ist Scope. „Antwortet Leads“ ist es nicht.

4. Die Tools und Integrationen, mit denen er arbeitet. Jede API, Datenbank oder Plattform, die der Agent aufruft. Hier hältst du auch fest, was du explizit nicht integrierst — ein Kunde, der annimmt, sein CRM sei inbegriffen, weil er es einmal beiläufig im Discovery-Call erwähnt hat, ist die häufigste Quelle von Scope Creep, die ich gesehen habe.

5. Was ausgeschlossen ist. Eine kurze, explizite Liste von Dingen, die der Agent nicht tun wird, auch wenn sie naheliegend klingen. Baust du einen Lead-Klassifizierungs-Agenten, schreib „versendet keine ausgehenden Nachrichten“ auf, selbst wenn das offensichtlich erscheint — was dir offensichtlich ist, ist es nicht einem Kunden, der noch nie Software gescopt hat.

6. Die Liste der Abnahmetests. Die tatsächliche Liste an Fällen, die der fertige Agent bestehen muss, bevor die Schlusszahlung fällig ist. Nicht „funktioniert gut“ — sondern konkrete, überprüfbare Fälle: „klassifiziert 9 von 10 Beispiel-Leads aus dem bereitgestellten Datensatz korrekt“, „postet erfolgreich in den verbundenen Slack-Kanal ohne manuellen Eingriff“, „verarbeitet eine fehlerhafte Einreichung (fehlendes E-Mail-Feld), ohne abzustürzen“. Das ist der mit Abstand wichtigste Abschnitt im Dokument, weil es der einzige ist, auf den sich beide Seiten später berufen können, ohne neu zu verhandeln, was gemeint war.

Die Vorlage

Das ist die tatsächliche Struktur, die ich verwende. Kopiere sie, fülle die sechs Abschnitte aus, und du hast ein Dokument, an das du einen Preis knüpfen kannst.

AGENT SCOPE DOCUMENT — [Client name] / [Project name]
Date: [date]

1. TRIGGER
   [What starts this agent running]

2. INPUTS
   [Exact data fields and their source]

3. OUTPUTS
   [What the agent produces, in what format, sent where]

4. TOOLS & INTEGRATIONS
   Included: [every API/platform/database touched]
   Explicitly excluded: [anything adjacent that is NOT built]

5. EXCLUSIONS
   [What this agent will not do, even if related]

6. ACCEPTANCE TESTS
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   [ ] [Specific, checkable test case]
   ...

BUILD FEE: $[amount], due [payment terms]
MAINTENANCE RETAINER: $[amount]/month, starting [date]
CHANGE REQUESTS: priced separately, quoted before work starts

Signed: _______________  Date: _______

Die Zeilen für Baugebühr und Retainer existieren, damit der Preis direkt an den Scope darüber gebunden ist — sieh dir an, wie ich beide Zahlen bemesse, falls du noch nie einen Build bepreist hast. Ein Kunde, der dieses Dokument unterschreibt, segnet Scope und Preis in derselben Bewegung ab — das ist der Punkt.

Wie ich das Gespräch führe, das dieses Dokument hervorbringt

Ich berechne die Scoping-Session selbst als pauschales Audit von 500–1.000 $, getrennt von der Baugebühr — nie darin eingerechnet, auch wenn der Kunde weitermacht. Zwei Gründe: Es verhindert, dass die Scoping-Phase zu unbezahlter Vertriebsarbeit wird, und es sorgt dafür, dass der Kunde das Gespräch ernst nimmt, statt es als kostenlose Beratung zu behandeln.

Das Gespräch selbst dauert 30–45 Minuten und ist der Reihe nach um die sechs Abschnitte oben herum strukturiert. Ich lasse die Unterhaltung nicht abschweifen in „was ein KI-Agent theoretisch für dein Unternehmen tun könnte“ — das ist ein anderes, teureres Gespräch, und es ist genau das, aus dem Dokumente entstehen, die niemand bepreisen kann. Ich frage zuerst nach dem Auslöser, denn ein Kunde, der nicht benennen kann, was den Prozess startet, hat meist noch keinen stabilen genug Workflow, um ihn zu automatisieren — und das lohnt sich herauszufinden, bevor einer von euch beiden sich auf einen Build festlegt.

Den Prompt liefern, nicht die leere Seite

Ich schreibe den ersten Entwurf des Dokuments nicht von Hand. Ich nehme meine Gesprächsnotizen — oft nur ein unordentlicher Absatz mit Stichpunkten — und füge das hier in Claude ein:

Here are my raw notes from a scoping call for an AI agent build. Turn them
into a scope document with exactly these six sections: Trigger, Inputs,
Outputs, Tools & Integrations, Exclusions, Acceptance Tests. For each
section, flag anything the notes don't specify clearly enough to build
against, rather than guessing or filling the gap yourself. The acceptance
tests need to be specific and checkable — reject vague criteria like
"works correctly" and either sharpen them into a concrete test case or
flag them for me to clarify with the client.

[paste raw notes]

Diese letzte Anweisung — Lücken markieren statt sie zu füllen — ist der Teil, der zählt. Ein Modell erfindet bereitwillig einen plausibel klingenden Abnahmetest, um das Dokument zu vervollständigen, und ein plausibel klingender Test, der nicht dem entspricht, was der Kunde tatsächlich meinte, ist schlimmer als eine Lücke, nach der du nachfragen musst.

Häufige Fehler, die ich immer noch sehe

Den Ausschluss-Abschnitt zuletzt schreiben oder ganz weglassen. Der Ausschluss-Abschnitt ist derjenige, den die meisten als optional behandeln. Er ist derjenige, der die meisten Streitigkeiten verhindert. Schreib ihn vor den Abnahmetests, nicht danach.

Abnahmetests, die Verhalten statt Ergebnisse beschreiben. „Der Agent soll den Ton des Kunden verstehen“ ist Verhalten. „Der Antwortentwurf des Agenten wird in 7 von 10 Beispielfällen ohne Änderungen freigegeben“ ist ein Ergebnis. Nur Ergebnisse sind überprüfbar.

Scoping aus einem einzigen Gespräch ohne schriftliche Notizen. Ist das Scope-Dokument der erste schriftliche Artefakt des Projekts, rekonstruierst du das Gespräch Tage später aus dem Gedächtnis. Mach dir während des Gesprächs Notizen, in der Reihenfolge der sechs Abschnitte, und das Dokument schreibt sich fast von selbst.

Den Kunden den Scope schreiben lassen. Wenn ein Kunde beschreibt, was er will, in seinen eigenen Worten, ist das Input für das Dokument, nicht das Dokument selbst. Seine Sprache ist meist feature-förmig („Ich will, dass er meine Leads bearbeitet“), nicht test-förmig. Das in überprüfbare Abnahmekriterien zu übersetzen, ist der eigentliche Wert der Scoping-Session — deshalb ist sie ein bezahltes Deliverable und kein Formular, das der Kunde selbst ausfüllt.

Die Tools, die ich dafür nutze

Claude entwirft das Dokument aus rohen Gesprächsnotizen mit dem obigen Prompt und markiert Lücken, statt zu raten.

Notion ist der Ort, an dem das fertige Scope-Dokument liegt, geteilt mit dem Kunden, bevor irgendeine Anzahlung eingezogen wird — derselbe Ort, an dem ich den Rest der Papierspur des Projekts aufbewahre.

Airtable verfolgt, welche Projekte sich im Scoping, im signierten oder im Build-Status befinden, eine Zeile pro Kunde, sodass ein Scope-Dokument nie wochenlang unsigniert liegen bleibt, ohne dass es jemand bemerkt.

FAQ

Wie lang sollte ein Scope-Dokument sein?

So lang, wie es nötig ist, um jeden Abnahmetest überprüfbar zu machen, und nicht länger. Ein Agent mit einem einzigen Workflow kann eine halbe Seite sein. Ein Multi-Agenten-System mit mehreren Integrationen kann zwei oder drei Seiten füllen. Länge ist nicht das Ziel — das Ziel ist, dass ein Kunde und ein Entwickler die Abnahmetests unabhängig voneinander lesen und sich einig sind, ob sie bestanden wurden.

Was, wenn der Kunde den Scope nach der Unterschrift ändern will?

Das ist eine Change Request, separat bepreist und angeboten, bevor die Arbeit beginnt — schreib diese Bedingung direkt ins Dokument, wie in der Vorlage oben. Ein Scope-Dokument, das nach der Unterschrift stillschweigend erweitert werden kann, ist eigentlich kein Scope-Dokument.

Brauche ich ein Scope-Dokument auch für sehr kleine Automatisierungen?

Ja, nur ein kurzes. Der Wert liegt nicht in der Länge — sondern darin, eine schriftliche Liste von Abnahmetests zu haben, bevor du mit dem Bauen anfängst, damit „fertig“ eine Checkliste ist und kein Gefühl. Ich hatte schon kleine, informell gescopte Jobs, die länger dauerten als große, sauber gescopte — genau aus diesem Grund.

Wem gehört das Scope-Dokument selbst — ist es Teil des Deliverables?

Ich behandle es als Eigentum des Kunden, unabhängig davon, ob er zu einem Build übergeht, da er für das Audit bezahlt hat, das es hervorgebracht hat. Was ich behalte, ist die zugrunde liegende Vorlage und der Prompt, genauso wie ich wiederverwendbares Gerüst über Projekte hinweg behalte — die Struktur des Dokuments gehört mir, der ausgefüllte Inhalt über ihr konkretes Unternehmen gehört ihnen.

Nächste Schritte: Mein Kurs „AI Agents for Beginners“ behandelt den Bau der Agenten, die ein Scope-Dokument wie dieses beschreibt. Das Cowork-Programm ist für Operator, die eine strukturierte Umgebung suchen, um genau diese Art von Scoping und Bauen zu üben. Wenn du das Scope-Dokument lieber für dich schreiben lassen willst, buch eine 30-minütige Session.