Ontwerp de werklaag voordat je van model wisselt
De keuze: investeer in verwisselbare interfaces, niet in één voorkeursmodel
De verstandige keuze is om de agent rond expliciete werkafspraken te bouwen en het model daarachter vervangbaar te houden. Behandel het model als één uitvoerende component; leg buiten die component vast welke taak binnenkomt, welke context beschikbaar is, welke tools mogen worden gebruikt, welke uitkomst telt en wanneer de workflow stopt of escaleert. Daarmee maak je niet elk model gelijkwaardig, maar voorkom je dat promptgedrag, chatgeschiedenis en applicatielogica één onontwarbaar geheel worden. De bronnen onderbouwen vooral waarom die werklaag aandacht verdient. Het ACL-onderzoek beschrijft geheugen als een kritieke component waarmee LLM-agenten eerdere uitvoeringen kunnen opslaan en terughalen, en onderzoekt hoe keuzes in geheugenbeheer gedrag en langetermijnprestaties beïnvloeden. Het PMLR-werk over Agent Workflow Memory vertrekt vanuit de moeilijkheid van langlopende taken met complexe actietrajecten en onderzoekt herbruikbare workflows als sturing voor latere generaties. Dit is geen bewijs dat één universele architectuur of elke modelwissel werkt; het is wel reden om geheugen en workflowgedrag als afzonderlijke, toetsbare onderdelen te behandelen.
Maak state en routering observeerbaar
Zet duurzame informatie niet uitsluitend in de conversatiecontext van het model. Bewaar per workflow bijvoorbeeld een taak-ID, invoerversie, geselecteerde route, toegestane tools, relevante geheugenreferenties, tussenstatus, verwachte outputvorm en eindstatus. Een nieuw model krijgt dan dezelfde afgebakende invoer en levert output tegen hetzelfde contract. Houd ook vast welke informatie alleen tijdelijk in de sessie mag bestaan en welke informatie gecontroleerd moet worden bewaard. Routering is vervolgens een productiekeuze per taak, geen etiket op een model. Het onderzoek naar routing en cascading onderscheidt routing — één model per query — van cascading, waarbij steeds grotere modellen na elkaar kunnen draaien totdat een antwoord voldoet. Die passage wijst op mogelijke afwegingen tussen kosten en prestatie, maar levert voor uw eigen workload geen optimale route op. Kies daarom vooraf welke taakklasse, kwaliteitsdrempel, kostenlimiet en fallback u wilt meten; laat pas daarna een routeringsregel beslissen.
Gebruik een wisselregister en test één taakklasse tegelijk
Praktisch artefact: Een wisselregister per taakklasse met taakdoel, eigenaar, state-schema, invoer- en outputcontract, route, toetsset, acceptatiegrens en fallback. Gebruik dit register eerst voor één afgebakende taakklasse, zoals classificatie, samenvatting of een toolgestuurde stap. Draai dezelfde vastgelegde gevallen met de huidige en kandidaatroute. Controleer niet alleen de eindtekst, maar ook contractnaleving, toolaanroepen, statusovergangen en foutafhandeling. Leg de beslissing vast: behouden, beperken, terugrollen of uitbreiden. Zo is een modelwissel reproduceerbaar en kan de eigenaar uitleggen welke gedragsverandering is geaccepteerd. Beperking: de aangeleverde passages onderzoeken geheugen, workflowgeheugen en routering, maar beschrijven geen complete referentiearchitectuur of validatie voor uw specifieke modellen, data, tools, risico's en productie-eisen. Een geslaagde proef op één taakklasse bewijst daarom niet dat alle agenttaken veilig kunnen wisselen.
