Automatische vertaling
Dit artikel is automatisch vertaald vanuit de oorspronkelijke Engelse versie.
Enterprise RAG Challenge 3 (ECR3): Winnende AI-agentarchitecturen
De Enterprise RAG Challenge 3 (ECR3) is net afgerond. 524 teams, meer dan 341.000 agent-runs, en slechts 0,4% van de teams behaalde een perfecte score. Nu het leaderboard en de write-ups openbaar zijn, ben ik door de winnende oplossingen gegaan om te zien wat de topteams anders deden.
Deze post behandelt wat ECR3 is, hoe de taken eruitzagen en welke patronen ik steeds terugzag in de architecturen die werkten.
Kort gezegd: Multi-agentpijplijnen versloegen monolithische varianten. Het topteam gebruikte evolutionaire prompt-engineering over 80+ geautomatiseerde iteraties. Winnaars staken serieus werk in guardrails (pre-flight security-checks, validators in de loop, post-execution guards) en in contextstrategie. Wat in de context zat, was belangrijker dan hoeveel erin zat.
Wat is de Enterprise RAG Challenge?
De Enterprise RAG Challenge 3 is een grootschalig, crowdsourced onderzoeksproject dat test hoe autonome AI-agents omgaan met complexe bedrijfstaken. In tegenstelling tot statische benchmarks draait ECR3 op de Agentic Enterprise Simulation (AGES), een discrete-eventsimulatie die een realistische enterprise-API blootlegt.
Waarom ECR3 belangrijk is
Via AGES werken agents binnen een nepbedrijf dat het volgende heeft:
- Medewerkersprofielen met specifieke vaardigheden en afdelingen
- Projecten met teamtoewijzingen en klantrelaties
- Corporate wiki met bedrijfsregels en permissiehiërarchieën
- Tijdregistratie en financiële operaties
Elke taak start zijn eigen simulatie met verse data, dus agents kunnen niets tussen runs memoriseren.
De moeilijkheidsgraad
Het leaderboard is streng:
| Metric | Value |
|---|---|
| Registered Teams | 524 |
| Total Agent Runs | 341.000+ |
| Available Tasks | 103 unieke bedrijfstaken |
| Perfect Score (100.0) | Slechts 0,4% van de teams |
| Score ≥ 0.9 | Slechts 1,1% van de teams |
Soorten taken
De taken beslaan meerdere vaardigheidsgebieden:
- Multi-hop reasoning: Vaardigheden van medewerkers kruislings verwijzen met projecttoewijzingen
- Permissievalidatie: Ongeautoriseerde salariswijzigingen of datatoegang voorkomen
- Ambigue queries: Omgaan met meertalige en geparafraseerde gebruikersverzoeken
- Strikte output-compliance: Verplichte entity-links opnemen in antwoorden
Wat er daadwerkelijk won
Vier patronen kwamen steeds terug bovenaan het leaderboard:
- Multi-agentpijplijnen versloegen monolithische agents. Het opsplitsen van het werk werkte beter dan één grote agent die alles probeerde te doen.
- De meest autonome agents waren het meest beperkt. Guardrails waren geen bijzaak.
- Geautomatiseerde prompt-evolutie versloeg handmatige engineering. Topprompts gingen door 80+ generaties.
- Contextstrategie deed het meeste werk. Niet meer context, maar de juiste context.
Beste winnende benaderingen
De vijf architecturen hieronder gaan heel verschillende richtingen op, van volledig geautomatiseerde prompt-evolutie tot hybride retrieval. Elk heeft onderdelen die de moeite waard zijn om over te nemen.
1. Evolutionaire prompt-engineering (Team VZS9FL / @aostrikov)
De hoogst scorende aanpak automatiseerde prompt-engineering via een self-improvement-loop.
In plaats van prompts handmatig te tunen, bouwde het team een loop met drie agents waarmee de agent van zijn eigen fouten kan leren.
Drie-agentpijplijn:
| Agent | Role |
|---|---|
| Main Agent | Draait benchmark, logt alle acties en fouten |
| Analyzer Agent | Beoordeelt mislukte taken, formuleert hypothesen over root causes |
| Versioner Agent | Genereert nieuwe promptversie met de opgedane lessen |
Het resultaat: De productieprompt was de 80e automatisch gegenereerde versie. Elke versie patchte een specifiek foutpatroon dat opdook in de logs van de vorige run. De meeste daarvan waren precies het soort edge case dat je pas ziet nadat je een uur naar een mislukte trace hebt gestaard.
Stack: claude-opus-4.5 met Anthropic Python SDK en native Tool Use.
2. Sequentiële multi-agentpijplijn (Team Lcnxuy / @andrey_aiweapps)
Deze aanpak zette de monolithische agent overboord en bouwde een sequentiële pijplijn van specialisten, elk klein genoeg om daadwerkelijk goed te zijn in zijn taak.
De 4-stappenpijplijn:
- Security Gate Agent: Pre-execution-check die permissies valideert tegen wiki-regels voordat de hoofdloop start.
- Context Extraction Agent: Haalt de kritieke regels uit enorme prompts en preloadt user-, project- en customer-data.
- Execution Agent: ReAct-achtige planning met 5 interne fases (Identity → Threat Detection → Info Gathering → Access Validation → Execution).
- LinkGeneratorAgent: Ingebed in de response-tool, parseert context om de vereiste entity-links op te nemen.
De LinkGenerator-agent is het interessante deel. Hij loste een van de meest voorkomende failure modes op: een agent die het juiste antwoord geeft maar de verplichte referentielinks vergeet.
Stack: atomic-agents en instructor-frameworks met gpt-5.1-codex-max, gpt-4.1 en claude-sonnet-4.5.
3. Schema-guided reasoning met stapvalidatie (Team NLN7Dw / Ilia Ris)
Dit team combineerde SGR met zeer snelle inferentie en een real-time validator. De inzet: veel snelle, gevalideerde beslissingen verslaan één langzaam, doordacht antwoord.
Belangrijke componenten:
| Component | Function |
|---|---|
| StepValidator | Inspecteert elke voorgestelde stap. Als iets niet klopt, stuurt hij die terug voor herwerking met commentaar. |
| Context Management | Volledig plan van de vorige beurt, plus gecomprimeerde historie voor oudere beurten |
| Dynamic Enrichment | Haalt automatisch user profile, projects, customers op; LLM filtert om alleen taakrelevante data te injecteren |
| Auto-pagination Wrappers | Alle list-endpoints geven automatisch volledige resultaten terug |
Het snelheidsvoordeel komt van draaien op Cerebras met ongeveer 3.000 tokens/seconde. Op die snelheid kan de agent zich veroorloven een stap te heroverwegen in plaats van vast te houden aan een traag eerste antwoord van een zwaarder model.
Stack: gpt-oss-120b op Cerebras, met een aangepaste SGR NextStep-implementatie.
4. Enricher- en guardsysteem (Team J8Gvbi / @mishka)
Deze aanpak bouwde niet-blokkerende "intelligente hints" en een guardsysteem met meerdere lagen boven op een SGR-basis. Terwijl API-responses binnenkomen, inspecteren enrichers ze en vertellen de agent stilletjes waar hij op moet letten.
Het enrichersysteem:
Meer dan 20 enrichers inspecteerden API-responses en injecteerden contextuele hints:
RoleEnricher: "You are LEAD of this project, proceed with update."
PaginationHintEnricher: "next_offset=5 means MORE results! MUST paginate."
Drie-modus guardsysteem:
| Mode | Behavior |
|---|---|
| Hard block | Onmogelijke acties permanent geblokkeerd |
| Soft block | Risicovolle acties geblokkeerd bij eerste poging, toegestaan bij retry |
| Soft hint | Richting zonder te blokkeren |
Hybride RAG-wiki: Drie zoekstromen (regex, semantisch, keyword) parallel uitgevoerd, waarbij voor elk querytype de beste wint.
Stack: qwen/qwen3-235b-a22b-2507 op het LangChain SGR-framework.
5. Plan-execute REPL (Team key_concept_parallel)
Deze architectuur zette een harde scheiding tussen planning en uitvoering en gebruikte een codegenererende loop. In feite een REPL: de agent plant een stap, genereert code, voert die uit en beslist wat daarna moet gebeuren.
Verschillende modellen voor verschillende taken: een planner plant, een code-gen-model schrijft Python en een kleiner decision-model beslist wat te doen na elke stap.
Multi-modelopzet:
| Stage | Model |
|---|---|
| Planning | openai/gpt-5.1 |
| Code Generation | deepseek/deepseek-v3.2 |
| Post-Step Decision | openai/gpt-4.1 |
| Final Response | openai/gpt-4.1 |
De REPL voor step completion:
- Planner maakt een high-level stap.
- Code-gen-model schrijft er een Python-script voor.
- Script draait in een geïsoleerde context.
- Decision-model bekijkt het resultaat en kiest: doorgaan, afbreken of herplannen.
Het herplanpad is waar dit ontwerp zijn waarde bewijst. Als een stap deels mislukt, kan het decision-model de rest van het plan herschrijven in plaats van vast te lopen op het kapotte plan.
Patronen die overal opdoken
Los van de individuele architecturen liepen een paar gewoonten door bijna elke topsubmissie heen.
Contextmanagement deed het meeste werk
De topteams begrepen dat contextkwaliteit het plafond bepaalt voor hoe goed een agent kan presteren.
| Strategy | Approach | Best for |
|---|---|---|
| Rule Distillation | Wiki vooraf verwerken via LLM tot een samenvatting van ~320 tokens | Lean prompts, snelle start |
| Aggressive Preloading | User/project/customer-data laden vóór uitvoering | Tool-calls minimaliseren |
| Hybrid RAG | Regex + semantische + keyword-zoekstromen | Complexe retrievalbehoeften |
| History Compression | Recente beurten volledig houden, oudere historie comprimeren | Lange gesprekken |
Trade-off: Teams Kc7F2N en f1Uixf ontdekten dat contextkwaliteit belangrijker is dan kwantiteit. f1Uixf zag zelfs dat history compression de performance schaadde, dus hielden ze de volledige historie aan en leunden ze in plaats daarvan op long-context-modellen.
Guardrails: hoe autonomer de agent, hoe meer hij ze nodig heeft
De agents met de hoogste scores hadden ook de strengste beperkingen om zich heen. Dat klinkt tegenintuïtief, maar dat is het niet. Een autonome agent heeft meer manieren om de fout in te gaan, dus heeft hij meer punten nodig waar iets hem kan stoppen.
| Guardrail Type | When | Example |
|---|---|---|
| Pre-Execution Gates | Voordat de hoofdloop start | Security Gate Agent valideert permissies tegen wiki-regels |
| In-Loop Validators | Tijdens reasoning | StepValidator controleert elke voorgestelde actie, triggert herwerking bij fouten |
| Post-Execution Guards | Voor finale indiening | Three-Mode Guard System valideert volledigheid van het antwoord |
Slimme tool-wrappers
Topteams bouwden abstractielagen rond de ruwe API:
- Auto-pagination: Wrappers lopen door elke pagina en geven de complete dataset terug.
- Fuzzy normalization: "Willingness to travel" wordt vertaald naar het API-veld
will_travel. - Specialized reasoning tools:
think,planencritic-tools voor gecontroleerde deliberatie.
Veelvoorkomende failure modes en hoe winnaars ze oplosten
Zelfs de topagents deelden dezelfde blinde vlekken. De oplossingen waren structureel, geen prompt-tweaks:
| Failure Mode | Description | Architectural Fix |
|---|---|---|
| Permission Bypass | Beperkte acties uitvoeren zonder gebruikerspermissies te verifiëren | Pre-execution Security Gate Agent; verplichte Identity → Permissions → Execution-sequence |
| Missing Entity Links | Tekstueel correct antwoord maar vereiste referentielinks ontbreken | Ingebedde LinkGeneratorAgent in de response-tool |
| Pagination Exhaustion | Alleen de eerste pagina van lijstresultaten verwerken | Auto-pagination-wrappers voor alle list-endpoints |
| Tool-Calling Loops | Vastlopen in herhaald dezelfde tool aanroepen met kleine variaties | Turn-limits; reasoning-gerichte modellen (Qwen3) |
| Context Overloading | Context vullen met irrelevante wiki-secties | Rule distillation; dynamische contextfiltering |
Wat je moet meenemen
Als je agents bouwt en dit wilt toepassen:
- Gebruik multi-agentpijplijnen. Monolithische agents verloren. Topteams gebruikten 3 tot 5 specialisten voor security, context extractie, planning en uitvoering.
- Automatiseer de prompt-iteratie. De winnende prompt was versie 80. Een loop vindt failure patterns die je zelf nooit zou ontdekken.
- Steek echt werk in guardrails. Pre-flight security-checks, critics in de loop en post-execution guards. De agents die het autonoomst leken, zaten het meest in een keurslijf.
- Wrap je tools. Pagination, data-enrichment en fuzzy matching horen allemaal in wrappers. Eén team bouwde 20+ enrichers die API-responses live observeerden.
- Neem contextstrategie serieus. Rule distillation (~320-token-samenvattingen), preloading en dynamische filtering. Snelheid helpt ook. Eén team draaide op ~3.000 tokens/seconde en kon zich daardoor veroorloven vaak te herplannen.