Agentik braucht Struktur, nicht mehr Prompt-Zauber (KW 37, 8.–14.9.2025)

Diese Woche schiebt sich ein Thema in den Vordergrund: Agentische Softwareentwicklung wird konkret – und mit ihr die Frage, wie wir Nicht‑Determinismus produktiv einhegen, ohne ihn totzuadministrieren. Wo liegt der Sweet Spot zwischen Struktur und Geschwindigkeit?

Agentik braucht Struktur, nicht mehr Prompt-Zauber

Das Konzept „Structured Agentic Software Engineering“ verpasst dem Agenten‑Hype einen entwaffnend nüchternen Rahmen. Das SASE‑Paper legt eine Dualität nahe: Software Engineering für Menschen (Intent, Strategie, Mentoring) wird sauber getrennt von Software Engineering für Agenten (planbare, beobachtbare Ausführung). An die Stelle von ad‑hoc‑Prompts treten versionierte Artefakte: BriefingScript (Ziel und Mission), LoopScript (Arbeitsablauf) und MentorScript (Teamnormen als Code). Auf Agentenseite entstehen Consultation‑ und Merge‑Readiness‑Päckchen mit Evidenz für Funktion, Tests, Hygiene und Rationale. Die Qualitätslatte wandert von „Tests grün“ zu „Merge‑fähig mit Nachweis“ – oder, wie die Autor:innen trocken festhalten: „passing tests is far from sufficient.“

Das ist weniger Bürokratie als es klingt. Wer schon heute Feature‑Branches mit Checklisten, Teststrategie und Architekturnotizen pflegt, bekommt hier die agententaugliche Fortsetzung – inklusive klarer Trennung von ACE (Agent Command Environment für Menschen) und AEE (Agent Execution Environment für Agenten). Praktisch heißt das: Wir coachen, orchestrieren und auditieren, während Agenten parallelisieren, ausharren und maschinenlesbares Feedback liefern. Rollen verschieben sich – weg vom eigenen Tippen hin zu Spezifikation, Evidenzprüfung und Mentoring. Für deutsche Organisationen, die gern „Prozesse“ sagen, ohne sie zu leben, ist das eine erfrischende Zumutung: Artefakte ermöglichen erst Tempo.

Tools als Vertrag zwischen Maschine und Modell

Wenn Agenten arbeiten sollen, brauchen sie präzise Werkzeuge. Anthropic formuliert das als nüchterne Leitlinie: „Agents are only as effective as the tools we give them.“ Tools sind Verträge zwischen deterministischen Systemen und nicht‑deterministischen Agenten. Das beginnt bei Beschreibungen wie Onboarding‑Guides (klare Parameter, Beispiele, Erwartungen) und reicht bis zu tokenbewussten Antworten, sinnvollen Namespaces und paginierten, semantisch beschrifteten Ergebnissen. Weniger API‑Wrapper, mehr bewusste, hochwirksame Tools. Tooling für intelligente Maschinen, statt deterministische Prozessroboter.

Wichtig ist der Realitätsabgleich. Wir sollten nicht nicht nur Accuracy evaluieren, sondern Laufzeit, Anzahl Tool‑Calls, Tokenkosten und Fehlertypen. Warum nicht Agenten Transkripte ihrer Fehlversuche selbst analysieren und ihre Tools eigenständig verbessern lassen – mit Tests gegen Überanpassung? Das ist MLOps (Machine Learning Operations) im Kleinformat für Agenten: klare Verträge, Messgrößen, Iteration. Und es beantwortet eine wiederkehrende Sorge von Software Engineers: Ja, der Nicht‑Determinismus bleibt – aber er wird durch bessere Werkzeuge und Metriken viel berechenbarer.

RAG debuggen wie einen Build: schnell, sichtbar, reproduzierbar

Retrieval Augmented Generation scheitert selten an Halluzinationen, sondern meist am Retrieval. „raggy“ zeigt als Tool, wie wir RAG‑Pipelines interaktiv debuggen: Chunk‑Größen, Overlaps, k‑Werte, Re‑Ranking oder Prompts live variieren, Zwischenergebnisse visualisieren, What‑if‑Analysen ohne Re‑Indexieren ausführen. Der Trick: vorindizierte Varianten und Prozess‑Checkpoints. In einer Studie hätten 71,3 Prozent der beobachteten Retrieval‑Änderungen klassisch ein zeitintensives Re‑Indexing erfordert – hier geht es per Dropdown.

Organisatorisch ist das Gold wert, weil Fachexpertise früh eingebunden wird. Wenn Fachbereich und Architektur gemeinsam auf Chunk‑Auswahl und Score‑Verteilungen schauen, werden Ursachen greifbar statt mystisch. Praktisch empfehlen sich zwei Betriebsarten: eine schnelle „Werkbank“ mit vorindizierten Varianten für Entwicklung und Diagnose, daneben eine schlanke Produktionslinie mit genau einer, gut gemessenen Konfiguration. So vermeiden wir die bekannte Falle, in der Projektbeteiligte „noch kurz“ am Retriever drehen.

Pragmatismus im CRM: SQL als Exoskelett fürs LLM

Wie sieht agentische Arbeit im Bestand aus? Ein INNOQ‑Beitrag von meinem Kollegen Hermann Schmidt zeigt es für Salesforce: Das LLM holt Daten via SOQL, lädt Resultate in eine dialoggebundene In‑Memory‑Datenbank (DuckDB) und erledigt Aggregationen, Joins und mehrstufige Recherchen deterministisch per SQL. Das entlastet das Kontextfenster, erhöht Reproduzierbarkeit und gibt uns ein Audit‑Trail: SOQL‑ und SQL‑Transkripte sind prüfbar, Fehlermeldungen werden zur Feedback‑Schleife.

Der Trade‑off ist klar: längere Antwortzeiten, dafür weniger Black‑Box‑Magie. Kosten fallen dort an, wo sie planbar sind – Rechenzeit für Queries statt Tokens für endlose „Gedankenketten“ im Latent Space. Für Governance ist das attraktiv: Wir sehen, welche Daten genutzt, welche Schritte gegangen wurden, und können Risiken (z. B. Datenzugriff) begrenzen. Die Art von unglamouröser Architektur, die in deutschen Unternehmen tatsächlich skaliert.

Belege aus der Wildnis: Multi-Agenten und Dauerläufer

Zwei aktuelle Fälle illustrieren Spannweite und Reife. Mit „AlphaAgents“ demonstrieren Forschende von BlackRock ein Multi‑Agenten‑Setup für Aktienauswahl: Fundamental‑, Sentiment‑ und Bewertungsagent debattieren, bis ein Konsens vorliegt. Das Konsortium-Pattern. Aus Faulheit selten angewendet. Im riskoneutralen Test über wenige Monate stieg die Sharpe Ratio gegenüber Benchmarks; im risikoaversen Setup blieb man zurück, mit geringeren Drawdowns. Das ist kein Freifahrtschein für den Finanzhandel, aber ein belastbarer Hinweis: Rollen‑Trennung plus Debatte verbessert Qualität und macht Signale nutzbarer – zum Beispiel als Input für klassische Optimierer.

Am anderen Ende der Ernsthaftigkeit lässt Geoffrey Huntley einen Agenten monatelang laufen und bekommt eine neue Programmiersprache samt LLVM‑Backend heraus. Die Geschichte zu „cursed“ liest sich wild, zeigt aber zweierlei: Lang laufende Agenten können komplexe Artefakte erzeugen, und ohne erfahrene Operator:innen, die Richtung geben, kuratieren und reparieren, verheddert sich das System. Wer SASEs Idee der N‑Version‑Programmierung ernst nimmt – mehrere Varianten, beste selektieren oder synthetisieren –, findet hier Anschauungsmaterial: Output ist machbar, aber Governance entscheidet über Wert.

Warum das jetzt skaliert: Tokens überall

Zur Einordnung hilft ein Schritt zurück. Ein Überblicksartikel von Marcel Weiß in der FAZ erklärt, warum Tokenisierung und Transformer so breit funktionieren: Alles wird zur Sequenz – Text, Bilder, Zeitreihen, Proteinfolgen oder Verkehrstrajektorien – und Self‑Attention modelliert weitreichende Abhängigkeiten. Deshalb sehen wir transformerbasierte Wettermodelle, die klassische Verfahren bei drastisch weniger Rechenzeit erreichen, und Handelsprognosen im Millionenmaßstab. Für uns heißt das: Wo Daten als Tokens vorliegen und Verträge klar sind, können KI-Workflows zuverlässig wirken und Agenten zuverlässig handeln.

Der rote Faden durch all diese Beispiele ist unbequem und befreiend zugleich: Nicht‑Determinismus bleibt, aber er wird planbar, wenn wir ihn von Anfang an mit Artefakten, Verträgen, Evidenz und Messung einhegen – wer Struktur liefert, darf Tempo fordern.

Bis nächste Woche.
Robert