Functie-uitleg 01: Orchestration Engine

Van de eerste opdracht tot de gecontroleerde patch

Agent Argo bestaat niet uit een enkel model dat zo lang mogelijk aan een taak werkt. Het is een systeem dat softwarewerk vertaalt naar begrijpelijke stappen: plannen, opsplitsen, bewerken, controleren, corrigeren en pas daarna voorleggen ter overname.

Met dit artikel begint de reeks "Functie-uitleg". Hij maakt de centrale mechanismen van Agent Argo begrijpelijk – niet als marketingbelofte, maar langs zijn werkelijke gebruik. De opening wordt gevormd door de Orchestration Engine: het proces dat van een vereiste een gecontroleerd werkproces maakt.

1. Voor de start: kwaliteit, kosten en autonomie vastleggen

Voordat Argo een taak uitvoert, zijn twee beslissingen belangrijk. Ze zijn bewust van elkaar gescheiden:

1. Hoe moet Argo afwegen tussen kosten en resultaatkwaliteit?
2. Hoe zelfstandig mag Argo handelen binnen het project?

Dit voorkomt een typisch doelconflict: een grondige run hoeft niet automatisch meer schrijfrechten te krijgen. En een autonome run hoeft niet automatisch dure modellen te kiezen.

De drie niveaus voor kosten en kwaliteit

De model-router kent drie begrijpelijke modi. Ze veranderen hoe sterk prijs en modelniveau meewegen in de selectie; de benodigde skill blijft altijd centraal.

Niveau	Router-modus	Geschikt voor
Spaarzaam	economy	Routinematige taken, extractie, duidelijk afgebakende wijzigingen. Kosten wegen zwaar.
Uitgebalanceerd	balanced	De standaard voor de meeste runs: skill-fit, kosten en kwaliteitsniveau blijven in evenwicht.
Veeleisend	expert	Architectuur, onderzoek, complexe analyses en veeleisende reviews. Modelniveau weegt duidelijk zwaarder, kosten minder.

De bedrijfsprofielen Snel & goedkoop, Uitgebalanceerd en Grondig bundelen deze router-modus met verdere beslissingen: bijvoorbeeld of gezamenlijk denken alleen wordt waargenomen of actief wordt uitgevoerd, of verificatie verplicht is en of Argo bij een mislukte poging sterker mag escaleren.

De drie niveaus van autonomie

De autonomie regelt niet wat Argo voor juist houdt, maar wanneer het daarvoor een mens nodig heeft.

Niveau	Gedrag
Veilig	Argo analyseert en plant. Wijzigingen blijven ter controle; voor schrijvende of risicovolle acties wordt gevraagd.
Uitgebalanceerd	Normale wijzigingen kunnen ontstaan in een geïsoleerde werkstand. Bij verwijderen, commando's, downloads, netwerktoegang of beschermde paden vraagt Argo verder na.
Volledig autonoom	De run werkt zonder gebruikelijke terugvragen. Harde veiligheids-, beleids- en budgetgrenzen blijven van kracht.

In de code zijn deze regels preciezer geïmplementeerd als readonly, confirm_write, auto_write en bypass. De drie niveaus maken ze bedienbaar; het projectbeleid blijft echter altijd de laatste instantie. Het kan bijvoorbeeld cloud-providers uitsluiten, alleen lokale modellen toestaan, netwerktoegang blokkeren, commando's beperken, secrets beschermen of een kostenlimiet stellen.

2. Het CEO-niveau maakt van de opdracht een plan

De gebruiker beschrijft eerst het doel in gewone taal. Het CEO-niveau van Argo ontvangt daarbij een beperkt projectoverzicht, de beschikbare modelcatalogus en relevante projectinformatie. Het kan bij open vragen eerst doorvragen of een plan opstellen.

Een plan bevat niet alleen een takenlijst. Elke taak krijgt een rol, een beschrijving, afhankelijkheden en benodigde vaardigheden – bijvoorbeeld coding, planning, qa_review of context_comprehension. Voor moeilijke taken kan ook een hogere moeilijkheid worden vermeld. Het CEO-niveau noemt daarbij niet star een model: het beschrijft het werk, de router beslist later per taak over het passende model.

Het plan blijft daarmee de menselijk leesbare afspraak over het voornemen, terwijl de uitvoering adaptief mag blijven.

3. Van het plan wordt een task-graph

Na goedkeuring van het plan verandert Argo de taken in een task-graph. Een knooppunt mag pas lopen wanneer zijn afhankelijkheden succesvol zijn afgerond. Onafhankelijke taken kunnen parallel lopen.

De scheduler sorteert gereedstaande knooppunten volgens een begrijpelijke nut-heuristiek: verwachte kwaliteit minus kosten-, tijd- en risicostraf. Bevindt een knooppunt zich op het kritieke pad, dan krijgt het bij gelijke stand voorrang, omdat het de totale duur van de run bepaalt.

Bij hoge onzekerheid of hoog risico kan Argo voor de bewerking een gezamenlijke denkmodus kiezen: meerdere perspectieven ontwikkelen benaderingen, bekritiseren elkaar en leveren een onderbouwde werkaanpak voor de worker. Of dit alleen wordt gelogd of echt wordt uitgevoerd, beslist het voor de run gekozen bedrijfsprofiel.

4. Voor elke taak: passende context, passende vaardigheden, passend model

Voordat een worker start, bouwt Argo een op rol en taak toegesneden context. Daartoe behoren relevante bestanden, afhankelijkheidsresultaten en – indien geactiveerd – een compact memory-pakket en geschikte skill-handleidingen. Argo neemt daarbij niet blind de volledige projectkennis in de prompt op. Memory en skills worden geselecteerd op relevantie, herkomst, actualiteit, kosten en veiligheidsstatus.

Dan kiest de model-router een model. Eerst worden kandidaten uitgesloten die niet bereikbaar zijn, onvoldoende contextvenster hebben, waarvan het contingent op is of die in strijd zijn met het actieve beleid. Van de overblijvende modellen beoordeelt Argo vier factoren:

• Vaardigheids-fit: Hoe goed is een model beoordeeld voor de benodigde skills? Bij meerdere skills wordt het gemiddelde bekeken.
• Kosten: Hoe duur is het verzoek – of bij actief kosten-routering het waarschijnlijk succesvolle resultaat?
• Modelniveau: Moeilijke, veiligheidskritieke, architectuur- en review-taken mogen een vlaggenschipniveau prefereren.
• Ervaringswaarden: Na voldoende echte resultaten vloeien de recente succes- en herhalingsratio van een model-/skill-combinatie mee in.

Voor de kostenberekening kan Argo de Expected Cost of Success gebruiken: directe prijs, verwachte herhalingen, verificatie-inspanning, mogelijke nabewerking en een kleine latentiestraf. Een goedkope enkele aanroep is dus niet automatisch de goedkoopste oplossing, als hij vaker faalt of nabewerking triggert.

Een expliciete modelaanbeveling wordt alleen geaccepteerd als hij beschikbaar, door het beleid toegestaan en groot genoeg voor de context is. Planning, delegatie en contextbegrip van het CEO-niveau gebruiken op hun beurt een sterk model dat speciaal voor deze drie vaardigheden is geselecteerd.

5. De worker bewerkt de taak in kleine, controleerbare stappen

Een worker werkt niet met een enkel antwoord. Hij doorloopt een beperkte ReAct-lus:

1. Het model stelt gestructureerde acties voor – bijvoorbeeld bestanden lezen, doorzoeken, tests uitvoeren of wijzigingen schrijven.
2. De executor controleert rechten, pad, commandorisico en actief beleid.
3. Argo voert alleen toegestane acties uit.
4. Resultaten, diffs en foutmeldingen vloeien als observatie terug naar het model.
5. Op basis hiervan corrigeert de worker zijn volgende stap of rondt de taak af.

Zo kan een agent bijvoorbeeld eerst de betrokken code lezen, dan een wijziging aanbrengen, een test uitvoeren en een testresultaat in de volgende beslissing betrekken. Het volledige verloop blijft zichtbaar in het runlog.

Ook de uitvoer zelf wordt gecontroleerd. Als een model ongeldige actie-JSON levert, kan Argo een beperkte reparatielus aanvragen. In de strikte modus wordt een blijvend foutieve uitvoer gecontroleerd afgewezen, in plaats van onduidelijke tekst als actie te interpreteren.

6. Bij fouten: gericht corrigeren in plaats van blind herhalen

Niet elke mislukte taak betekent dat de hele run is mislukt. De Orchestration Engine onderscheidt foutoorzaken en reageert gecontroleerd:

• Een tijdelijke fout kan binnen vaste grenzen opnieuw worden geprobeerd.
• Een hard verificatiebevinding levert zijn concrete bezwaar als opdracht voor de volgende poging.
• Bij geactiveerde cascadering neemt de volgende poging de inzichten van de vorige over, in plaats van bij nul te beginnen.
• Na een mislukte poging mag Argo een sterker model prefereren.
• Is een budget uitgeput, dan wordt geen dure gok gestart: het knooppunt eindigt met een gedocumenteerd deelresultaat of wordt zichtbaar geëscaleerd.

De knooppuntstrategie beslist uiteindelijk of een taak kan worden overgeslagen, gecontroleerd faalt of een gebruikersbeslissing nodig heeft. Afhankelijke taken ontvangen uitsluitend bevestigde deelresultaten. Daardoor wordt van een lokale fout geen stille fout die zich door de rest van het plan voortzet.

7. Na de implementatie: review, verificatie en een mogelijke verdere cyclus

Zijn de geplande taken bewerkt, dan controleert Argo de geïntegreerde stand vanuit meerdere gezichtspunten:

• De QA-agent mag bestanden lezen en test-commando's uitvoeren.
• De architectuuragent controleert de structuur lezend en blijft bewust zonder schrijfrechten.
• Deterministische verifiers kunnen tests, typecontrole of linting uitvoeren als objectieve orakels.
• Modelgebaseerde en deterministische bevindingen worden samengevoegd tot een algemeen oordeel.

Als QA, architectuur of een verplichte verifier problemen vindt, wijst Argo de bevindingen toe aan de betrokken taken. Alleen deze taken worden met de concrete feedback opnieuw bewerkt. Daarna volgt weer review en verificatie. Zonder consensusmodus is deze lus beperkt; in een uitdrukkelijk gekozen consensusmodus loopt hij door tot de gebruiker stopt of de controleurs akkoord gaan.

Een verifier in observatiemodus documenteert bevindingen, maar blokkeert niet. In de verplichte modus kan een harde bevinding voorkomen dat het resultaat als succesvol geldt. Zo kan de strengheid per bedrijfsprofiel worden gekozen, zonder de traceerbaarheid op te geven.

8. Pas als de stand is gecontroleerd: documentatie en CEO-samenvatting

Na een voltooide werk- en controlecyclus kan een documentatie-agent de wijzigingen vastleggen. Vervolgens stelt het CEO-niveau de samenvatting voor de gebruiker op: wat is afgerond? Wat bleef open? Welke controles liepen? Welke bestanden of beslissingen zijn betrokken?

Het resultaat is meer dan een chattekst. De run voert een gemeenschappelijke identificatie voor plan, modelkeuze, kosten, acties, verificatieoordelen, gebruikersonderbrekingen en latere patch-beslissingen. Daardoor is na te gaan hoe Argo tot een resultaat is gekomen.

9. Uiteindelijk beslist de mens over de echte workspace

Standaard werkt Argo in een geïsoleerde worktree. De wijzigingen liggen daar als patch, niet stil in het echte project. Afhankelijk van het autonomieniveau gebeurt daarna een van drie dingen:

• De patch blijft gereed voor acceptatie, gedeeltelijke overname, bewerking of verwerping.
• Een succesvolle patch wordt automatisch overgenomen.
• Bij conflicten met tussentijds gewijzigde bestanden stopt Argo zichtbaar; het overschrijft geen vreemde wijzigingen.

Een mislukte run wordt niet automatisch toegepast. Ook een zeer autonome configuratie heft het beleid niet op: secret-bescherming, commandoregelen, providergrenzen, budgetlimieten en noodzakelijke human gates blijven van kracht.

Wat de Orchestration Engine doet

De Orchestration Engine beslist niet alleen welk model als volgende antwoordt. Hij verbindt gebruikersintentie, instellingen, planning, parallelisatie, modelkeuze, gereedschapsgebruik, foutcorrectie, kwaliteitsborging en veilige overname tot een samenhangend verloop.

De maatstaf is niet "zo veel mogelijk agenten". Extra werk ontstaat alleen daar waar het gerechtvaardigd is: een sterker model voor een moeilijke architectuurbeslissing, een tweede denkbenadering bij onzekerheid, een gerichte retry na een verifier-bezwaar of een menselijke vrijgave voor een risicovol effect.

De koers is daarmee gezet.