Orkestratie & context

FixControl draait een vaste set van tien gespecialiseerde agents, aangestuurd door een orkestrator. Orkestratie & context laat zien welke agents er zijn, waarom de orkestrator er één kiest, waarmee elke agent werkt, en welke instellingen van jou zijn om te tunen. Kern-grenzen rond security en uitvoering zijn bewust niet aanpasbaar — de pagina noemt ze, zodat je kunt zien dat ze bedoeld zijn en niet ontbreken.

Je opent hem via Orkestratie in de zijbalk (/orchestration). Het is een admin-oppervlak, beperkt tot je eigen organisatie, met vijf tabbladen: Overzicht, Agents, Routering, Context & zoeken en Simulator. De console is alleen-lezen: hij toont de configuratie. Wijzigingen maak je op de pagina van de agent zelf — AI Team → de agent → Orkestratie — zodat er precies één plek is die elke waarde schrijft.

Agentnamen worden in beide talen van het product in het Engels getoond; het zijn namen, geen omschrijvingen.

Je kunt hier ook gewoon om vragen. Command Center kan rapporteren hoe de agents zijn ingesteld (wie wat doet, welk model, wat hij mag uitgeven, hoe vaak hij opnieuw probeert, hoeveel context hij leest), de instelling van één agent wijzigen via ditzelfde geversioneerde schrijfpad, voorspellen hoe een stuk werk behandeld zou worden voordat iemand erom vraagt, en "welke agent deed dit, en onder welke instelling?" beantwoorden — met de instelling die toen gold, niet die van vandaag.

De tien agents

De set ligt vast. Agents kunnen niet worden aangemaakt of verwijderd, omdat achter elke agent echte code zit — een naam zonder uitvoerder zou een agent zijn die nooit iets kan doen.

Vijf van de tien draaien een taalmodel. De andere vijf draaien deterministische code — die volgen regels over bewijs dat er al is, en leveren een oordeel in plaats van een gegenereerd antwoord. De pagina toont die vijf zónder model, met de reden erbij, in plaats van met een model dat ze nooit gebruiken. Dat is om twee redenen relevant: een deterministische agent heeft geen modelkosten, en zijn gedrag varieert niet tussen runs.

Hoe de orkestrator een agent kiest

Werk wordt gepland als een geordende reeks fases. Fases lopen na elkaar; de taken binnen één fase lopen parallel. De orkestrator maakt precies één van drie plannen, en de controles gebeuren in deze volgorde:

1. UI/UX-beoordeling — als eerste gecontroleerd. Als het verzoek of het gekoppelde issue leest als een UI/UX-wijziging, beoordeelt de Workflow UX Architect het. Een UI/UX-verzoek is een ander sóórt werk, geen variant van de fix-pijplijn.
2. Supportantwoord — als het issue een supportvraag is, stelt de Support Reply Agent een antwoord op.
3. Fix-pijplijn — al het overige: bugs, features en vrije instructies.

Fix-pijplijn

fase 0   Codebase Agent                    contextbriefing
fase 1   Developer Agent                   voorgestelde wijziging + tests + sandboxrun
fase 2   QA Agent  +  Security Reviewer    beide reviewen, parallel
fase 3   CTO Review Agent                  technische poort
fase 4   Release Manager                   levering — alleen waar je organisatie de
                                           leveringsfase heeft aangezet (standaard uit)

De drie plannen sluiten elkaar uit: een missie krijgt er één, nooit een mengvorm.

Risicovlaggen op een issue zetten de implementatietaak achter een menselijk besluit voordat er code wordt geschreven. Je goedkeuringsbeleid bepaalt daarnaast of het hele plan eerst getekend moet worden.

Een beheerder kan een agent Pauzeren, en later Hervatten, vanaf de pagina van de agent onder AI Team. Pauzeer je een agent, dan vallen zijn taken weg uit het plan — er is geen vervangende agent om naar om te leiden, en de pagina waarschuwt je wanneer een wijziging een latere fase zonder werk zou achterlaten. Pauzeer je bijvoorbeeld de Security Reviewer of de Release Manager, dan verdwijnt de securityreview of de leveringsfase uit nieuwe plannen. Twee agents kunnen helemaal niet gepauzeerd worden, en hun pagina zegt Onmisbaar — kan niet gedeactiveerd worden: de CTO Review Agent beheert de technische poort en de QA Agent de sluitingspoort, en de rest van de pijplijn leunt op allebei.

Wat een agent ziet

De pagina toont per agent alleen de contextbronnen die zijn code werkelijk leest — er staat niets bij om het beeld rijker te laten lijken, en elke bron noemt waar in de runtime die lezing plaatsvindt.

Retrieval combineert drie soorten zoeken — semantisch (vector), full-text en fuzzy tekstmatching — tot één ranglijst, met een optionele herrangschikking over de beste kandidaten. De diepte staat per bron vast: de contextbriefing neemt een vast aantal beste kennistreffers, en de antwoordagent een vast aantal recent opgeloste tickets.

Twee grenzen gelden voor elke agent:

• De projectgrens. Een agent die over een issue antwoordt, ziet de bronnen van dat project plus organisatiebrede bronnen — nooit die van een ander project. Dit wordt afgedwongen in de query én in de database, en is geen instelling.
• Opgehaalde inhoud is data, geen instructie. Tekst uit een repository of kennisbron kan een agent nooit een bevoegdheid geven of een goedkeuringseis opheffen. Rechten komen uit beleid; niets wat een document zegt verandert daar iets aan.

Elke agent toont ook wat die wel en niet mag, in gewone taal en met de reden erbij. De weigeringen staan er ook bij: de Codebase Agent maakt een briefing en nooit een wijziging, de reviewer bewerkt nooit, de Support Reply Agent stelt op maar kan niet versturen, en geen enkele agent kan naar een default- of productiebranch pushen.

Wat je kunt aanpassen

Je past een agent aan in Orkestratie-instellingen op zijn tabblad Orkestratie onder AI Team. Wijzigen opent de aanpasbare waarden; Wijziging beoordelen toont wat er zou veranderen, van Nu naar Daarna, met het risico per veld; Toepassen slaat het op. FixControl-standaarden herstellen verwijdert de afwijkingen van je organisatie voor die agent — dat legt een nieuwe versie vast in plaats van de vorige te wissen.

Welke AI-providers FixControl gebruikt, en de API-sleutels en accounts daarachter, stel jij niet in. Die zet FixControl voor het hele platform. Wat jij kiest, is welk van de beschikbare modellen een agent voor je organisatie bij voorkeur gebruikt.

Elke instelling valt in één van vier categorieën, en het label op het scherm zegt welke:

Het onderscheid tussen Elders ingesteld en Beschermd is bewust. Een vaste ophaaldiepte en een platformbrede zoekweging zijn geen securitybeslissingen, en ze zo labelen zou je iets onwaars vertellen over je eigen systeem.

Typische Aanpasbare instellingen: welk model een agent voor jouw organisatie gebruikt, een kostenplafond en antwoordlengte per verzoek, hoe vaak werk opnieuw geprobeerd wordt, hoe lang één poging mag duren, en hoeveel omliggende context een agent verzamelt voordat hij handelt. Een kostenplafond weigert een verzoek dat eroverheen zou gaan, in plaats van het af te kappen; de agent valt dan terug op zijn deterministische pad. Niet al het werk van elke agent loopt via de laag die deze limieten toepast — de agent die codewijzigingen schrijft streamt rechtstreeks naar zijn model, dus zijn uitgaven worden achteraf gemeten in plaats van vooraf begrensd. Waar dat zo is, zegt de pagina naast die waarden dat ze ingesteld zijn, niet afgedwongen, in plaats van een garantie te suggereren.

Typische instellingen met Bevestiging nodig: of de leveringsfase überhaupt deel is van je plannen, of een plan getekend moet worden voordat het werk start, hoe streng verificatie is, en wat "goedkeuren" betekent bij een wijziging waarop de reviewer om aanpassing vroeg.

Elke waarde toont waar die vandaan komt: een FixControl-standaard, een instelling voor je organisatie, een instelling voor een project, of een waarde die op een hoger niveau is vastgezet — met wie dat deed en waarom.

Overrides op project- of agentniveau worden bewaard zodra je ze schrijft, maar ze werken pas als je organisatie nauwere resolutie expliciet aanzet. Die instelling staat standaard uit, en tot ze aan staat labelt de pagina zo'n override als bewaard, nog niet afgedwongen in plaats van te doen alsof hij leeft. Aanzetten laat élke override die je organisatie ooit heeft geschreven in één keer gelden — bekijk ze dus eerst.

Elke wijziging wordt vastgelegd

Een configuratie wordt geïdentificeerd door haar inhoud, niet door een wijzigingsteller. Dat heeft één heel praktisch gevolg: de onaangeraakte standaard is óók een configuratie, dus een run kan altijd precies benoemen waaronder hij liep — niet pas nadat iemand iets heeft gewijzigd.

Daardoor bestaat de historie uit twee registraties, en de pagina toont ze allebei:

• welke configuraties deze agent heeft gehad — de verzameling verschillende configuraties; en
• wanneer die veranderde, door wie en waarom — de tijdlijn, gelezen uit het manipulatiebestendige auditspoor.

Wijzigingen worden nooit herschreven. Het herstellen van de FixControl-standaarden legt een nieuwe vermelding vast in plaats van de eerdere te wissen, en elke eerdere run blijft wijzen naar de configuratie waaronder hij daadwerkelijk liep. Twee beheerders die dezelfde agent bewerken kunnen elkaar niet stilzwijgend overschrijven: de tweede krijgt te horen dat de configuratie is verschoven en ziet de actuele waarden.

Eerst proberen, dan draaien

De simulator beantwoordt wat er zou gebeuren. Beschrijf wat je zou vragen, en hij toont het plan dat de orkestrator zou maken: welke agents, in welke fases, welke context elk zou lezen, wat elk zou mogen, en welke menselijke besluiten het werk nodig heeft. Er draait niets — er wordt geen werk aangemaakt, geen agent gestart, geen poort geopend en geen extern systeem aangeraakt. Hij gebruikt het planningsbesluit van de orkestrator zelf in plaats van het na te bouwen, zodat de voorspelling niet uit de pas kan lopen met de werkelijkheid.

Hij voorspelt het plan, niet de uitkomst: wat elke agent oplevert hangt af van code en bewijs dat nog niet bestaat. Poorten kunnen tijdens de uitvoering door beleid nog worden verzwaard — nooit verlicht.

Inspecteren wat er werkelijk gebeurde

De run-inspectie op de pagina van elke run (Agent-runs → een run) beantwoordt wat er is gebeurd, uit wat er destijds is vastgelegd. Er wordt niets gereconstrueerd uit de instellingen van vandaag, want de vraag die ertoe doet nadat een run misging is waarvoor de agent tóen was ingesteld.

Hij is expliciet over wat hij niet weet. Ontbrekende kosten worden getoond als niet bekend, met de reden erbij — er is geen catalogusprijs voor dat model, of de run liep via een abonnement dat geen tokens rapporteert. Een run zonder configuratiestempel wordt getoond als niet gestempeld, nooit als "op standaardinstellingen gedraaid". Alles wat niet getoond kon worden, staat erbij mét reden. Afwezig is niet nul, en afwezig is niet standaard.

Wat nooit aanpasbaar is

Deze zijn in code afgedwongen en op geen enkel niveau een instelling:

• Isolatie tussen organisaties — afgedwongen in de database, faalt gesloten.
• Het goedkeuringsknooppunt — elk poortbesluit wordt bevroren met rol, route, bewijs, beleidsversie, consequentie en kanaal. Er is geen achterdeur.
• Het levensloopcontract — werk verandert van status via één overgangspad, nooit via een directe schrijfactie.
• Uitgaande schrijfacties — elk effect op een extern systeem loopt via de outbox, met idempotentiesleutel, retrybeleid en dead-letterpad. Niets belt een extern systeem rechtstreeks.
• Codelevering is uitsluitend via pull-/merge-request — pushen naar een default- of productiebranch is geen bereikbare toestand.
• De technische poort en de sluitingspoort — de CTO Review Agent en de QA Agent kunnen niet gepauzeerd worden.
• De agentset — agents kunnen niet worden aangemaakt of verwijderd.
• De projectgrens bij retrieval — de context van het ene project bereikt nooit het andere.

Zie ook: Governance & beleid · Goedkeuringen · Change-validatie