Lifecycle stage — Build
Vrijwel niemand heeft een multi-agent-systeem op productieschaal opgeleverd. De afstand tussen een LangGraph-demo die werkt in een notebook en een systeem dat draait voor betalende klanten is waar elk ander team vastloopt — en dat gebeurt om redenen die pas duidelijk worden als u er zelf een heeft gebouwd. Dit zijn de ENGINEER- en PILOT-fases van de DEPLOY Method, gecomprimeerd tot een 12-wekelijks ingebed traject voor teams die al een agent-prototype met echte gebruikers hebben en het moeten industrialiseren. Ik heb Auralink gearchitectureerd — 1,7 miljoen regels productiecode, ongeveer 20 autonome agents die 78% van de incidenten oplossen zonder menselijke tussenkomst, peer-reviewed op arXiv. Een vergelijkbaar multi-agent-systeem bestaat vandaag nergens in productie. Het werk dat ik met uw team doe, is hetzelfde werk dat ik met het mijne deed, aangepast aan uw codebase, uw agents en uw operationele beperkingen. Ik heb acht AI-ventures in productie gebracht. Ik weet welke beslissingen kunnen worden uitgesteld en welke u zes weken na launch zullen bijten als u ze nu overslaat.
Elke agent-demo werkt in een notebook en valt uiteen onder gelijktijdig productieverkeer. De tutorial gebruikt synchrone aanroepen, één happy-path-trajectory en mock-tools. Productie draait tientallen agent-sessies parallel, elk met echte tool-aanroepen en echte storingsmodes, en het naïeve orchestratiepatroon dat in de demo er schoon uitzag, wordt een thundering herd van retries, deadlocks en half-gecommitte state. Uw team weet dat dit een probleem is en heeft geen referentiearchitectuur om het op te lossen.
Uw eval-strategie voor single-turn LLM-calls strekt zich niet uit tot multi-step agent-trajectories. U kunt een prompt evalueren. U kunt nog geen 14-stappenplan evalueren waarin de vijfde stap het verkeerde tool koos, de negende stap het verkeerde argument meegaf en het eindantwoord toch technisch klopte. Faalpatronen in agent-trajectories stapelen zich op over stappen en de evaluatiemethodologie uit single-turn-werk levert misleidende scores op. Zonder trajectory-level-evaluatie kunt u niet zeggen of een modelupdate het systeem verbeterde of verslechterde, en kunt u niet met vertrouwen uitrollen.
Kosten per taak exploderen onvoorspelbaar omdat elke agent-stap het tokenverbruik vermenigvuldigt. Eén gebruikersverzoek triggert een plan, dat triggert tool-calls, die triggeren sub-agents, die triggeren meer tool-calls. Uw token-count per sessie is nu 40x een gewone LLM-call en uw CFO wil een model dat uitlegt waarom één power-user afgelopen dinsdag €18 aan tokens kostte. U heeft geen instrumentatie om dat te beantwoorden — geen token-accounting per stap, geen routing-logica die goedkopere modellen kiest voor eenvoudigere stappen, geen budget-caps die netjes afbreken als een sessie op hol slaat.
Als een agent iets fout doet in productie, heeft u geen observability-stack die u vertelt welke stap, welke prompt, welke tool-call het veroorzaakte. De gebruiker klaagt dat 'de agent een raar antwoord gaf'. Uw logs tonen het eindantwoord en verder niets. U kunt de trajectory niet reproduceren omdat de agent non-deterministisch is. U kunt niet zeggen of de bug zit in de planner, de tool-router, de retrieval-laag of een specifieke prompt-template. Elke incident wordt een meerdaagse forensische oefening en uw team verliest sneller vertrouwen in het systeem dan de gebruikers.
De opdracht loopt in vier fases van drie weken. Ik werk ingebed met uw engineeringteam — uw engineers bouwen, ik breng de topologiebeslissingen, de eval-methodologie en de observability-patronen vanuit Auralink. Er wordt geen werk gedaan op een consulting-slide. Aan het einde van week twaalf draait uw team het systeem zonder mij.
Ik ga de diepte in op uw huidige prototype — de agent-graph, het tool-inventaris, het state-management, de faalpatronen die u al hebt ondervonden. Ik lever een geschreven topologie-ontwerp: welke agents, welke verantwoordelijkheden, welke communicatiepatronen, welke state-grenzen, welke failure-isolation-zones. Het ontwerp is specifiek voor uw domein en uw codebase, geen referentiearchitectuur gekopieerd uit een blogpost. Aan het einde van week drie heeft uw team een blauwdruk die ze kunnen verdedigen tegenover een senior reviewer, en een migratiepad vanuit het huidige prototype dat geen herschrijving vereist.
Uw engineers implementeren de topologie. Ik werk naast hen aan de moeilijkere keuzes — de orchestration-primitives, de concurrency-strategie, de state-machine voor langlopende sessies, de retry- en compensatielogica voor tool-storingen. We leveren incrementeel tegen echt verkeer vanaf week vijf, geen big-bang-overgang in week zeven. Aan het einde van week zeven bedient de nieuwe topologie productieverkeer en is het oude prototype buiten bedrijf gesteld.
Trajectory-level-evaluatie gebouwd op de patronen die ik voor Auralink ontwikkelde — per-step-evaluatie, ground-truth-trajectories voor regressietests, LLM-als-jury met gekalibreerde prompts en de statistische methodologie waarmee u kunt zeggen 'deze modelupdate verbeterde het systeem met 4,2% bij p < 0,01' in plaats van 'de nieuwe versie voelt beter'. Per-step token-accounting en dashboards voor kosten-per-taak zodat uw CFO de vragen kan beantwoorden die komen. Uw team draait de eval op elke wijziging vanaf week negen.
De observability-stack die uw on-call-engineer gebruikt als de pager om 3 uur 's nachts afgaat — trajectory-traces gekoppeld aan gebruikerssessies, per-step prompts en completions, tool-call input en output, token-accounting, latentiebreakdowns, kostentoewijzing. Runbooks voor de top-10-incidenttypes die uw systeem zal produceren. Werksessies met uw SRE-team zodat zij de alerting-drempels, dashboards en incidentresponspaden bezitten. Als ik vertrek, draait uw team het systeem. Geen retainer, geen doorlopende afhankelijkheid.
Enterprise-technologieorganisaties en Series-B+-startups met een agent-prototype dat echte gebruikers heeft, budget voor een 12-wekelijkse ingebedde opdracht en een engineeringteam met capaciteit om het systeem na overdracht te bezitten. Productteams waar de CTO of VP Engineering al tegen de muur is gelopen tussen 'agent-demo werkt' en 'agent-systeem draait' en weet dat de kloof een topologieprobleem, een eval-probleem en een observability-probleem is — geen prompt-engineering-probleem. Dit is niet voor teams zonder LLM-productie-ervaring — zij hebben eerst de Readiness Audit of de Strategy Sprint nodig. Het is ook niet voor teams zonder bestaande codebase; de opdracht veronderstelt een prototype om te industrialiseren, geen greenfield-build.
Niet veel. Het orchestration-framework is een voertuig — de beslissingen die ertoe doen zijn de topologie, het state-management, de eval-methodologie en de observability. Ik heb gewerkt met de belangrijkste frameworks en met custom orchestration-code. In week één beoordeel ik of uw huidige framework het juiste voertuig is voor waar u naartoe gaat; soms is het antwoord ja en bouwen we erop voort, soms pleit een specifieke bottleneck voor een migratie. Ik maak die keuze op basis van bewijs, niet op basis van welk framework de beste marketing heeft.
Een senior AI-engineer die u in 2026 aanneemt, heeft waarschijnlijk geen productie-multi-agent-systeem opgeleverd, want vrijwel niemand heeft dat gedaan. Ik heb het één keer gedaan, op 1,7 miljoen regels code en 78% autonome oplosratio. De patroonherkenning is nog niet beschikbaar op de contractormarkt. Uw engineers doen de implementatie; ik breng de topologiebeslissingen, de eval-methodologie en de observability-patronen die hen anders drie iteraties en twaalf maanden zouden kosten om te leren. Als ik vertrek, bezit uw team alles en heeft mij niet meer nodig.
Nee. Agent-topologie, eval-harnas en observability zijn elk drie-weekse problemen als ze goed worden gedaan en elk één-weekse problemen als ze slecht worden gedaan. De gecomprimeerde versie levert een systeem op dat draait tot het niet meer draait, en de debugging-kosten in maand vier overschrijden de consulting-besparing in maand één. Als u geen twaalf weken heeft, is de juiste opdracht de Pilot-to-Production Hardening-service, die het productieklaarmaak-werk dekt zonder de volledige topologie-herontwerp. Ik beveel dat eerlijk aan als dat de juiste match is.
Bijna nooit. In de opdrachten die ik heb uitgevoerd, behoudt het topologie-ontwerp 60-80% van de bestaande code en verandert het de orchestration-laag, de state-grenzen en de failure-isolation-patronen. De businesslogica die uw team schreef is meestal prima; wat moet veranderen is hoe de agents coördineren, hoe state wordt beheerd en hoe fouten worden afgehandeld. Volledige herschrijvingen zijn een teken van een consultant die uw code niet wil lezen. Ik lees uw code.
Het is een gemeten getal uit het productiesysteem van Auralink, gerapporteerd in het arXiv-paper. 78% van de incidenten toegewezen aan de agent-pool wordt opgelost zonder mens in de lus — inclusief de gevallen waarin een agent correct escaleert, niet alleen de gevallen waarin hij end-to-end oplost. De methodologie om het te meten maakt deel uit van wat ik naar uw opdracht breng. Elk team waarmee ik heb gewerkt eindigt met een ander getal omdat hun taakprofiel anders is; het doel is niet om 78% te repliceren, maar om de meet-infrastructuur te bouwen die u vertelt wat uw echte getal is.
Ontdek andere diensten die dit aanbod aanvullen
30 minuten. Ik diagnosticeer uw situatie en zeg u eerlijk of deze dienst past — en zo niet, welke wel.