🤖 AI

In-Context Prompting Obsoletes Agent Orchestration for Procedural Tasks

Dit artikel betoogt dat voor procedurele multi-turn taken eenvoudigere prompting in de context, waarbij het model zichzelf orchestreert, beter presteert dan complexe externe agent-orchestratieframeworks, waardoor laatstgenoemde verouderd zijn voor frontier-modellen.

Oorspronkelijke auteurs: Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang, Hao Guo

Gepubliceerd 2026-05-01

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang, Hao Guo

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een complexe taak probeert te voltooien, zoals het boeken van een ingewikkelde familievakantie, het repareren van een kapotte Zoom-verbinding of het indienen van een verzekeringsclaim. In de wereld van Kunstmatige Intelligentie (KI) zijn er twee hoofdmanieren om een slimme computer te vertellen hoe dit moet.

Dit artikel betoogt dat de "fancy, ingewikkelde" manier de dingen eigenlijk erger maakt, en dat de "eenvoudige, directe" manier veel beter is.

Hier is de uitleg met behulp van eenvoudige analogieën:

De Twee Benaderingen

1. De "Manager"-benadering (Agent Orchestration)
Denk hierbij aan een strenge fabrieksvloer. Je hebt een zeer slimme werknemer (de KI), maar je hebt ook een Manager die over hun schouder meekijkt.

De Manager heeft een flowchart (een kaart met stappen).
De Manager vertelt de werknemer precies wat hij moet zeggen voor Stap 1.
Zodra de werknemer Stap 1 heeft voltooid, controleert de Manager het werk, beslist of ze naar Stap 2 of Stap 3 moeten gaan, en fluistert vervolgens de instructies voor de volgende stap.
De werknemer ziet nooit de hele kaart; ze zien alleen de kleine instructie voor het moment.
Het Probleem: De Manager is traag, maakt fouten bij het bepalen van de volgende stap, en vergeet soms wat de werknemer drie stappen geleden zei, omdat ze zich alleen focussen op de huidige instructie.

2. De "Zelfgeleide"-benadering (In-Context Prompting)
Denk hierbij aan het geven van dezelfde slimme werknemer een volledige handleiding en een kaart van de hele reis voordat ze beginnen.

De werknemer leest de hele handleiding.
Ze weten precies waar ze zijn, waar ze naartoe moeten en wat ze als volgende moeten doen.
Ze hebben geen Manager nodig om hen te vertellen wat ze moeten doen; ze leiden zichzelf.
Het Voordeel: Ze zien het grote plaatje, onthouden het hele gesprek en verlopen natuurlijk zonder te stoppen om bij elke draai toestemming te vragen.

Wat de Onderzoekers Deden

De auteurs testten deze twee benaderingen met behulp van een zeer slimme KI (genaamd "Claude Sonnet") in drie verschillende realistische scenario's:

Reisboeking: Het plannen van een reis voor een groep met een specifiek budget en specifieke interesses.
Technische Ondersteuning: Het oplossen van een audio-probleem in Zoom.
Verzekeringsclaims: Het indienen van een claim na het aanrijden van een hert met een auto.

Ze draaiden 200 simulaties voor elk scenario met zowel de "Manager"-stijl als de "Zelfgeleide"-stijl. Vervolgens lieten ze een andere KI optreden als rechter om de gesprekken te beoordelen op zaken zoals:

Hebben ze de taak voltooid?
Was de informatie accuraat?
Voelde het gesprek natuurlijk aan, of robotachtig?
Raakte de KI in de war of herhaalde ze zichzelf?

De Resultaten: De "Zelfgeleide" Werknemer Wint

De resultaten waren duidelijk en consistent in alle drie de scenario's:

Betere Kwaliteit: De "Zelfgeleide" KI (In-Context) scoorde hoger op elke enkele maatstaf. Ze voltooide taken vaker, onthield details beter en klonk meer als een behulpzame mens.
Minder Fouten: De "Manager"-benadering faalde veel vaker.
- Bij reisboeking faalde de Manager 24% van de tijd. De Zelfgeleide KI faalde slechts 11,5%.
- Bij technische ondersteuning faalde de Manager 9% van de tijd. De Zelfgeleide KI faalde slechts 0,5% (bijna nooit).
- Bij verzekeringen faalde de Manager 17% van de tijd. De Zelfgeleide KI faalde 5%.
Waarom de Manager Faalde: Omdat de Manager slechts één stap tegelijk bekeek, vergat de KI vaak belangrijke details die de gebruiker eerder had genoemd (zoals dat het budget "per persoon" was in plaats van "totaal"). Het raakte ook vast in lussen, waarbij het steeds dezelfde vraag stelde omdat het de draad kwijtraakte over waar het in het proces zat.
Snelheid en Kosten: De "Manager"-benadering kostte eigenlijk meer computerkracht en tijd, omdat de Manager bij elk beslispunt moest stoppen en nadenken. De "Zelfgeleide"-benadering was sneller en vloeiender, zelfs al vereiste het dat er aan het begin een iets langere "handleiding" in het geheugen van de KI moest worden geladen.

De Conclusie

Het artikel concludeert dat voor taken die een duidelijke set regels volgen (zoals het boeken van een reis of het indienen van een claim), we geen Manager meer nodig hebben.

In het verleden waren KI-modellen "dommer" en hadden ze een Manager nodig om ze bij elke stap door de hand te leiden. Maar de KI-modellen van vandaag zijn zo slim dat als je ze gewoon het hele regelboek aan het begin geeft, ze de rest zelf kunnen uitzoeken. Het toevoegen van een Manager staat eigenlijk in de weg, wat leidt tot verwarring en fouten.

De eenvoudige les: Als je een duidelijke procedure hebt, zet dan gewoon de hele procedure in de instructies van de KI en laat het de klus klaren. Bouw geen complex systeem om het te beheren.

1. Probleemstelling

Het artikel behandelt de toenemende complexiteit en betrouwbaarheidsproblemen die geassocieerd worden met Agent Orchestration Frameworks (zoals LangGraph, CrewAI, Google ADK, OpenAI Agents SDK). Deze frameworks maken doorgaans gebruik van een externe controller (orkestrator) die bovenop het Large Language Model (LLM) zit. De orkestrator houdt toezicht op de conversatiestatus, beheert een gerichte grafiek van werkstappen en injecteert bij elke beurt specifieke routing-instructies of knopspecifieke prompts.

De auteurs betogen dat deze architectuur aanzienlijke engineering- overhead introduceert, cascadefouten, routing-fouten en slechte consistentie tussen verschillende trials veroorzaakt. Zij hypothetiseren dat voor procedurale taken (conversaties die een gedefinieerde workflow volgen van intake tot oplossing) moderne frontier-LLM's voldoende redeneervermogen bezitten om zichzelf te orkestreren wanneer de volledige procedure in hun context wordt aangeboden, waardoor externe orkestratie overbodig en potentieel schadelijk wordt.

2. Methodologie

De studie maakt gebruik van een gecontroleerde empirische vergelijking tussen twee condities met hetzelfde frontier-model (Claude Sonnet 4.5) over drie verschillende domeinen met variërende complexiteit:

Reisboeking: 14 knopen, 3 beslissingshubs.
Zoom Technische Ondersteuning: 14 knopen, 3 beslissingshubs (vereist technische nauwkeurigheid).
Verzekeringsschadeafhandeling: 55 knopen, 6 beslissingshubs (hoge complexiteit met geneste lussen).

Experimentele Condities:

Conditie A (LangGraph Georkestreerd): De workflow is geïmplementeerd als een gerichte grafiek in LangGraph. De orkestrator beheert de status, maakt routing-beslissingen via extra LLM-aanroepen bij beslissingshubs en injecteert knopspecifieke prompt-sjablonen in de systeem-prompt voor elke beurt.
Condite B (In-Context Baseline): Het model ontvangt de volledige geserialiseerde flowchart (alle knopen, randen, voorwaarden en terminale staten) in zijn systeem-prompt. Het model orkestreert zichzelf, bepaalt de volgende stap en routeert intern zonder externe status-tracking of routing-aanroepen.

Evaluatieopzet:

Data: 200 gesimuleerde conversaties per conditie per domein ( $N=1.200$ in totaal).
Simulator: Een gebruikerssimulator (aangedreven door Claude Sonnet) genereert dynamische antwoorden op basis van de conversatiegeschiedenis, zonder kennis van de onderliggende flowchart.
Beoordeling: Conversaties werden geëvalueerd door een LLM-as-Judge (initieel Claude Sonnet, gerepliceerd met GPT-4.1) op vijf criteria:
1. Taaksucces (Procedurale voltooiing)
2. Informatienauwkeurigheid
3. Consistentie (Statuscoherentie)
4. Graceful Handling (Aanpasbaarheid aan ambiguïteit/edge cases)
5. Natuurlijkheid (Menselijke interactie)

3. Belangrijkste Bijdragen

Empirisch Bewijs van Obsolescentie: Demonstreert dat voor procedurale taken een eenvoudige in-context prompting-aanpak consequent beter presteert dan complexe orkestratieframeworks op alle kwaliteitsmetrieken.
Analyse van Falingsmodi: Identificeert dat orkestratie specifieke structurele falingsmodi introduceert (routing-fouten, gefragmenteerd redeneren, sjabloonconflicten) die niet bestaan in de in-context aanpak.
Efficiëntie-analyse: Kwantificeert de afweging tussen token-gebruik (hoger bij in-context door opname van de procedure) en API-call-efficiëntie (lager bij in-context door gebrek aan routing-overhead).
Robuustheidstest: Valideert de bevindingen met een onafhankelijke judge (GPT-4.1) om zelf-preferentiebias in de primaire judge uit te sluiten.

4. Resultaten

A. Kwaliteitsprestaties

De in-context baseline presteerde significant beter dan de LangGraph-orkestrator in 15 van de 15 vergelijkingen (3 domeinen $\times$ 5 metrieken) onder de Claude-judge, waarbij alle verschillen statistisch significant waren ( $p < 0.005$ ).

Scores: In-context scores varieerden van 4,53 tot 5,00, terwijl LangGraph-scores varieerden van 4,17 tot 4,84.
Consistentie & Graceful Handling: Het verschil was hier het meest uitgesproken. Het in-context-model behield een bijna perfecte coherentie (4,83–4,99) en aanpasbaarheid (4,96–5,00), terwijl het georkestreerde systeem worstelde (respectievelijk 4,32–4,55 en 4,38–4,62).
Replicatie: Het gebruik van GPT-4.1 als judge bevestigde de kernbevindingen: 11 van de 15 vergelijkingen waren in het voordeel van in-context prompting, met geen enkel voordeel voor orkestratie. De "Natuurlijkheid"-kloof nam af in de GPT-4.1-evaluatie, wat suggereert dat de Claude-judge mogelijk een bias heeft naar onbeperkte tekst.

B. Faalpercentages

Het georkestreerde systeem faalde significant vaker (gedefinieerd als Taaksucces $\le$ 3):

Reis: 24,0% falen (LangGraph) versus 11,5% (In-Context).
Zoom: 9,0% falen (LangGraph) versus 0,5% (In-Context).
Verzekering: 17,0% falen (LangGraph) versus 5,0% (In-Context).
Oorzaken: Georkestreerde fouten werden toegeschreven aan routing-fouten (verkeerde classificatie van conversatiestatus bij beslissingshubs), informatieverlies over knopgrenzen heen, en oneindige lussen veroorzaakt doordat de agent de voltooide fasen uit het oog verloor.

C. Efficiëntie en Kosten

API-aanroepen: Orkestratie vereiste 1,2x tot 1,7x meer LLM-aanroepen per conversatie door routing-beslissingen bij beslissingshubs.
Token-gebruik: In-context prompting verbruikte meer tokens per conversatie (bijvoorbeeld 68K versus 43K voor Verzekering) omdat de geserialiseerde procedure in elke API-aanroep was opgenomen.
Kosten: Ondanks het hogere token-gebruik was de in-context aanpak slechts 1,3x–1,4x duurder per conversatie. De kostenpremie is bescheiden in vergelijking met de aanzienlijke winsten in kwaliteit en betrouwbaarheid.

5. Betekenis en Implicaties

Paradigmaverschuiving: Het artikel suggereert dat voor goed gedefinieerde procedurale taken de "steigers" die door orkestratieframeworks worden geboden, niet langer nodig zijn voor frontier-modellen. Sterker nog, deze steigers degraderen de prestaties actief door het redeneren van het model te fragmenteren en faalpunten in te voeren.
Engineering-aanbeveling: Beoefenaars moeten prioriteit geven aan het plaatsen van de volledige procedure in de systeem-prompt voordat ze toevlucht nemen tot complexe orkestratieframeworks. Dit vereenvoudigt de stack, verlaagt de latentie (minder API-aanroepen) en verbetert de betrouwbaarheid.
Beperkingen & Toekomstig Werk:
- De bevindingen zijn specifiek van toepassing op procedurale taken met gedefinieerde workflows. Niet-procedurale taken (creatief, open-ended) of multi-model pipelines kunnen nog steeds baat hebben bij orkestratie.
- De aanpak vereist dat de procedure binnen het contextvenster van het model past (hoewel 55-knoop-procedures slechts ongeveer 2% van een 200K-tokenvenster gebruikten).
- Voor hoge volumes in productie zou de hogere tokenkost van in-context prompting fine-tuning van de procedure in kleinere modellen kunnen motiveren als een kosteneffectief alternatief.

Conclusie: De auteurs concluderen dat naarmate frontier-modellen verbeteren, de waarde van externe orkestratie voor procedurale taken afneemt. De "bottleneck" is niet betere orkestratie; orkestratie zelf is de bottleneck.