Von fest verdrahtet zu fließend: Wohin sich Softwarearchitektur nach der Agent-Ära entwickelt

Jede Generation von Softwarearchitektur war eine Antwort auf eine Frage: Wie viel von der Welt können wir uns leisten, zur Build-Zeit offenzulassen?

Die Antwort lautete: „fast nichts“. Dann begann sich das zu ändern – und seitdem immer schneller. Versuchen wir eine Prognose, wo es landet.

1. Alles fest verdrahtet

Die ersten Systeme waren die in Code eingefrorene Welt. Datenmodell, Prozess, Integration, Bildschirm – alles wurde einmal festgelegt, von wenigen Leuten, bevor der erste Nutzer auftauchte. Das funktionierte prächtig, solange die Realität zu den Annahmen passte. Sobald sie das nicht mehr tat, bog sich das System nicht, es brach. Änderung bedeutete ein Release, ein Release bedeutete ein Projekt, ein Projekt bedeutete Monate oder Jahre.

Das Designprinzip dieser Zeit: Korrektheit durch Starrheit. Was Sie nicht vorhersagen können, können Sie nicht unterstützen.

2. Workflows und Konfiguration

Dann gaben wir zu, dass Geschäftsprozesse variieren, und zogen die Variation aus dem Code in Workflow-Engines, Regel-Engines und Konfiguration. Verzweigungen, Freigaben, Ausnahmen, regionale Varianten – alles ohne Neukompilieren ausdrückbar. BPM, Low-Code und tausend Admin-Masken entstanden. Schauen Sie sich eine beliebige Legacy-SaaS-Plattform wie Salesforce an.

Das war ein echter Fortschritt, aber ein subtiler: Die Kategorien der Variation blieben fest. Sie konnten Schritte umsortieren – aber nur solche, die sich die Designer vorgestellt hatten. Eine Workflow-Engine verdrahtet den Raum möglicher Änderungen fest, statt die Änderungen selbst.

Designprinzip: Flexibilität innerhalb eines vordefinierten Rahmens.

3. KI-Modelle hinter Prompt-Oberflächen

Large Language Models kamen, und wir taten das Naheliegende: Wir schraubten sie seitlich an unsere Systems of Record. Dieses Ticket zusammenfassen. Jene E-Mail klassifizieren. Die Antwort entwerfen. Den CRM-Datensatz mit dem anreichern, was das Modell weiß.

Mächtig – aber architektonisch konservativ. Das Modell war ein sehr kluger Funktionsaufruf. Schema, Prozess und Oberfläche bewegten sich keinen Millimeter. Wir hatten eine neue Quelle von Intelligenz, die ein altes Skelett fütterte.

Designprinzip: Intelligenz als Anreicherungsschicht.

4. Agents rund um einen starren Kern

Als Nächstes kamen Agents: Modelle mit Tools, Gedächtnis und der Freiheit, viele Schritte auf ein Ziel hin zu gehen. Plötzlich konnte ein System Aufgaben bewältigen, deren Ausgangslage nicht vollständig spezifiziert war. „Löse das Problem dieses Kunden“ statt „führe Flow 14b aus“.

Und doch blieb der Kern starr. Agents arbeiteten am System of Record über dieselben APIs und dasselbe Datenmodell, die wir Jahre zuvor eingefroren hatten. Der Agent war flexibel, der Boden unter ihm nicht. Der Großteil der Cleverness des Agenten floss in Umgehungslösungen für Beschränkungen, die das System aus Gründen auferlegte, an die sich niemand mehr erinnerte.

Designprinzip: flexible Ausführung auf festem Fundament.

5. „KI-native“ Plattformen

Die aktuelle Debatte dreht das Verhältnis um. Das System of Record rückt hinter die Bühne. Davor stehen eine reichhaltige Dialogoberfläche und Dutzende zusammenwirkende agentische Kollegen. Menschen beschreiben Ergebnisse, Agents finden die Schritte, die Datenbank wird zum Implementierungsdetail.

Hier entstehen heute viele ehrgeizige Produkte, und es ist eine echte Verschiebung darin, wer – oder was – der primäre Nutzer des Systems ist. Aber sprechen Sie mit jemandem, der so etwas baut, und Sie hören dasselbe Unbehagen. Die Chat-Oberfläche ist nicht das Ziel. Das agentische Harness ist nicht das Ziel. Darunter tragen die meisten dieser Plattformen weiterhin ein festes Datenmodell, handverdrahtete Integrationen und eine Prozessschicht, die jemand pflegen muss. Wir haben die Starrheit aufgelockert, nicht vollständig beseitigt.

Das ungelöste Problem

Offen bleibt: Wie baut man ein System, in dem sich alles im laufenden Betrieb ändern kann – Datenmodell, Prozesse, Integrationen, Benutzeroberfläche –, während Tausende Agents innerhalb und außerhalb des Systems gleichzeitig darauf agieren und das offene Internet einer der Akteure ist?

Niemand hat bisher eine saubere Antwort. Aber ich glaube, ihre Form wird erkennbar, und sie beruht auf einer Umdeutung.

Die Umdeutung: Schluss mit Berechtigungssystemen, her mit Randbedingungen

Jede frühere Epoche wollte flexibel werden, indem sie mehr von der Zukunft vorhersagte und vorab codierte. Flexibilität, Stück für Stück. Diese Strategie ist erschöpfend. Die Alternative: nicht noch mehr Berechtigungen hinzufügen, sondern entscheiden, was sich niemals ändern darf – und alles andere zur Laufzeit aushandeln lassen.

Konkret erwarte ich, dass sich die Architektur in zwei Schichten mit sehr unterschiedlicher Änderungsrate teilt.

Die langsame Schicht: eine Verfassung, keine Codebasis

Ein minimaler, bewusst konservativer Kern, den Menschen besitzen und der sich selten ändert:

• •Identität und Autorität. Wer und was existiert, was jeder Akteur tun darf und wie Berechtigungen an Agents delegiert und ihnen wieder entzogen werden.
• •Ein Ledger der Fakten. Kein Schema, sondern ein nur anfügbares, versioniertes Protokoll dessen, was geschah und was behauptet wurde – samt Herkunft. Schemas werden zu Sichten auf dieses Ledger, die sich später neu interpretieren lassen.
• •Invarianten und Policies. Die echten geschäftlichen, rechtlichen und sicherheitsrelevanten Regeln, deklarativ formuliert: „Keine Erstattung übersteigt die ursprüngliche Zahlung“, „Kundendaten verlassen nie die EU-Region“, „Jede Aktion über 10.000 € braucht eine menschliche Unterschrift“.
• •Ökonomie und Budgets. Limits für Rechenleistung, Geld und Risiko pro Akteur und pro Aufgabe – denn ein System autonomer Agents ohne Budgets ist ein Störfall mit Ansage.
• •Evaluation. Die Tests, Monitore und Qualitätssignale, die definieren, was „funktioniert“ heißt – damit sich die schnelle Schicht laufend beurteilen lässt.

Die schnelle Schicht: alles andere, generiert und ausgehandelt

Über der Verfassung wird nahezu alles fließend:

• •Datenmodell als sich entwickelnder Graph. Konzepte, Beziehungen und sogar Felddefinitionen werden zur Laufzeit vorgeschlagen, übernommen und ausgemustert. Ein Agent, der auf eine neue Art von Entität stößt, scheitert nicht an einer fehlenden Spalte. Er schlägt ein neues Konzept vor, das System prüft es gegen die Invarianten, und es wird Teil des gemeinsamen Vokabulars – versioniert, mit einem Migrationspfad, den Agents ausführen können.
• •Prozesse als Ziele plus Randbedingungen. Statt eines Flussdiagramms ist ein Prozess ein deklariertes Ergebnis, eine Reihe von Leitplanken und eine Erfolgsbilanz. Die Schritte werden pro Fall geplant, und erfolgreiche Pläne werden als „Gewohnheiten“ gespeichert: Sie verfestigen sich zu schnellen Pfaden, wenn sie stabil sind, und lösen sich auf, wenn sich die Welt bewegt. Workflows verschwinden nicht, sie werden emergent und wegwerfbar.
• •Integrationen als Gespräche zwischen Agents. Punkt-zu-Punkt-API-Verträge weichen Agent-zu-Agent-Protokollen: Zwei Systeme entdecken gegenseitig ihre Fähigkeiten, handeln Bedingungen aus und tauschen Daten über gemeinsame Semantik aus, statt über handgemappte Felder. Die offenen Standards, die heute entstehen – Tool-Protokolle, Agent-zu-Agent-Messaging, maschinenlesbare Fähigkeitsbeschreibungen –, sind die frühe Verrohrung dafür.
• •Oberflächen als Kompilate. Die UI wird für diese Person, für diese Aufgabe, in diesem Moment gerendert – aus dem aktuellen Zustand des Graphen und den aktuellen Berechtigungen. Manchmal ist sie ein Chat. Oft ein Formular, eine Tabelle, ein Dashboard oder gar nichts, weil die Arbeit fertig war, bevor jemand hinsehen musste. „Die Oberfläche“ wird zum Verb.
• •Das Internet als vollwertiger Teilnehmer. Externe Agents, öffentliche Daten, Systeme anderer Organisationen. Die Grenze „des Systems“ ist eine Berechtigungsgrenze, keine Deployment-Grenze.

Was das an unserer Arbeit ändert

Stimmt dieses Bild auch nur zur Hälfte, verändert sich die Rolle von Architekten und Entwicklern in dreierlei Hinsicht.

Wir hören auf, Verhalten zu schreiben, und schreiben stattdessen Randbedingungen und Evaluationen. Der wertvollste Code im künftigen System ist der, der festlegt, wie „gut“ und „verboten“ aussehen – denn er hält zehntausend Agents kohärent.

Versionierung wird zur zentralen Disziplin. Nicht die Versionierung von Releases, sondern die von Bedeutung: Konzepte, Policies und Gewohnheiten tragen alle eine Historie, und das System muss erklären können, warum ein Fakt oder eine Entscheidung unter welchen Definitionen entstanden ist.

Vertrauen wird zur konstruierten Größe. Jeder Agent, intern oder extern, sammelt gegenüber der Evaluationsschicht eine Reputation an. Autonomie wird danach gewährt und wieder entzogen – so wie ein neuer Mitarbeiter mehr Befugnisse erhält, wenn er sich bewährt.

Offene Fragen bleiben

Mehrere harte Probleme haben noch keine überzeugende Antwort:

• •Observability. War der Prozess vorab entworfen, hieß Debugging, den Entwurf zu lesen. Wird er pro Fall von Agents geplant, braucht das Verstehen von Was und Warum Tooling, das uns größtenteils fehlt.
• •Konsistenz im großen Maßstab. Verteilte Systeme waren schon schwer, als die Teilnehmer deterministisch waren. Massive agentische Workloads, die ein gemeinsames, veränderliches Datenmodell aushandeln, sind eine neue Kategorie von Nebenläufigkeitsproblem.
• •Kosten. Ein System, das über alles nachdenkt, bezahlt für alles. Die Idee der „Gewohnheiten“ – stabiles Verhalten in günstigen Code einzufrieren – ist wichtiger, als sie klingt.
• •Verantwortlichkeit. Aufsichtsbehörden, Prüfer und Kunden werden weiter fragen: „Wer hat das entschieden?“ Die Verfassungsschicht existiert vor allem, damit sich diese Frage beantworten lässt.

Wo uns das hinführt

Jede Architekturepoche hat verringert, wie viel von der Welt wir vorab entscheiden mussten. Hardcoding entschied alles. Workflows entschieden die Kategorien der Änderung. Prompt-getriebene KI ließ Entscheidungen fest, machte aber die Daten reicher. Agents befreiten die Ausführung, aber nicht das Fundament. KI-native Plattformen rückten die Starrheit aus dem Blickfeld.

Der nächste Schritt: die Starrheit bewusst machen und winzig halten – eine kleine Verfassung unter menschlicher Kontrolle – und alles andere, vom Schema bis zum Bildschirm, von Agents darin aushandeln lassen. Die Systeme, die das richtig machen, fühlen sich nicht an wie Software, die wir bedienen. Sie fühlen sich an wie Organisationen, die wir lenken.

Mich würde interessieren, welches Teilstück aus Sicht anderer, die in diesem Feld bauen, nicht trägt.