Cost Engineering ist in agentischen Systemen kein „FinOps später“, sondern Teil der Architektur. Im Exam kommt das oft als Szenario: Ein Agent soll zuverlässig liefern, aber du hast Budget-, Latenz- und Risiko-Grenzen. Deine Aufgabe ist dann, Kosten aktiv zu steuern, ohne Qualität und Sicherheit zu verlieren.
Denke in Budgets pro Ausführung (Run) und pro Phase (Planung, Tool-Calls, Auswertung, Antwort). Lege harte Grenzen fest, bevor du optimierst: z.B. „max 12k Input Tokens, max 1.5k Output Tokens“ oder „max 3 Tool-Calls“. Der Trick ist nicht, immer weniger Tokens zu verbrauchen, sondern Tokens dort einzusetzen, wo sie den größten Qualitätshebel haben (z.B. bei der Problemstrukturierung oder Validierung).
Praktisch: Nutze kurze, wiederverwendbare Prompts (Templates), kompakte Kontext-Extrakte statt Rohdaten, und „progressive disclosure“: erst grob entscheiden, dann nur bei Bedarf tiefer. Ein typisches Muster: 1) kurze Triage (kleines Modell), 2) nur bei komplexen Fällen Eskalation, 3) am Ende knappe Zusammenfassung.
Model Tiering bedeutet: Du definierst mehrere Modellklassen (z.B. günstig/schnell, stark/teuer) und klare Routing-Regeln. Diese Regeln hängen meist an drei Signalen:
Ein exam-taugliches Routing-Design ist explizit und prüfbar: „Standardfälle laufen auf Tier A. Wenn (a) Kontext > X, (b) Validierung fehlschlägt, oder (c) Aktion extern wirkt, dann eskalieren zu Tier B.“ Wichtig: Tiering ist nicht nur Modellwahl, sondern auch Strategy Tiering (z.B. mit/ohne Web-Tools, mit/ohne extra Validierungsschritt).
Guardrails schützen nicht nur vor Schaden, sie schützen auch dein Budget. Beispiele:
Exam-Perspektive: Beschreibe trade-offs sauber. Mehr Validierung kostet Tokens, reduziert aber Fehlversuche (die oft teurer sind). Ein guter Architekt wählt den Sweet Spot: „cheap checks first, expensive reasoning only when warranted“.
1. Kostensteuerung ist Architektur: Budgets, Limits und Stop-Conditions gehören ins Design.
2. Model Tiering braucht klare Routing-Regeln nach Komplexität, Risiko und Unsicherheit.
3. Guardrails sparen Geld, weil sie Schleifen, unnötige Tool-Calls und Fehlversuche verhindern.
Du betreibst einen Support-Agenten mit Tool-Zugriff (Ticket-DB, E-Mail-Versand). Budget und Latenz sind knapp, aber Fehl-E-Mails sind kritisch. Skizziere ein Model-Tiering- und Guardrail-Design, das Kosten minimiert und riskante Aktionen absichert.
Nutze ein günstiges Modell für Triage und Datenabruf, eskaliere auf ein stärkeres Modell nur bei unklaren Fällen oder vor externen Side Effects. Baue Guardrails ein: harte Token- und Tool-Call-Limits, Validierungsschritt vor dem Senden, sowie „Send E-Mail nur nach explizitem Approval“. Caching und idempotente Tool-Calls reduzieren Wiederholungen und damit Kosten.