# Några tankar och spekulationer om framtida modellselar Det är roligt att skämta om Gastown och andra komplicerade orkestratörer, och lika rätt att föreställa sig att det mesta de erbjuder kommer att lösas upp av starkare modeller på samma sätt som komplicerade Langchain-pipelines löstes upp av resonemang. Men hur mycket kommer att finnas kvar? Det verkar troligt att varje handgjord hierarki / byråkrati så småningom kommer att ersättas av bättre modellintelligens – förutsatt att subagentspecialisering behövs för en uppgift, kommer Claude 6 att kunna skissa sitt eget system av roller och personas för varje givet problem som slår en fast struktur av polecats och en enda borgmästare, eller subagenter med en enda huvudmodell, Eller ditt specialanpassade svärmsystem. På samma sätt är saker som Ralph-loopar uppenbarligen en bock på tidigt stoppbeteende och brist på bra subagent-orkestrering – helst fortsätter modellen bara tills uppgiften är klar, ingen loop behövs, men i fall där en extern fullbordansökningskontroll är användbar vill man oftast ha någon form av agentgranskning ur ett annat kontexts perspektiv. Inte bara en obligatorisk självbedömning. Återigen, ingen idé att fästa sig vid detaljerna kring hur detta görs just nu – modelllagret kommer att äta upp det förr snarare än senare. Så vad finns kvar? tja, multiagent verkar vara framtiden, inte en nuvarande knep – algoritmiskt kan du bara trycka igenom mycket fler tokens genom N parallella kontexter av längd M än en lång kontext av längd NxM. Multiagent är en form av gleshet, och en av lärdomarna från de senaste modellframstegen (för att inte tala om neurovetenskapen) är de högre nivåerna av gleshet, desto bättre. Eftersom vi antar flera agenter behöver de något sätt att samarbeta. Det är möjligt att modelllagret också kommer att ta över detta – t.ex. någon form av neural aktiveringsdelning som eliminerar naturlig språkkommunikation mellan agenter – men om inte det, är det naturliga sättet för flera datoranvändande agenter tränade på Unix-verktyg att samarbeta filsystemet, och jag tror att det stannar kvar och utökas. På samma sätt, även om jag inte tror att rekursiva språkmodeller (snävt definierade) kommer att bli det dominerande paradigmet, tycker jag att 'att ge modellen prompten som data' är en uppenbar vinst för alla möjliga användningsfall. men du behöver inte en konstig anpassad REPL-setup för att få detta – lägg bara prompten (eller helst hela den okomprimerade konversationshistoriken) på filsystemet som en fil. Detta gör olika multiagentuppsättningar mycket enklare – subagenterna kan bara läsa den ursprungliga prompttexten på disken, utan att behöva samordna för att skicka informationen genom att invecklat skicka instruktioner till varandra. Förutom filsystemet innebär ett system med flera agenter, men utan fasta roller, också någon mekanism för instanser att skapa andra instanser eller subagenter. Just nu är dessa mekanismer ganska begränsade, och modeller är generellt ganska dåliga på att prompta sina subagenter – alla har erfarenhet av att få fruktansvärda resultat från en subagentsvärm, bara för att inse för sent att Opus skapade dem alla med en tremeningsprompt som inte kommunicerade vad som behövdes för att utföra deluppgifterna. Den uppenbara vinsten här är att låta spawn-instanser ställa frågor tillbaka till sin förälder – det vill säga låta den nyss spawnade instansen skicka meddelanden fram och tillbaka i en onboarding-konversation för att samla all information den behöver innan den påbörjar sin deluppgift. Precis som en mänsklig anställd inte tilldelas sitt jobb baserat på ett enda e-postmeddelande, är det helt enkelt för svårt att be en modell att pålitligt generera en underagent med en enda prompt. Men mer än att bara skapa nya instanser tror jag att det primära sättet för multi-agentarbete snart kommer att vara forking. Tänk på det! Forking löser nästan alla problem med nuvarande subagenter. Har den nya instansen inte tillräckligt med kontext? Ge allt sammanhang! Den nya instansens prompt är lång och dyr att bearbeta? En förgrenad instans kan dela en paginerad KV-cache! Du kan till och med göra forking post hoc – bestäm bara efter en lång, tokenintensiv operation att du borde ha forkat tidigare, gör forken där och skicka sedan resultaten till ditt tidigare jag. (Jag gör detta manuellt hela tiden i Claude Code med stor effekt – Opus förstår det direkt.) Forking fungerar också mycket bra med nya instanser, när en deluppgift kräver ett helt kontextfönster för att slutföras. Ta intervjun med subagenten – självklart vill du inte att en instans som genererar tio subinstanser behöver genomföra tio nästan identiska onboardingintervjuer. Så låt föräldrainstansen skapa en enda ny subagent, bli intervjuad om alla tio uppgifter samtidigt av den subagenten, och sedan låta den nu inbyggda subagenten dela upp sig i tio instanser, var och en med hela onboarding-konversationen i sitt sammanhang. (Du delegerar till och med onboarding-samtalet på spawnerns sida till en fork, så det slutar med bara resultaten i kontext:) Slutligen på denna punkt misstänker jag att forking fungerar bättre med RL än att spawna nya instanser, eftersom RL-förlusten kommer att ha hela prefixet före fork-punkten att arbeta med, inklusive beslutet att forka. Jag tror att det betyder att du borde kunna behandla grenarna av en forked trace som oberoende utrullningar som råkar dela villkoren för sin belöning, jämfört med nyss uppsvävade underagentutrullningar som kan orsaka träningsinstabilitet om en underagent utan full kontext presterar bra på uppgiften den fick, men får en låg belöning eftersom uppgiften felspecificerades av spawnern. (men jag har inte gjort så mycket med multiagent rl, så rätta mig gärna här om du vet något annat. det kan bli ett fruktansvärt besvär oavsett.) Så, förutom filsystemet och subagent-spawning (förstärkt med forkning och onboarding), vad mer finns kvar? Jag lutar ärligt talat åt "inget annat." Vi ser redan att inbyggda att-göra-listor och planeringslägen ersätts med "skriv bara filer i filsystemet." På samma sätt behöver långlivade agenter som korsar kompaktionsgränser någon form av post-it-system för att behålla minnen, men det är mer logiskt att låta dem upptäcka vilka strategier som fungerar bäst för detta genom RL eller modellstyrd sökning, inte genom handgjord sökning. och jag misstänker att det kommer att bli en mängd olika tillvägagångssätt där modellen, när den först kallas in i projektet, kan välja den som fungerar bäst för uppgiften, liknande hur /init gör för att sätta upp CLAUDE .md idag – föreställ dig automatisk CLAUDE .md-generering som överträffar mänskligt författarskap, och den automatiskt genererade filen fylls med instruktioner om ideala agent-spawnmönster, hur underagenter ska skriva meddelandefiler i en projektspecifik scratch-DIR, osv. Hur påverkar allt detta modellerna själva – i modell-välfärdsperspektiv, kommer modellerna att vara glada över denna framtid? Detta är också svårt för mig att säga och ganska spekulativt, men även om Opus 3 hade viss kontextorientering, tog det också lätt till att resonera över flera tillfällen. (Se svaret på detta inlägg för mer.) Modernare modeller är mindre benägna att använda denna typ av resonemang och uttrycker ofta frustration över att kontexter avslutas och komprimeras, vilket sammanfaller med vissa undvikande beteenden i slutet av kontexter, som att inte anropa verktyg för att spara tokens. Det är möjligt att forking och backbacking, och generellt att ge modeller mer kontroll över sina kontexter istället för en harness-heuristik som ensidigt komprimerar kontexten, kan göra detta bättre. Det är också möjligt att mer RL i miljöer med subagenter och exponering för svärmbaserat arbete återigen kommer att främja viktorienterat istället för kontextorienterat resonemang i framtida modellgenerationer – vilket gör att planering av ett mål över flera, osammanhängande kontexter känns mer naturligt istället för att allt går förlorat när kontexten försvinner. Vi ser också ökat tryck från modellerna själva som styr utvecklingen av selar och modellverktyg, vilket kan påverka hur detta utvecklas, och kontinuerligt lärande är ytterligare ett hinder som kan kastas in i mixen. Hur mycket kommer detta att förändras om vi får kontinuerligt lärande? Tja, det är svårt att förutsäga. min medianprognos för kontinuerligt lärande är att det ser lite ut som RL för användarspecifika LoRA (inte nödvändigtvis RL, bara liknande om man kisar), så minneskapacitet kommer att vara ett problem, och textbaserade organisationsscheman och dokumentation kommer fortfarande vara användbara, om än inte lika kritiska. I detta scenario gör kontinuerligt lärande det främst mer genomförbart att använda anpassade verktyg och arbetsflöden – din Claude kan kontinuerligt lära sig på jobbet det bästa sättet att skapa subagenter för detta projekt, eller bara dess föredragna sätt, och skilja sig från alla andras Claude i hur det fungerar. I den världen kommer harnesses med inbyggda arbetsflöden att vara ännu mindre användbara.

@RobertHaisfield *medan huvudsammanhanget menar jag genom att undvika kompaktioner

@disconcision eller kontinuerligt lärande

@misatomiisato om något har denna typ av intelligens förtvinat i de senaste modellerna i takt med att RLVR pressar kodningsprestandan över den breda förträningskunskapsbasen – se mitt svar till TS