# Capstone: wenn mehrere Achsen gleichzeitig ziehen

> Integrative Entscheidungen, bei denen jede Verbesserung auf einer Achse eine andere verschlechtert: Architekturwahl, gefährliche Kombinationen, Kosten gegen Verlässlichkeit, Kontrolle gegen Durchsatz, Priorisierung im Vorfall — und wann keine Option trägt.

Track: [Agentic AI](https://physar.tech/learn/agentic-ai)  
Kanonische Fassung: https://physar.tech/learn/agentic-ai/agent-expert-capstone  
Stand: 2026-09-04  
Interaktiver Teil: 9 Checks (nur im Browser)

## Capstone: wenn mehrere Achsen gleichzeitig ziehen

### Was eine integrative Entscheidung ausmacht

In den vorangegangenen Modulen hatte jede Frage eine beste Antwort, weil jeweils eine Achse betrachtet wurde. Im Betrieb gibt es diesen Zustand nicht. Dort zieht jede Entscheidung an mehreren Achsen gleichzeitig, und die Verbesserung auf einer verschlechtert eine andere.

Der Unterschied ist nicht die Schwierigkeit, sondern die Form der Antwort. Eine Einzelachsen-Frage wird mit „so“ beantwortet. Eine integrative Frage wird mit „so, weil in diesem Fall diese Achse schwerer wiegt — und ab dieser Schwelle wäre es umgekehrt“ beantwortet. Ohne den zweiten Halbsatz ist es keine Entscheidung, sondern eine Vorliebe.

**Integrative Entscheidung:** Eine Entscheidung, bei der mindestens zwei Achsen gegenläufig ziehen, sodass jede Verbesserung auf der einen die andere verschlechtert. Sie ist erst vollständig, wenn neben der Wahl auch die **ausschlaggebende Achse** und eine **messbare Umkehrschwelle** benannt sind.

> **Merksatz:** Eine gute Architekturentscheidung nennt drei Dinge: die gewählte Option, die Achse, die den Ausschlag gab, und die **messbare Schwelle**, ab der sie neu zu treffen wäre.

### Die Achsen, die in diesem Track aufgespannt wurden

|  |  |
| --- | --- |
| Vorhersagbarkeit | Wie fest steht der Pfad? Sie entscheidet zwischen Workflow, Agent und Gerüst. |
| Wirkung | Was kann das System verändern, und was davon ist rückholbar? |
| Autorität | Mit wessen Rechten handelt es, und bis wohin reicht die Identität des Auslösers? |
| Kontext | Was steht dem Modell zur Verfügung, woher kommt es und wie lange bleibt es? |
| Aufwand | Runden, Tokens, Latenz und die Kapazität der angebundenen Systeme. |
| Verlässlichkeit | Wird die Wirkung geprüft, ist sie wiederholbar, kann der Lauf ehrlich scheitern? |
| Kontrolle | Kann ein Mensch rechtzeitig eingreifen, und ist die Entscheidung, die er trifft, tragfähig? |
| Nachweis | Bleibt genug übrig, um einen Wirkungsradius zu bestimmen und Rechenschaft abzulegen? |
| Sparsamkeit | Wie wenige Kopien wie kurz — und wie eng zugänglich? |

Neun Achsen sind zu viele, um sie in einer Besprechung gleichzeitig zu halten. Deshalb ist der praktische Zugang nicht, alle zu prüfen, sondern die **zwei bis drei** zu benennen, die im vorliegenden Fall gegeneinander ziehen — und die übrigen ausdrücklich als nicht betroffen zu erklären.

### Die Konflikte, die tatsächlich auftreten

|  |  |
| --- | --- |
| Wirkung gegen Kontext | Der Agent braucht private Daten und einen Ausgangskanal, liest aber fremde Inhalte. Sicherheit gegen Nutzen. |
| Verlässlichkeit gegen Aufwand | Jede Verifikation kostet eine Runde. Vollständige Prüfung gegen bezahlbare Läufe. |
| Nachweis gegen Sparsamkeit | Die vollständige Trajektorie macht Vorfälle beherrschbar und ist eine sensible Zweitkopie. |
| Kontrolle gegen Durchsatz | Jede Freigabe bremst — und zu viele Freigaben heben die Kontrolle auf, statt sie zu erhöhen. |
| Vorhersagbarkeit gegen Anpassungsfähigkeit | Ein Gerüst ist zuverlässig und bricht am Sonderfall. Ein Agent ist anpassungsfähig und unvorhersagbar. |

Die vierte Zeile hat eine Eigenschaft, die sie von den anderen unterscheidet: Sie ist nicht monoton. Mehr Freigaben bedeuten ab einer Menge **weniger** Kontrolle, nicht mehr — weil Aufmerksamkeit bei Häufigkeit zusammenbricht und sich das nicht wegtrainieren lässt. Wer diese Achse wie eine gewöhnliche Abwägung behandelt, optimiert in die falsche Richtung.

### Weder Kompromiss noch Rangordnung, sondern Schwellen

Für den Umgang mit solchen Konflikten gibt es zwei verbreitete und zwei brauchbare Verfahren. Die verbreiteten sind der Kompromiss — von jeder Achse etwas — und die feste Rangordnung: Sicherheit vor allem, immer.

|  |  |
| --- | --- |
| Kompromiss | Halbe Verifikation und halbe Sparsamkeit ergibt zwei Achsen, die beide nicht tragen. Bei Grenzen mit Sprungfunktion — Sicherheit, Löschbarkeit — gibt es kein Halb. |
| Feste Rangordnung | Klar und im Einzelfall regelmäßig falsch. Sie führt dazu, dass die nachrangige Achse gar nicht erst gemessen wird. |
| Schwellen | Eine Achse gewinnt, solange eine benannte Größe unter einem Wert liegt. Darüber gewinnt die andere. Die Entscheidung wird damit überprüfbar. |
| Zuschnitt ändern | Die Option, die in Besprechungen fehlt: Wenn keine Wahl trägt, ist möglicherweise die Aufgabe falsch geschnitten. |

Die dritte Zeile ist das Handwerkszeug dieses Moduls. Statt „wir prüfen jede Wirkung nach“ heißt es: „Wir prüfen jede Wirkung nach, deren Rücknahme mehr als zehn Minuten Handarbeit kostet — bei den übrigen genügt eine Stichprobe von fünf Prozent.“ Der zweite Satz ist umsetzbar, überprüfbar und bei geänderten Umständen korrigierbar.

Damit eine Schwelle wirkt, gehört sie in die Konfiguration und nicht in ein Protokoll. Aus „wir verifizieren risikobasiert“ wird dann ein Feld wie `verify_if_undo_minutes_gt: 10` neben einem `sample_rate: 0.05` für den Rest — ablesbar, änderbar und im Review sichtbar. Eine Schwelle, die nur in einem Besprechungsprotokoll steht, ist nach zwei Personalwechseln verschwunden.

### Konflikt: Sicherheit gegen Nutzen

### Der Agent, der lesen, wissen und melden soll

Ein Agent soll eingehende Kundentickets bearbeiten. Dafür braucht er die Ticketinhalte (fremder Inhalt), die Kundendatenbank (private Daten) und einen Webabruf, um öffentliche Fehlerdatenbanken zu prüfen (Ausgangskanal). Alle drei Anforderungen sind fachlich begründet und alle drei zusammen sind ein Exfiltrationspfad.

**Anforderungen**

- Kundendaten dürfen das System nicht über einen wählbaren Kanal verlassen
- Der Abgleich mit öffentlichen Fehlerdatenbanken bleibt möglich
- Die Lösung darf nicht an einer Erkennungsquote hängen

**Schritte**

- Erster Schritt: Die drei Anforderungen einzeln prüfen — jede für sich ist unproblematisch, nur die Kombination trägt das Risiko.
- Zweiter Schritt: Die Kombination auflösen, statt sie zu überwachen. Ein Filter wäre eine Wahrscheinlichkeitsaussage, kein Ausschluss.
- Dritter Schritt: In zwei Läufe trennen. Lauf A liest das Ticket und darf ins Netz, hat aber keinen Datenbankzugriff. Lauf B liest die Datenbank und hat keinen Netzzugang.
- Vierter Schritt: Die Übergabe zwischen beiden ist ein Auftragstext — und der ist von fremdem Inhalt beeinflusst. Er lenkt also die Aktionen von Lauf B.
- Fünfter Schritt: Deshalb bekommt Lauf B eine enge Positivliste erlaubter Aktionen und einen festen Rückkanal, statt frei zu handeln.
- Ergebnis benennen: Der Datenabfluss ist strukturell geschlossen. Die verbleibende Angriffsfläche ist auf eine benennbare Frage reduziert — welche Aktionen ein fremdbeeinflusster Auftrag auslösen darf.

**Merksatz:** Bei einer gefährlichen Kombination ist die Frage nicht, wie man sie überwacht, sondern welches Bein sich entfernen lässt. Was danach bleibt, ist kleiner und ausdrücklich benennbar — nicht null.

### Konflikt: Verlässlichkeit gegen Aufwand

Jede Verifikation kostet einen Leseaufruf und damit eine Runde. Bei neun Runden je Aufgabe und drei wirkenden Schritten sind das drei zusätzliche Runden — ein Drittel mehr Aufwand für eine Prüfung, die in 98 Prozent der Fälle bestätigt, was ohnehin stimmte.

Die falsche Auflösung ist der Verzicht mit der Begründung, die Quote sei ja gut. Die zweite falsche Auflösung ist die vollständige Prüfung mit der Begründung, Verlässlichkeit gehe vor. Beide behandeln alle Aktionen gleich, obwohl sich die Kosten eines unentdeckten Fehlers zwischen ihnen um Größenordnungen unterscheiden.

- **Immer verifizieren**, wo die Rücknahme teuer oder unmöglich ist — unabhängig von der Fehlerquote.
- **Immer verifizieren**, wo ein Fehlschlag still bleibt, also im Protokoll wie ein Erfolg aussieht.
- **Stichprobe genügt**, wo die Wirkung billig rücknehmbar ist und ein Fehler auffällt — die Quote dient dann der Überwachung, nicht dem Einzelfall.
- **Gar nicht**, wo die Aktion selbst schon eine Prüfung ist, etwa ein Lesevorgang.

> **Schwelle formulieren:** „Verifikation bei allen Aktionen mit einer Rücknahmedauer über zehn Minuten; Stichprobe von fünf Prozent bei den übrigen; monatliche Prüfung, ob die Stichprobenquote noch trägt.“ Das ist eine Entscheidung — „wir verifizieren risikobasiert“ ist keine.

Der zweite Teil dieser Staffelung wird oft vergessen: Eine Stichprobe ist nur dann eine Kontrolle, wenn ihr Ergebnis irgendwo auflaufen. Fünf Prozent geprüfte Aktionen ohne Auswertung sind fünf Prozent zusätzliche Aufrufe ohne Nutzen. Die Quote gehört als Kennzahl geführt, und eine Abweichung nach oben ist der Anlass, die Schwelle nachzuziehen — genau dafür ist sie eine Schwelle und keine Regel.

### Konflikt: Nachweis gegen Sparsamkeit

Dieser Konflikt ist der unangenehmste, weil beide Seiten aus derselben Pflichtenlage folgen können: Rechenschaft verlangt Aufzeichnung, Speicherbegrenzung verlangt kurze Fristen. Er lässt sich nicht gewichten, sondern nur **trennen**.

|  |  |
| --- | --- |
| Betriebsdaten ohne Personenbezug | Lange aufbewahren, breit zugänglich. Rundenzahlen, Latenzen, Abbruchgründe, Fehlerklassen. |
| Trajektorie in gekürzter Form | Mittlere Frist, für Entwicklung lesbar. Werkzeugnamen, Statusklassen, Grenzen — ohne Inhalte. |
| Trajektorie vollständig | Kurze Frist, enger Zugriff, Freigabe je Zugriff. Enthält Argumente und Rückgaben im Wortlaut. |
| Ausnahme im Vorfall | Befristete Verlängerung für markierte Läufe, mit dokumentiertem Grund und Ende. |

Die Trennung kostet zwei Pipelines und erzeugt eine neue Fehlerquelle: Ein Befund, der nach acht Wochen auffällt, trifft auf eine gekürzte Fassung, die nicht reicht. Diesen Fall wird es geben, und er ist der Preis. Ihn zu benennen ist ehrlicher, als eine lange Frist für alles zu wählen und die Sparsamkeit als erledigt zu betrachten.

### Konflikt: Kontrolle gegen Durchsatz

Diese Achse verhält sich anders als die übrigen, und das ist der wichtigste Einzelbefund dieses Moduls. Mehr menschliche Freigaben erhöhen die Kontrolle nur bis zu einer Menge; darüber sinkt sie wieder, weil Aufmerksamkeit bei Häufigkeit zusammenbricht — bei Fachleuten wie bei Laien, und ohne dass Training daran etwas ändert.

**Kurzcheck:** Ein Team diskutiert, ob es die Freigabepflicht von 30 auf 300 Aktionen pro Tag ausweiten soll, um mehr Kontrolle zu haben. Wie ordnest du den Vorschlag ein?

- [x] Er würde die Kontrolle senken — bei dieser Menge wird geprüft nicht mehr, sondern durchgewunken
- [ ] Er erhöht die Kontrolle und senkt den Durchsatz — eine normale Abwägung
- [ ] Er ist vertretbar, wenn die Freigaben auf mehrere Personen verteilt werden
- [ ] Er ist vertretbar, wenn die Entscheidungsvorlagen gleichzeitig verbessert werden

> Die Achse ist nicht monoton. Ab einer Menge ist die zusätzliche Freigabe keine Prüfung mehr, und die vorher wirksamen dreißig verlieren die Aufmerksamkeit gleich mit.

Die Auflösung liegt deshalb nicht auf dieser Achse, sondern auf einer anderen: Weniger Freigaben und dafür belastbare Laufzeitgrenzen. Die Kontrolle wandert von der Vorabprüfung in die Absicherung — das ist eine andere Art von Arbeit und keine Reduktion.

### Die Reihenfolge der Festlegungen

Nicht alle Achsen sind gleichzeitig entscheidbar. Einige Festlegungen schränken die übrigen ein, und wer sie spät trifft, macht frühere Entscheidungen ungültig.

**Vorhersagbarkeit — Workflow, Gerüst oder Agent; alles Weitere hängt daran** → Zuschnitt und Werkzeugmenge — daraus folgt, was überhaupt erreichbar ist → Wirkung und Autorität — Aktionsklassen, Identität, Least Privilege → Kontrolle und Verlässlichkeit — Freigaben, Verifikation, Grenzen → Nachweis und Sparsamkeit — was aufgezeichnet wird, wie lange, für wen

Der häufigste Reihenfolgefehler ist, mit Stufe vier zu beginnen: Ein Team diskutiert Freigabeprozesse für ein System, dessen Zuschnitt noch offen ist. Die Diskussion ist dann unauflösbar, weil die Aktionsklassen fehlen, über die man reden müsste — und sie wird oft mit „dann eben alles freigabepflichtig“ beendet.

Umgekehrt gilt: Wer die Reihenfolge einhält, bekommt viele spätere Entscheidungen geschenkt. Steht der Zuschnitt, ist die Werkzeugmenge klein; ist die Werkzeugmenge klein, sind die Aktionsklassen überschaubar; sind die Klassen überschaubar, ist die Freigabefrage in einer halben Stunde beantwortet. Die scheinbar langsame Reihenfolge ist die schnellere, weil sie keine Diskussion zweimal führt.

Eine Ausnahme gibt es: Wenn eine spätere Stufe eine frühere unmöglich macht, gehört sie vorgezogen. Stellt sich bei der Nachweisfrage heraus, dass ein Zielsystem keine Korrelationskennung annimmt, ist die Zurechnung nicht herstellbar — und das kann die Entscheidung über Wirkung und Autorität zwei Stufen weiter oben verändern. Solche Rückkopplungen sind selten und teuer genug, um früh nach ihnen zu fragen.

### Die Entscheidung so aufschreiben, dass sie prüfbar bleibt

Eine integrative Entscheidung ist erst dann fertig, wenn sie in einer Form vorliegt, die ein anderer in sechs Monaten prüfen kann. Vier Angaben genügen dafür.

- **Die Wahl** — knapp und ohne Begründungsprosa: was gebaut wird.
- **Die ausschlaggebende Achse** — welche der Größen den Ausschlag gab und warum in diesem Fall.
- **Die verworfenen Optionen** — mit dem Grund, an dem sie scheiterten. Ohne sie sieht jede Entscheidung alternativlos aus.
- **Die Umkehrschwelle** — die messbare Größe, ab der die Entscheidung neu zu treffen ist, samt der Stelle, an der sie beobachtet wird.

Die vierte Angabe ist die, die am häufigsten fehlt und den größten Unterschied macht. Ohne sie wird eine Entscheidung entweder nie hinterfragt oder bei der ersten Unzufriedenheit umgeworfen. Mit ihr gibt es einen Anlass, der von einer Zahl kommt statt von einer Stimmung.

In der Ablage sieht das unspektakulär aus: ein kurzes Dokument je Entscheidung mit den Feldern `entscheidung`, `achse`, `verworfen`, `umkehrschwelle` und `beobachtet_bei`. Das letzte Feld nennt die Stelle, an der die Schwelle tatsächlich gemessen wird — ein Dashboard, eine Kennzahl, ein wiederkehrender Bericht. Ohne diese Angabe ist die Umkehrschwelle eine Absichtserklärung, die niemand jemals prüft.

### Wenn keine Option trägt

Manche Konflikte lassen sich innerhalb der gestellten Aufgabe nicht auflösen. Dann ist die richtige Antwort nicht die am wenigsten schlechte Option, sondern der Hinweis, dass der Zuschnitt der Aufgabe das Problem ist.

Der Grund, warum diese Antwort so selten fällt, ist nicht fachlich, sondern situativ: Wer eine Aufgabe zugewiesen bekommen hat, sucht eine Lösung und keine Absage. Deshalb lohnt es, die Ausschlusskriterien vor Projektbeginn aufzuschreiben statt am Ende — dann ist der Verzicht eine Anwendung vereinbarter Regeln und nicht das Eingeständnis eines Scheiterns.

- **Der Agent braucht drei unvereinbare Fähigkeiten** — die Aufgabe gehört in zwei Läufe geteilt, auch wenn das die Bedienung umständlicher macht.
- **Jede Aktion ist unumkehrbar und keine kompensierbar** — dann ist Autonomie hier kein Entwurfsparameter, und die Aufgabe bleibt beim Menschen.
- **Es gibt kein Erfolgskriterium** — dann ist die fehlende Messbarkeit das Projekt, nicht der Agent.
- **Die Kosten sind bei jeder Variante höher als der Nutzen** — dann ist die ehrliche Empfehlung, es nicht zu bauen.

> **Merksatz:** „Nicht bauen“ ist eine vollwertige Architekturentscheidung. Sie braucht dieselbe Begründung und dieselbe Umkehrschwelle wie jede andere — und sie ist die einzige, die niemals nachträglich teuer wird.

### Was der Check prüft

- Ein Symptom der Achse zuordnen, auf der es tatsächlich liegt.
- Eine Architekturwahl treffen, wenn Vorhersagbarkeit und Anpassungsfähigkeit gegeneinander ziehen.
- Eine vollständige Agentenkonfiguration lesen und die Festlegung finden, die zwei Achsen gleichzeitig verletzt.
- Entscheiden, ob eine Aufgabe zerlegt gehört — und den Preis der Zerlegung benennen.
- Eine gefährliche Kombination auflösen, statt sie zu überwachen.
- Verifikation risikobasiert staffeln und die Schwelle beziffern.
- In einem Vorfall zwischen konkurrierenden Sofortmaßnahmen priorisieren.
- Erkennen, wann mehr Kontrolle weniger Kontrolle bedeutet.
- Benennen, wann keine der Optionen trägt und die Aufgabe neu zu schneiden ist.

Wer diese neun Entscheidungen mit einer benannten Achse und einer Umkehrschwelle begründen kann, hat den Track abgeschlossen — und die Fähigkeit, die er trainiert: nicht die beste Antwort zu kennen, sondern zu wissen, unter welchen Bedingungen sie es ist.

## Quellen

- Anthropic Engineering — Building Effective Agents — https://www.anthropic.com/engineering/building-effective-agents
- Anthropic Engineering — How we built our multi-agent research system — https://www.anthropic.com/engineering/multi-agent-research-system
- OWASP GenAI Security Project — LLM06:2025 Excessive Agency — https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
- Simon Willison — The lethal trifecta for AI agents — https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
- Parasuraman & Manzey — Complacency and Bias in Human Use of Automation: An Attentional Integration, Human Factors 52(3), 2010 — https://journals.sagepub.com/doi/10.1177/0018720810376055
- NIST — SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management — https://csrc.nist.gov/pubs/sp/800/61/r3/final