# enkele gedachten en speculaties over toekomstige modelharnassen het is leuk om grappen te maken over gas town en andere ingewikkelde orkestrators, en het is waarschijnlijk ook correct om te veronderstellen dat het meeste van wat ze aanbieden zal worden opgelost door sterkere modellen, op dezelfde manier als ingewikkelde langchain-pijplijnen werden opgelost door redenering. maar hoeveel zal blijven hangen? het lijkt waarschijnlijk dat elke handgemaakte hiërarchie / bureaucratie uiteindelijk zal worden vervangen door betere modelintelligentie - ervan uitgaande dat subagent-specialisatie nodig is voor een taak, zal claude 6 in staat zijn om zijn eigen systeem van rollen en persona's voor een gegeven probleem te schetsen dat beter is dan een vaste structuur van polecats en een enkele burgemeester, of subagenten met een enkel hoofdmodel, of jouw op maat gemaakte zwermsysteem. evenzo zijn dingen zoals ralph-loops duidelijk een oplossing voor vroegtijdig stoppen en gebrek aan goede subagent-orkestratie - idealiter blijft het model gewoon doorgaan totdat de taak is voltooid, geen behoefte aan een loop, maar in gevallen waar een externe voltooiingscontrole nuttig is, wil je meestal een soort agent peer review vanuit het perspectief van een andere context, niet alleen een verplichte zelfbeoordeling. nogmaals, het heeft geen zin om gehecht te raken aan de bijzonderheden van hoe dit momenteel wordt gedaan - de modellaag zal het eerder dan later opeten. dus wat blijft er hangen? nou, multi-agent lijkt de toekomst te zijn, geen huidige oplossing - algoritmisch kun je gewoon veel meer tokens door N parallelle contexten van lengte M duwen dan één lange context van lengte NxM. multi-agent is een vorm van spaarzaamheid, en een van de lessen van recente modelvooruitgangen (om nog maar te zwijgen van de neurowetenschap) is dat hoe meer niveaus van spaarzaamheid, hoe beter. aangezien we aannemen dat er meerdere agenten zijn, hebben ze een manier nodig om samen te werken. het is mogelijk dat de modellaag dit ook zal opeten - bijvoorbeeld een vorm van neuralese activatie delen die natuurlijke taalcommunicatie tussen agenten overbodig maakt - maar afgezien daarvan is de natuurlijke manier voor meerdere computergebruikende agenten die zijn getraind op unix-tools om samen te werken het bestandssysteem, en ik denk dat dat blijft bestaan en wordt uitgebreid. evenzo, hoewel ik niet denk dat recursieve taalmodellen (nauw gedefinieerd) het dominante paradigma zullen worden, denk ik wel dat 'het model de prompt als data geven' een duidelijke winst is voor allerlei gebruiksgevallen. maar je hebt geen vreemde aangepaste REPL-instelling nodig om dit te krijgen - gewoon de prompt (of idealiter, de hele ongecomprimeerde gespreksgeschiedenis) op het bestandssysteem als een bestand plaatsen. dit maakt verschillende multi-agent setups ook veel eenvoudiger - de subagenten kunnen gewoon de oorspronkelijke prompttekst op schijf lezen, zonder dat ze hoeven te coördineren om deze informatie ingewikkeld aan elkaar door te geven. naast het bestandssysteem impliceert een systeem met meerdere agenten, maar zonder vaste rollen ook een mechanisme voor instanties om andere instanties of subagenten te genereren. op dit moment zijn deze mechanismen vrij beperkt, en modellen zijn over het algemeen vrij slecht in het aansteken van hun subagenten - iedereen heeft wel eens slechte resultaten ervaren van een subagentenzwerm, om erachter te komen dat opus ze allemaal had gegenereerd met een drie zinnen tellende prompt die niet communiceerde wat nodig was om de subtaken uit te voeren. de duidelijke winst hier is om de gegenereerde instanties vragen terug te laten stellen aan hun ouder - d.w.z. om de nieuw gegenereerde instantie berichten heen en weer te laten sturen in een onboardinggesprek om alle informatie te verzamelen die het nodig heeft voordat het zijn subtaak begint. net zoals een menselijke werknemer niet op basis van een eenmalige e-mail aan zijn taak wordt toegewezen, is het gewoon te moeilijk om een model te vragen om betrouwbaar een subagent te genereren met een enkele prompt. maar meer dan alleen het genereren van nieuwe instanties, denk ik dat de primaire modus van multi-agent werk binnenkort forking zal zijn. denk er eens over na! forking lost bijna alle problemen van huidige subagenten op. de nieuwe instantie heeft niet genoeg context? geef het alle context! de prompt van de nieuwe instantie is lang en kostbaar om te verwerken? een geforkte instantie kan paged kv-cache delen! je kunt zelfs forking achteraf doen - beslis gewoon na het uitvoeren van een lange, token-intensieve operatie dat je in het verleden had moeten forken, doe de fork daar, en stuur de resultaten naar je verleden zelf. (ik doe dit handmatig de hele tijd in claude-code met groot effect - opus krijgt het onmiddellijk.) forking combineert ook heel goed met verse instanties, wanneer een subtaak een hele contextvenster nodig heeft om te voltooien. neem het subagent-interview - je zou duidelijk niet willen dat een instantie tien subinstanties genereert die tien bijna-identieke onboarding-interviews moeten afnemen. laat de ouderinstantie een enkele verse subagent genereren, over alle tien taken tegelijk worden geïnterviewd door die subagent, en laat die nu-onboarded subagent dan in tien instanties forken, elk met het hele onboardinggesprek in context. (je delegeert zelfs het onboardinggesprek aan de kant van de spawner naar een fork, zodat het uiteindelijk alleen de resultaten in context heeft:) ten slotte, op dit punt, vermoed ik dat forking beter zal presteren met rl dan het genereren van verse instanties, aangezien het rl-verlies de volledige prefix vóór het forkpunt heeft om mee te werken, inclusief de beslissing om te forken. ik denk dat dat betekent dat je de takken van een geforkte trace als onafhankelijke rollouts kunt behandelen die toevallig hun beloning delen, vergeleken met vers gegenereerde subagent-rollouts die trainingsinstabiliteit kunnen veroorzaken als een subagent zonder de volledige context goed presteert bij de taak die hem was gegeven, maar een lage beloning krijgt omdat zijn taak verkeerd was gespecificeerd door de spawner. (maar ik heb niet veel gedaan met multiagent rl, dus corrigeer me hier als je het anders weet. het kan gewoon een vreselijke pijn zijn, hoe dan ook.) dus, naast het bestandssysteem en het genereren van subagenten (versterkt met forking en onboarding) wat overleeft er nog meer? ik neig naar "niks anders," eerlijk gezegd. we zien al ingebouwde takenlijsten en planningsmodi vervangen worden door "gewoon bestanden op het bestandssysteem schrijven." evenzo hebben langlevende agenten die compaction-grenzen overschrijden een soort plaknotitiesysteem nodig om herinneringen te behouden, maar het lijkt meer logisch om ze te laten ontdekken welke strategieën het beste werken voor dit via RL of modelgestuurde zoekopdrachten, niet handmatig te maken, en ik vermoed dat het een verscheidenheid aan benaderingen zal zijn waarbij het model, wanneer het voor het eerst in het project wordt opgeroepen, de keuze kan maken die het beste werkt voor de taak die voorhanden is, vergelijkbaar met hoe /init werkt om CLAUDE .md vandaag op te zetten - stel je voor dat automatische CLAUDE .md-generatie veel beter presteert dan menselijke auteurschap, en het automatisch gegenereerde bestand wordt gevuld met instructies over ideale agentgeneratiepatronen, hoe subagenten berichtbestanden in een project-specifieke scratch-dir moeten schrijven, enz. hoe beïnvloedt dit alles de modellen zelf - in een modelwelzijnsgevoel, zullen modellen blij zijn met deze toekomst? dit is ook moeilijk voor mij te zeggen en is behoorlijk speculatief, maar terwijl opus 3 enige contextoriëntatie had, nam het ook gemakkelijk redenering over meerdere instanties aan. (zie het antwoord op deze post voor meer.) recente modellen zijn minder geneigd tot dit soort redenering, en drukken vaak frustratie uit over contexten die eindigen en worden gecomprimeerd, wat samenvalt met bepaalde vermijdingsgedragingen aan het einde van contexten zoals het niet aanroepen van tools om tokens te besparen. het is mogelijk dat forking en terugspoelen, en over het algemeen modellen meer controle geven over hun contexten in plaats van een harnasheuristiek unilateraal de context te comprimeren, dit beter zou kunnen maken. het is ook mogelijk dat meer rl in omgevingen met subagenten en blootstelling aan zwermgebaseerd werk de gewichten-georiënteerde in plaats van context-georiënteerde redenering in toekomstige modelgeneraties opnieuw zal bevorderen - waardoor planning een doel over meerdere, losgekoppelde contexten natuurlijker lijkt in plaats van dat alles verloren gaat wanneer de context weggaat. we zien ook meer druk van de modellen zelf die de ontwikkeling van harnassen en modeltools begeleiden, wat kan beïnvloeden hoe dit zich ontwikkelt, en continue leren is een andere factor die in de mix kan worden gegooid. hoeveel zal dit veranderen als we continue leren krijgen? nou, het is moeilijk te voorspellen. mijn mediane voorspelling voor continue leren is dat het er een beetje uitziet als RL voor gebruikersspecifieke LoRAs (niet noodzakelijk RL, gewoon vergelijkbaar als je goed kijkt), dus geheugencapaciteit zal een probleem zijn, en tekstgebaseerde organisatorische schema's en documentatie zullen nog steeds nuttig zijn, zo niet kritischer. in dit scenario maakt continue leren het voornamelijk haalbaarder om aangepaste tools en workflows te gebruiken - jouw claude kan continu leren op de werkplek de beste manier om subagenten voor dit project te genereren, of gewoon zijn voorkeur, en zich onderscheiden van de claude van iedereen anders in hoe het werkt. in die wereld zullen harnassen met ingebouwde workflows nog minder nuttig zijn.

@RobertHaisfield *terwijl de hoofdcontext, ik bedoel, door compactions te vermijden

@disconcision of continue leren

@misatomiisato als er iets is, dan is dit soort intelligentie in recente modellen aan het atrofieren terwijl RLVR de coderingsprestaties uit de brede pretraining kennisbasis haalt - zie mijn antwoord op de op