Anthropic: én agent med skills slår ofte mange subagenter, og lanserer migreringskit

Mange agentprosjekter starter med en intent-klassifiserer, en fast resonneringspipeline og en orkestrator som fordeler arbeid til spesialiserte subagenter. Anthropics Applied AI-team skriver nå på Claude-bloggen at akkurat denne strukturen ofte gjør resultatet dårligere. I sammenligninger på tvers av flere bedriftsutrullinger slo én agent med skills både designet med én stor prompt for alt og subagent-designet på kvalitet, ofte med lavere kostnad og latens per oppgave.

Eksemplene er konkrete. Ett selskap fant at et dusin spesialist-subagenter i den kundevendte agenten gjorde det vanskelig å holde en konsistent tone, og latensen gikk ut over brukeropplevelsen. En annen kunde målte omtrent 2x raskere kjøretid med én agentløkke enn med multi-agent-oppsettet sitt. Rotårsaken er ifølge Anthropic organisatorisk:

«For ofte ser vi at bedrifter gir hvert team eller hver problemtype sin egen subagent, og agentarkitekturen blir en kopi av organisasjonskartet (Conways lov i praksis)» — Applied AI-teamet, Anthropic

Grepet som erstatter subagentene heter progressive disclosure. Agenten ser bare korte beskrivelser av skills og verktøy, og laster hele innholdet først når det trengs, verktøyene via tool search med deferred loading. Det fjerner hovedgrunnen til å splitte arbeid, nemlig en systemprompt som svulmer opp. Anthropic opplyser at selskapet kuttet Claude Codes systemprompt for de mer avanserte modellene med over 80 %, delvis ved å progressivt avsløre skills og verktøy. Fra Opus 4.5 og utover klarer modellene dessuten langt mer i én løkke enn de fleste team regnet med.

Rådet står i kontrast til Anthropics egen begrunnelse for multi-agent. I ingeniørbloggens artikkel om forskningssystemet rapporterte selskapet at Claude Opus 4 som hovedagent med Claude Sonnet 4-subagenter slo én enkelt Opus 4-agent med 90,2 % på en intern research-eval. Regningen var token-bruken:

«Multi-agent-systemer bruker omtrent 15 ganger flere tokens enn chat» — Anthropic, artikkelen om multi-agent-forskningssystemet

Samme artikkel påpekte at de fleste kodeoppgaver har færre deler som virkelig kan parallelliseres enn research. Den nye guiden trekker en lignende grense: subagenter er fortsatt riktig når én løkke får målbar degradering av oppblåst kontekst, når parallelle oppgaver trenger ferske kontekstvinduer som kan kastes etterpå, eller når agenten sliter med å velge riktig verktøy.

Migreringen skjer én subagent om gangen. Prompten blir en skill, API-kallene blir MCP-verktøy, og du sammenligner eval-resultatet med og uten subagenten. Verktøy bør grupperes etter brukerintensjon, fordi verktøyvalget pleier å bli dårligere når systemprompten passerer 30-50 verktøydefinisjoner. Se på hvilke oppgaver som snudde, ikke bare totalscoren: i Anthropics test på en eksempel-supportagent ga sammenslåingen lavere latens, men hovedagenten slo opp ordren selv og svarte uten å spørre fraktspesialisten om leveringsdatoen. Feilen dukket opp i bare én av to kjøringer.

Migreringskitet kjeder sammen Claude API-skills i én veiledet arbeidsflyt, med en demo du kan kjøre mot et mock-system først. /claude-api build-eval lager eval-settet, prompt-audit flagger instruksjoner skrevet for eldre modeller og foreslår rettelser som diff, hillclimb itererer mot en eksisterende eval, og cost-optimize viser hvor kallene går og foreslår besparelser som prompt caching. I tillegg viser /skill-doctor hva hver skill koster og hvor ofte den faktisk brukes.

Hva bør du gjøre?

1. Bygg et lite ende-til-ende-eval før du rører arkitekturen. Anthropic mener 10 gullstandard-eksempler holder til å starte.
2. Slå først sammen subagenter som kjeder på hverandres output, jobber på samme data eller ofte kalles sammen, og kjør hver eval-oppgave mer enn én gang.
3. Tell verktøydefinisjonene dine. Ligger du over 30-50, grupper dem etter intensjon eller flytt dem bak tool search.