De afgelopen maanden zie je het overal: teams bouwen niet meer "een chatbot", maar workflows met AI. Denk aan een assistent die mailtjes samenvat, tickets classificeert, documenten doorzoekt, of een proces stap-voor-stap afhandelt met tools en integraties.
En precies daar begint de frictie.
Niet omdat AI het niet kan - maar omdat elke provider z'n eigen "stekker" heeft.
Het probleem: dezelfde bouwblokken, andere stekkers
Vrijwel alle moderne LLM-platformen gebruiken ondertussen vergelijkbare concepten: berichten, tool calls, streaming output, multimodal input. Alleen... iedereen beschrijft ze nét anders.
Gevolg: als je een workflow bouwt voor provider A, ben je bij provider B weer bezig met vertalen, aanpassen, testen en edge cases fixen. En dat maakt het lastiger om later te switchen op basis van prijs, performance, of compliance.
Wat Open Responses probeert te doen
Open Responses is een open source specification die geïnspireerd is op de OpenAI Responses API. De belofte is simpel:
Consistente 'agentic' workflows
Streaming, tool invocation en orchestration op een uniforme manier.
Makkelijker vergelijken en routeren
Loggen, evalueren en kiezen per use case op basis van een gedeelde vorm.
Als dit aanslaat, verschuift de discussie van "welke provider is het beste?" naar: "welke provider is het beste voor déze taak?".
De agentic loop: zo werkt het
Centraal in Open Responses staat de "agentic loop": een gestandaardiseerde manier om AI-agents te laten samenwerken met tools. Het model vraagt om een tool, krijgt het resultaat, en besluit of het klaar is of nog een stap nodig heeft.
Bron: Open Responses Specification
Deze loop is precies wat je nodig hebt voor agent-achtige workflows: het model kan zelfstandig tools aanroepen, resultaten verwerken, en doorwerken tot de taak af is. Open Responses standaardiseert hoe die communicatie eruitziet, ongeacht welk model of welke provider je gebruikt.
De communityreactie: enthousiast, met een scherpe kanttekening
De positieve reacties komen vooral uit de hoek van builders die al langer een vendor-neutrale standaard willen. Simon Willison noemde dit zelfs expliciet de standaardiseringspoging waar hij al jaren op hoopte - juist omdat het een praktische, JSON-achtige interface is waar veel tools op mee kunnen liften.
En dat liften gebeurt meteen. LM Studio en Hugging Face publiceerden bijvoorbeeld op "launch day" al ondersteuning voor Open Responses, waarmee je lokale modellen via dezelfde soort interface kunt aanspreken.
Kritische kanttekening
Een terugkerend punt: standaarden worden vaak "lowest common denominator". De kritiek die je ziet: als je standaardiseert op de "shape" van één provider, kun je features missen die andere providers wél hebben, of beperkingen overnemen die niet nodig zijn.
Die kritiek is niet raar. Maar dit is ook precies hoe standaarden meestal beginnen: eerst 80% van de frictie wegnemen, daarna volwassen worden met extensies en varianten.
Waarom dit interessant is voor organisaties (en niet alleen voor developers)
Als je AI inzet voor echte processen, wil je opties openhouden. Open Responses is interessant omdat het precies dáár over gaat:
Minder lock-in in pilots
Je kunt een pilot zo ontwerpen dat je later kunt wisselen van provider zonder het hele fundament te slopen. Dat is prettig als kosten stijgen, beleid verandert, of je anders moet omgaan met data.
Betere keuzes per klant en per context
De ene organisatie wil "best possible output" (cloud), de andere wil "maximale controle" (lokaal). Als je interface gelijk is, kun je makkelijker schakelen tussen die werelden.
Vergelijken en routeren wordt praktisch
Niet één heilige provider, maar slim kiezen: snelle/goedkope modellen voor standaardtaken, zwaardere modellen voor complexe cases. En dat wordt pas echt interessant als je tooling daar goed op aansluit.
Open Responses + MCP: twee kanten van dezelfde puzzel
Een vraag die je vaak hoort: "Hoe verhoudt Open Responses zich tot MCP (Model Context Protocol)?" Het korte antwoord: ze vullen elkaar aan.
Open Responses
Standaardiseert hoe jij praat met het model. Inputs, outputs, streaming, tool-call requests - allemaal in één uniform formaat, ongeacht de provider.
MCP
Standaardiseert hoe het model praat met de buitenwereld. Tool-executie, context passing, en het teruggeven van resultaten - los van welk model je gebruikt.
Samen: end-to-end portability
Een applicatie met Open Responses kan uniform modellen aanroepen van elke provider en consistent tool-call requests parsen uit de gestreamde output.
Wanneer het model een tool aanvraagt, kan een MCP-compliant orchestratielaag de executie afhandelen, context doorgeven, en resultaten injecteren - onafhankelijk van de onderliggende modelprovider.
Het resultaat: schrijf je agent-logica één keer, wissel modellen via Open Responses, en wissel of beveilig tool-integraties via MCP. Zonder vendor-specifieke hacks.
Waarom dit relevant is voor Think Ahead
Bij Think Ahead bouwen we AI-pilots en agent-achtige workflows die snel naar een werkende demo gaan - met echte data en echte processen. In die wereld is "portability" geen hypewoord, maar gewoon: risico-reductie.
Open Responses is voor mij vooral een signaal: de markt beweegt richting een laag waarin je niet meer "OpenAI-apps" of "Anthropic-apps" bouwt, maar workflow-apps met verwisselbare modellen.
Of dit dé standaard wordt? Te vroeg om te zeggen.
Maar dat er behoefte is aan een "USB-C voor AI-agents" - dát is glashelder.
Wil je AI-workflows bouwen die niet vastzitten aan één provider?
We denken graag mee over architectuur, toolkeuze en vendor-onafhankelijke implementaties.
