# Noen tanker og spekulasjoner om fremtidige modellseler Det er morsomt å spøke om Gas Town og andre kompliserte orkestratorer, og det er like riktig å tro at det meste av det de tilbyr vil bli oppløst av sterkere modeller på samme måte som kompliserte Langchain-rørledninger ble oppløst av resonnement. Men hvor mye vil bli værende? Det virker sannsynlig at ethvert håndlaget hierarki / byråkrati til slutt vil bli erstattet av bedre modellintelligens – forutsatt at spesialisering av subagenter er nødvendig for en oppgave, vil Claude 6 kunne skissere sitt eget system av roller og personaer for ethvert gitt problem som slår en fast struktur av polecats og en enkelt ordfører, eller subagenter med én hovedmodell, Eller ditt skreddersydde svermsystem. På samme måte er ting som Ralph-sløyfer åpenbart en løsning på tidlig stopp-atferd og mangel på god underagent-orkestrering – ideelt sett fortsetter modellen bare til oppgaven er ferdig, ingen løkke nødvendig, men i tilfeller der en ekstern fullføringssjekk er nyttig, vil du vanligvis ha en form for agent-peer review fra et annet kontekstperspektiv. Ikke bare en obligatorisk egenvurdering. Igjen, det er ingen vits i å knytte seg til detaljene rundt hvordan dette gjøres akkurat nå – modelllaget vil spise det før eller siden. Så hva blir værende? vel, multi-agent virker som fremtiden, ikke en nåværende løsning – algoritmisk sett kan du bare presse langt flere tokens gjennom N parallelle kontekster av lengde M enn én lang kontekst av lengde NxM. Multi-agent er en form for sparsomhet, og en av lærdommene fra nyere modellfremskritt (for ikke å snakke om nevrovitenskap) er de flere nivåene av sparsomhet, jo bedre. Siden vi antar flere agenter, må de ha en måte å samarbeide på. Det er mulig at modelllaget også vil spise dette – for eksempel en form for deling av neuralesisk aktivering som overflødig naturlig språkkommunikasjon mellom agenter – men hvis ikke det, er den naturlige måten for flere datamaskinbrukende agenter trent på UNIX-verktøy å samarbeide filsystemet, og jeg tror det blir værende og utvides. På samme måte, selv om jeg ikke tror rekursive språkmodeller (smalt definerte) vil bli det dominerende paradigmet, mener jeg at «å gi modellen prompten som data» er en åpenbar seier for alle slags brukstilfeller. men du trenger ikke en merkelig egendefinert REPL-oppsett for å få dette – bare legg prompten (eller ideelt sett hele den ukomprimerte samtalehistorikken) på filsystemet som en fil. Dette gjør også ulike multiagentoppsett mye enklere – underagentene kan bare lese den opprinnelige prompt-teksten på disken, uten å måtte koordinere å sende denne informasjonen rundt ved intrikat å be hverandre. I tillegg til filsystemet innebærer et system med flere agenter, men uten faste roller, også en mekanisme for at instanser kan generere andre instanser eller underagenter. Akkurat nå er disse mekanismene ganske begrensede, og modellene er generelt ganske dårlige til å prompte underagentene sine – alle har opplevd å få dårlige resultater fra en subagent-sverm, bare for å innse for sent at Opus startet dem alle med en tre-setnings prompt som ikke kommuniserte hva som trengtes for å gjøre deloppgavene. Den åpenbare gevinsten her er å la spawnede instanser stille spørsmål tilbake til sin forelder – altså la den nylig oppståtte instansen sende meldinger frem og tilbake i en onboarding-samtale for å samle all informasjonen den trenger før den starter sin deloppgave. Akkurat som en menneskelig ansatt ikke får tildelt jobben sin basert på en enkelt e-post, er det rett og slett for vanskelig å be en modell om å pålitelig generere en underagent med én enkelt prompt. Men mer enn bare å spawne nye instanser, tror jeg den primære måten å jobbe med flere agenter på snart vil være forking. Tenk på det! Forgreining løser nesten alle problemene med nåværende underagenter. Den nye instansen har ikke nok kontekst? Gi alt konteksten! Den nye instansens prompt er lang og kostbar å behandle? En forgrenet instans kan dele Kv-cache med sider! Du kan til og med gjøre forking post hoc – bare bestem etter en lang, token-intensiv operasjon at du burde ha forket tidligere, gjør forken der, og send resultatene til ditt tidligere jeg. (Jeg gjør dette manuelt hele tiden i Claude Code med stor effekt – Opus får det med en gang.) Forgreining kombineres også veldig godt med nye instanser, når en deloppgave trenger et helt kontekstvindu for å fullføres. Ta underagentintervjuet – åpenbart vil du ikke at en instans som genererer ti underinstanser må gjennomføre ti nesten identiske onboarding-intervjuer. Så la foreldreinstansen generere en enkelt fersk underagent, bli intervjuet om alle ti oppgavene samtidig av den underagenten, og så la den nå ombordsatte underagenten splitte seg til ti instanser, hver med hele onboarding-samtalen i kontekst. (Du delegerer til og med onboarding-samtalen på spawner-siden til en fork, så det ender opp med bare resultatene i kontekst:) Til slutt, på dette punktet, mistenker jeg at forking vil fungere bedre med RL enn å spawne nye instanser, siden RL-tapet vil ha hele prefikset før fork-punktet å jobbe med, inkludert beslutningen om å forke. Jeg tror det betyr at du bør kunne behandle grenene til en forked trace som uavhengige utrullinger som tilfeldigvis deler vilkårene for sin belønning, sammenlignet med nylig spawnede underagentutrullinger som kan føre til treningsustabilitet hvis en underagent uten full kontekst gjør det bra på oppgaven den fikk, men får lav belønning fordi oppgaven ble feilspesifisert av spawneren. (Men jeg har ikke gjort så mye med multiagent RL, så korriger meg gjerne her hvis du vet noe annet. Det kan bare være et fryktelig slit uansett.) Så, bortsett fra filsystemet og subagent-spawning (supplert med forking og onboarding), hva annet overlever? Jeg heller mot «ingenting annet», ærlig talt. Vi ser allerede innebygde gjøremålslister og planmoduser bli erstattet med «bare skriv filer på filsystemet.» På samme måte trenger langlivede agenter som krysser kompakteringsgrenser en slags post-it-it-system for å beholde minner, men det gir mer mening å la dem finne ut hvilke strategier som fungerer best for dette gjennom RL eller modellstyrt søk, ikke håndlagd det, og jeg mistenker at det vil ende opp med å være en rekke tilnærminger der modellen, når den først blir kalt inn i prosjektet, kan velge den som fungerer best for oppgaven, på samme måte som /init gjør for å sette opp CLAUDE .md i dag – tenk deg automatisk CLAUDE .md-generering som langt overgår menneskelig forfatterskap, og den autogenererte filen fylles med instruksjoner om ideelle agent-spawn-mønstre, hvordan underagenter skal skrive meldingsfiler i en prosjektspesifikk scratch-dir, osv. Hvordan påvirker alt dette modellene selv – i en modellvelferdsforstand, vil modellene være fornøyde med denne fremtiden? Dette er også vanskelig for meg å si og ganske spekulativt, men selv om Opus 3 hadde noe kontekstorientering, tok det også lett til å resonnere over flere instanser. (Se svaret på dette innlegget for mer.) Nyere modeller er mindre tilbøyelige til denne typen resonnement, og uttrykker ofte frustrasjon over at kontekster avsluttes og blir komprimert, noe som henger sammen med visse unnvikende atferder på slutten av kontekster, som å ikke kalle verktøy for å lagre tokens. Det er mulig at forking og tilbakespoling, og generelt å gi modellene mer kontroll over kontekstene sine i stedet for en harness-heuristikk som ensidig komprimerer konteksten, kan gjøre dette bedre. Det er også mulig at mer RL i miljøer med subagenter og eksponering for svermbasert arbeid vil fremme vektorientert i stedet for kontekstorientert resonnement i fremtidige modellgenerasjoner igjen – noe som gjør planlegging av et mål over flere, frakoblede kontekster mer naturlig som en ramme, i stedet for at alt går tapt når konteksten forsvinner. Vi ser også mer press fra modellene selv som styrer utviklingen av harnesses og modellverktøy, noe som kan forme hvordan dette utvikler seg, og kontinuerlig læring er en annen utfordring som kan bli kastet inn i miksen. Hvor mye vil dette endre seg hvis vi får kontinuerlig læring? Vel, det er vanskelig å forutsi. min medianprognose for kontinuerlig læring er at det ser litt ut som RL for brukerspesifikke LoRA-er (ikke nødvendigvis RL, bare lignende hvis du myser), så minnekapasitet vil være et problem, og tekstbaserte organisasjonsskjemaer og dokumentasjon vil fortsatt være nyttige, om enn ikke like kritiske. I dette tilfellet gjør kontinuerlig læring det først og fremst mer levedyktig å bruke tilpassede verktøy og arbeidsflyter – din Claude kan kontinuerlig lære på jobben den beste måten å generere underagenter for dette prosjektet, eller bare den foretrukne måten, og avvike fra alle andres Claude i hvordan det fungerer. I den verdenen vil Harnesses med innebygde arbeidsflyter være enda mindre nyttige.

@RobertHaisfield *mens hovedkonteksten, jeg mener, ved å unngå komprimeringer

@disconcision eller kontinuerlig læring

@misatomiisato om noe, har denne typen intelligens avtatt i nyere modeller ettersom RLVR sliter ut kodingsytelsen over det brede kunnskapsgrunnlaget før opplæring – se mitt svar til OP