Mit Open Responses ist ein Open-Source-Standard für eine herstellerunabhängige JSON-API erschienen, über die Sprachmodelle mit Clients kommunizieren. Sie basiert auf Responses API und stellt einen weiteren Baustein des agentischen KI-Ökosystems der Firma dar.

Zusammen mit der Responses API hatte OpenAI letztes Jahr integrierte Tools und ein Software Development Kit (ADK) vorgestellt, mit deren Hilfe sich eigene KI-Agenten erstellen lassen. Die Responses API kombiniert die Chat Completions API sowie die Assistent API von OpenAI und kann eigenständig agieren, statt sich auf das Liefern von Antworten zu beschränken. Bislang war für jedes LLM jedoch ein eigener Client-Adapter erforderlich. Dies soll Open Responses nun vereinheitlichen.

OpenAI will den offenen Standard in den kommenden Monaten zusammen mit der Community und Anbietern von Interferenzlösungen weiterentwickeln. Dazu konnte OpenAI Hugging Face, Nvidia, LLM, LM Studio, Ollama, OpenRouter und Vercel als Launch-Partner gewinnen.

Mozilla hat mit any-llm bereits ein ähnliches Projekt am Start. Das Python-Paket ist eine einheitliche API für viele LLMs und erspart es Entwicklerinnen und Entwicklern, für jedes einzelne LLM einen eigenen Adapter pflegen zu müssen.

Einfacher Umstieg von Responses API auf Open Responses

Um die KI-Interoperabilität zu verbessern, definiert Open Responses ein „gemeinsames Schema und eine Werkzeugschicht, um den Aufruf von Sprachmodellen, das Streaming von Ergebnissen und die Zusammenstellung agentenbasierter Workflows zu vereinheitlichen“. Das soll unabhängig vom Anbieter funktionieren.

Entwicklerinnen und Entwickler, die bereits die Responses API nutzen, können laut OpenAI ohne großen Aufwand auf das neue Format umsteigen. Die Änderungen sollen größtenteils die agentische Argumentation betreffen. Dafür stehen neben encrypted_content (anbieterspezifische geschützte Inhalte) und summary (aus den Reasoning Traces bereinigte Daten) und dem neuen content (Reasoning Traces) nun drei Eingabeparameter zur Verfügung. Letzterer erlaubt es, die Reasoning Traces über die API zugänglich zu machen, was einen Anbieterwechsel leichter macht.

Im Fall des KI-Delta Learnings sehen die Funktionsaufrufe für Open Response im Vergleich zu Responses API folgendermaßen aus:

// Open weight models stream raw reasoning
event: response.reasoning.delta
data: { "delta": "User asked: 'Where should I eat...' Step 1: Parse location...", ... }

// Models with encrypted reasoning send summaries, or sent as a convenience by Open Weight models
event: response.reasoning_summary_text.delta
data: { "delta": "Determined user wants restaurant recommendations", ... }

Wer sich genauer in das agentische Open-Source-Modell einlesen will, findet auf der dessen Webseite eine technische Beschreibung.

(who)

Persistenz ist kein Detail, sondern prägt die gesamte Architektur. In dieser Episode diskutiert Eberhard Wolff den klassischen Mismatch zwischen objektorientierter Domänenlogik und relationalen Datenbanken, die Rolle von O/R-Mappern und die Bedeutung unter anderem von Aggregates und Domain-driven Design.

Er vergleicht relationale mit NoSQL-Ansätzen wie Dokumenten-Datenbanken und zeigt, warum unterschiedliche Persistenztechnologien zu unterschiedlichen Architekturen führen.

Lisa Maria Schäfer malt dieses Mal keine Sketchnotes.

Livestream am 23. Januar

Die Ausstrahlung findet am Freitag, 23. Januar 2026, live ab 13 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zu den Folgen finden sich auf der Videocast-Seite.

(mdo)

Wenn ich Kunden zu Domain-Driven Design (DDD) und Event Sourcing berate, gibt es einen Moment, der regelmäßig eintritt. Das Team wirkt selbstbewusst, vielleicht sogar ein wenig stolz. Sie sagen mir:

„Eigentlich arbeiten wir schon mit Events.“

Und dann zeigen sie mir ihre Events:

• UserCreated
• OrderUpdated
• InvoiceDeleted

Und innerlich zucke ich zusammen.

Denn das sind keine Events, sondern klassisches CRUD, nur eben mit Event-Syntax. Es hat die äußerliche Form von Events, aber keine innerliche Semantik. Und dieser Unterschied, so subtil er auch erscheinen mag, ist der Unterschied zwischen einem System, das die Sprache des Business spricht, und einem, das die Sprache von Datenbanken spricht.

Das Beispiel: Enterprise-Print-Management

Stellen wir uns einen Kunden vor, der sich mit Enterprise-Drucken beschäftigt. Die Software verwaltet Tausende von Druckern in großen Organisationen: in Krankenhäusern, Universitäten und Unternehmensbüros. Drucker müssen dem System hinzugefügt, für Wartungsarbeiten offline genommen, pausiert, fortgesetzt und schließlich entfernt werden, wenn sie außer Betrieb genommen werden.

Das Team hat etwas gebaut, das sie ein „Event-getriebenes System“ nennen. Und das sind ihre Events:

• PrinterCreated
• PrinterUpdated
• PrinterDeleted

Das war’s. Drei Events. Kommt Ihnen das bekannt vor?

Das ist CRUD in Verkleidung. Die Namen haben sich von INSERT, UPDATE und DELETE zu Created, Updated und Deleted geändert, aber die semantische Armut ist dieselbe. Wenn man sich ein PrinterUpdated-Event ansieht, was weiß man dann? Irgendetwas hat sich geändert. Aber was genau hat sich geändert? Dazu muss man in den Payload schauen. Warum hat es sich geändert? Keine Ahnung. War es eine geplante Wartungsmaßnahme oder ein unerwarteter Ausfall? Das Event verrät es nicht.

Das Mordproblem

Und mich erinnert das immer an ein etwas düsteres Beispiel (und die Ironie ist hoffentlich offensichtlich): Betrachten wir UserDeleted (was mir in der Praxis auch regelmäßig begegnet).

Sprechen Sie das mal laut und bewusst aus: UserDeleted. Es klingt, als hätte man die Nutzerin oder den Nutzer erfolgreich ermordet:

„Der Nutzer wurde eliminiert.“

Wäre das ein Krimi, würden die Ermittlerinnen und Ermittler sich jetzt Notizen machen.

Aber was wahrscheinlich gemeint war: AccountClosed. Oder UserDeactivated. Oder SubscriptionCancelled. Jedes davon hat eine andere Bedeutung, andere geschäftliche Implikationen, andere nachgelagerte Effekte. Aber CRUD-Sprache presst all diesen Reichtum in ein einziges, leicht morbides Verb.

Das ist nicht nur unpräzise. Es ist aktiv irreführend. CRUD-Sprache verliert nicht nur Information. Sie kann Events wie einen Polizeibericht klingen lassen.

Es fehlt die Wartungsfrage

Zurück zu unseren Druckern. Eine Wartungstechnikerin ruft beim Helpdesk an:

„Dieser Drucker im dritten Stock funktioniert nicht. Was ist passiert?“

Der Support-Mitarbeiter schaut auf den aktuellen Zustand in der Datenbank:

{ "printerId": "printer-3f-01",
"status": "offline"
}

Das ist alles, was er sieht. Der Drucker ist offline. Aber warum? Wann ging er offline? Wurde er manuell für Wartungsarbeiten offline genommen, oder ist er unerwartet ausgefallen? Ist das schon einmal passiert? Wie oft?

Mit CRUD-Events muss der Mitarbeiter nun Logs durchforsten, Zeitstempel korrelieren, vielleicht die Technikerin später zurückrufen. Jede Minute, die mit Nachforschungen verbracht wird, bedeutet verlorenes Geld und wachsende Frustration.

Das sind die versteckten Kosten semantischer Armut: Nicht nur verlorene Information, sondern verlorene Zeit, verlorener Kontext, verlorenes Vertrauen in das System.

Die semantische Alternative

Wie würden echte Events aussehen? Events, die erfassen, was tatsächlich passiert ist? In der Sprache der Domäne?

• PrinterAdded
• PrinterBecameOnline
• PrinterPaused
• PrinterResumed
• PrinterWentOffline
• PrinterRemoved

Beachten Sie die subtile, aber wichtige Verschiebung. Es heißt PrinterAdded, nicht PrinterCreated. Warum? Weil der Drucker in keinem sinnvollen Weg „erstellt“ wurde. Niemand hat einen Drucker hergestellt, indem eine Datenbankzeile eingefügt wurde. Der Drucker existierte bereits. Er war ein physisches Objekt, das in einem Karton lag, aus einer Fabrik geliefert. Was passiert ist: Er wurde dem System lediglich hinzugefügt.

Created ist CRUD-Sprache. Added ist Domänensprache. Der Unterschied zählt.

Genauso Removed statt Deleted: Der Drucker wurde nicht zerstört. Er steht wahrscheinlich irgendwo in einem Lagerraum und wartet darauf, neu zugewiesen zu werden. Er wurde aus der Verwaltung dieses Systems entfernt. Das ist passiert. Das sollte das Event sagen.

Die vollständige Historie

Spielen wir nun den Support-Anruf mit echten Events durch. Der Mitarbeiter ruft die Historie des Druckers auf:

2026-01-15 09:00 PrinterAdded
2026-01-15 09:05 PrinterBecameOnline
2026-01-16 14:30 PrinterPaused { "reason": "scheduled maintenance" }
2026-01-16 16:00 PrinterResumed
2026-01-17 11:45 PrinterWentOffline { "reason": "paper jam detected" }
2026-01-17 12:00 PrinterBecameOnline
2026-01-18 09:22 PrinterWentOffline { "reason": "connection lost" }

Jetzt kann er alles sehen:

• Der Drucker ging heute um 09:22 Uhr offline, weil die Verbindung verloren ging.
• Das ist das zweite unerwartete Offline-Event in zwei Tagen.
• Gestern war es ein Papierstau, heute ist es Konnektivität.
• Davor gab es eine geplante Wartungspause, die reibungslos verlief.

Die Technikerin muss in Konsequenz also nicht blind herumprobieren. Sie weiß, dass sie die Netzwerkverbindung prüfen muss, nicht das Papierfach. Sie kann ein Muster erkennen, weil das gleiche Problem in der Vergangenheit schon mit anderen Druckern aufgetreten ist: vielleicht versagt gerade die Netzwerkkarte dieses Druckers.

Das ist der Wert, den CRUD-Events nicht liefern können. Nicht nur „was ist der Zustand“, sondern „wie ist er dorthin gekommen“ und „was sagt uns dieses Muster“.

Events als natürliche Sprache

Das berührt etwas Grundlegenderes. In einem früheren Beitrag habe ich darüber geschrieben, wie niemand Geschichten mit CRUD erzählt. Man sagt nicht „Rotkäppchen wurde erstellt, dann aktualisiert, dann wurde die Großmutter gelöscht.“ Das ist absurd. Man erzählt die Geschichte durch Events: was passiert ist, in welcher Reihenfolge und warum es wichtig war.

Und in einem anderen Beitrag über DDD habe ich argumentiert, dass Domain-Driven Design unnötig kompliziert gemacht wurde. Die Essenz ist einfach: „Sprich die Sprache der Domäne!“ Aber wir haben diese Einfachheit unter Schichten von Patterns und Jargon begraben.

Hier ist der Zusammenhang: Wer gute Events formuliert, spricht automatisch die Sprache der Domäne. Man kann nicht PrinterPaused schreiben, ohne zu verstehen, dass Pausieren ein Konzept in dieser Domäne ist, unterschieden vom Offline-Gehen, unterschieden vom Entfernen. Der Akt des Benennens von Events zwingt dazu, Gespräche mit Domänenexpertinnen und -experten zu führen. „Wie nennen Sie es, wenn ein Drucker vorübergehend, aber absichtlich aufhört zu arbeiten?“ Diese Frage führt direkt ins Herz der Domäne.

Das ist DDD, ohne es DDD zu nennen. Keine Aggregates, keine Bounded-Contexts, keine einschüchternde Terminologie. Nur Events, die erfassen, was passiert, benannt so, wie das Business sie benennt.

Der Weg zu DDD führt durch Events

Das heißt mit anderen Worten: Event Sourcing ist ein Katalysator für Domain-Driven Design.

Kundinnen und Kunden DDD zu erklären ist schwer. Die Terminologie schüchtert ein. Die Konzepte sind abstrakt. Viele Entwicklerinnen und Entwickler (mich eingeschlossen) haben sich irgendwann „zu dumm“ für DDD gefühlt, erschlagen von der Theorie.

Aber Events zu erklären ist einfach. Jede und jeder versteht Events. „Was ist passiert?“ ist eine Frage, die Menschen stellen, seit es Sprache gibt. Und wenn man Teams dazu bringt, ihre Events präzise zu benennen, machen sie am Ende ganz natürlich DDD. Sie beginnen, die Sprache der Domäne zu sprechen. Sie beginnen, Gespräche mit Domänenexpertinnen und -experten zu führen. Sie beginnen, Systeme zu bauen, die die Realität widerspiegeln, statt Datenbanktabellen.

Wer also auf die eigenen Events schaut und überall Created, Updated und Deleted sieht, hat die Chance, nicht nur das Event-Modell zu verbessern, sondern ein Gespräch darüber zu beginnen, was im eigenen Business tatsächlich passiert. Wie nennt man es, wenn ein Drucker hinzugefügt wird? Wenn eine Nutzerin oder ein Nutzer geht? Wenn eine Bestellung storniert versus erstattet versus angefochten wird?

Die Antworten auf diese Fragen verraten mehr über die Domäne als jeder Musterkatalog es je könnte.

Wie es weitergehen kann

Wenn Ihnen das bekannt vorkommt, fangen Sie hier an: Schauen Sie sich Ihre Events an! Lesen Sie sie laut vor! Klingen sie wie Datenbankoperationen, oder klingen sie wie Dinge, die in Ihrem Business passieren?

Für einen tieferen Einblick in die Konzepte hinter DDD und Event-Sourcing erklären diese Einführungen in Domain-Driven Design und Event-Sourcing die Grundlagen.

Denn Events sollten eine Geschichte erzählen, keinen Polizeibericht.

(rme)