2025 er agentenes år, og nøkkelfunksjonen til agenter er å ringe verktøy. Når jeg bruker Claude Code, kan jeg be AI om å sile gjennom et nyhetsbrev, finne alle lenkene til startups, bekrefte at de finnes i CRM-en vår, med en enkelt kommando. Dette kan innebære at to eller tre forskjellige verktøy kalles. Men her er problemet: å bruke en stor fundamentmodell for dette er dyrt, ofte prisbegrenset og overmannet for en utvalgsoppgave. Hva er den beste måten å bygge et agentisk system med verktøykall? Svaret ligger i små handlingsmodeller. NVIDIA ga ut en overbevisende artikkel som argumenterte for at "Små språkmodeller (SLM-er) er tilstrekkelig kraftige, iboende mer egnet og nødvendigvis mer økonomiske for mange påkallelser i agentiske systemer." Jeg har testet forskjellige lokale modeller for å validere en kostnadsreduksjonsøvelse. Jeg startet med en Qwen3:30b-parametermodell, som fungerer, men som kan være ganske treg fordi det er en så stor modell, selv om bare 3 milliarder av de 30 milliarder parameterne er aktive til enhver tid. NVIDIA-dokumentet anbefaler Salesforce xLAM-modellen – en annen arkitektur kalt en stor handlingsmodell spesielt designet for verktøyvalg. Så jeg kjørte en egen test, hver modell kalte et verktøy for å liste opp Asana-oppgavene mine. Resultatene var slående: xLAM fullførte oppgaver på 2,61 sekunder med 100 % suksess, mens Qwen tok 9,82 sekunder med 92 % suksess – nesten fire ganger så lenge. Dette eksperimentet viser hastighetsøkningen, men det er en avveining: hvor mye intelligens som skal bo i modellen kontra i selve verktøyene. Denne begrensede Med større modeller som Qwen kan verktøy være enklere fordi modellen har bedre feiltoleranse og kan omgå dårlig utformede grensesnitt. Modellen kompenserer for verktøybegrensninger gjennom brute-force-resonnement. Med mindre modeller har modellen mindre kapasitet til å komme seg etter feil, så verktøyene må være mer robuste og seleksjonslogikken mer presis. Dette kan virke som en begrensning, men det er faktisk en funksjon. Denne begrensningen eliminerer sammensetningsfeilraten for LLM-kjedede verktøy. Når store modeller foretar sekvensielle verktøykall, akkumuleres feil eksponentielt. Små handlingsmodeller tvinger frem bedre systemdesign, beholder det beste fra LLM-er og kombinerer det med spesialiserte modeller. Denne arkitekturen er mer effektiv, raskere og mer forutsigbar.

1/8 📊 Nettopp lansert: et sanntidsdashbord for å spore Hyperliquid-handelsvolumer, bygger- og henvisningsberegninger, fortjeneste og tap og mer. Bygget av @AlliumLabs La oss dykke inn 🧵

Hvorfor krymper frørunden på under 5 millioner dollar? For et tiår siden utgjorde disse mindre rundene ryggraden i oppstartsfinansiering, og utgjorde over 70 % av alle såkornavtaler. I dag avslører PitchBook-data at tallet har stupt til mindre enn halvparten. Tallene forteller en sterk historie. Avtaler under 5 millioner dollar falt fra 62,5 % i 2015 til 37,5 % i 2024. Dette fallet på 29,5 prosentpoeng endret fundamentalt hvordan startups skaffer sin første institusjonelle kapital. Tre krefter drev denne transformasjonen. Vi kan bryte ned nedgangen for å forstå hva som reduserte den lille frørunden og hvorfor den er viktig for gründere i dag.

Dette var så gøy, Mario. Takk for at jeg var med på showet for å snakke om alt som skjer på markedet!

OpenAI mottar i gjennomsnitt 1 spørring per amerikaner per dag. Google mottar omtrent 4 søk per amerikaner per dag. Siden den gang har 50 % av Google-søkene AI-oversikter, noe som betyr at minst 60 % av amerikanske søk nå er AI. Det har tatt litt lengre tid enn jeg forventet før dette skulle skje. I 2024 spådde jeg at 50 % av forbrukersøk ville være AI-aktivert. ( Men AI har kommet i søket. Hvis Googles søkemønstre er noen indikasjon, er det en maktlov i søkeatferd. SparkToros analyse av Googles søkeatferd viser at den øverste tredjedelen av amerikanere som søker, utfører oppover 80 % av alle søk – noe som betyr at AI-bruk sannsynligvis ikke er jevnt fordelt – som fremtiden. Nettsteder og bedrifter begynner å føle virkningene av dette. The Economists artikkel "AI dreper nettet. Kan noe redde det?» fanger tidsånden i en overskrift. ( Et overveldende flertall av amerikanere søker nå med AI. Andreordenseffektene fra endrede søkemønstre kommer i andre halvdel av dette året, og flere vil spørre: "Hva skjedde med trafikken min?" ( AI er en ny distribusjonskanal, og de som griper den vil ta markedsandeler. - William Gibson så mye lenger inn i fremtiden! - Dette er basert på en midtpunktsanalyse av SparkToro-diagrammet, er en veldig enkel analyse, og har noen feil som resultat.

Når jeg jobber med AI, stopper jeg før jeg skriver noe i boksen for å stille meg selv et spørsmål: hva forventer jeg av AI? 2x2 til unnsetning! Hvilken boks er jeg i? På den ene aksen, hvor mye kontekst jeg gir: ikke veldig mye til ganske mye. På den andre siden, om jeg skal se på AI-en eller la den kjøre. Hvis jeg gir veldig lite informasjon og lar systemet kjøre: 'undersøk Forward Deployed Engineer-trender', får jeg bruk-og-kast-resultater: brede oversikter uten relevante detaljer. Å kjøre det samme prosjektet med en rekke korte spørsmål gir en iterativ samtale som lykkes - en utforskning. «Hvilke selskaper har implementert Forward Deployed Engineers (FDE)? Hva er den typiske bakgrunnen til FDE-er? Hvilke typer kontraktsstrukturer og virksomheter egner seg til dette arbeidet?» Når jeg har en veldig lav toleranse for feil, gir jeg omfattende kontekst og jobber iterativt med AI. For blogginnlegg eller økonomisk analyse deler jeg alt (nåværende utkast, tidligere skrifter, detaljerte krav) og fortsetter deretter setning for setning. Å la en agent løpe fritt krever å definere alt på forhånd. Jeg lykkes sjelden her fordi arbeidet på forhånd krever enorm klarhet - eksakte mål, omfattende informasjon og detaljerte oppgavelister med valideringskriterier - en disposisjon. Disse spørsmålene ender opp med å se ut som produktkravdokumentene jeg skrev som produktsjef. Svaret på "hva forventer jeg?" vil bli enklere ettersom AI-systemer får tilgang til mer av informasjonen min og blir bedre til å velge relevante data. Etter hvert som jeg blir bedre til å formulere hva jeg faktisk vil, forbedres samarbeidet. Jeg tar sikte på å flytte mange flere av spørsmålene mine fra den øverste venstre bøtta - hvordan jeg ble trent med Google-søk - til de tre andre kvadrantene. Jeg forventer også at denne vanen vil hjelpe meg å jobbe bedre med mennesker.

Den lille svarte boksen i midten er maskinlæringskode. Jeg husker at jeg leste Googles 2015 Hidden Technical Debt in ML-artikkel og tenkte på hvor lite av en maskinlæringsapplikasjon som var faktisk maskinlæring. Det store flertallet var infrastruktur, datahåndtering og operasjonell kompleksitet. Med begynnelsen av AI så det ut til at store språkmodeller ville subsumere disse boksene. Løftet var enkelhet: slipp inn en LLM og se den håndtere alt fra kundeservice til kodegenerering. Ingen flere komplekse pipeliner eller sprø integrasjoner. Men når vi bygger interne applikasjoner, har vi observert en lignende dynamikk med AI. Agenter trenger mye kontekst, som et menneske : hvordan er CRM strukturert, hva legger vi inn i hvert felt - men input er dyrt Hungry, Hungry AI-modellen. Å redusere kostnadene betyr å skrive deterministisk programvare for å erstatte resonnementet til AI. For eksempel betyr automatisering av e-postadministrasjon å skrive verktøy for å lage Asana-oppgaver og oppdatere CRM. Etter hvert som antallet verktøy øker utover ti eller femten verktøy, fungerer ikke verktøykall lenger. På tide å spinne opp en klassisk maskinlæringsmodell for å velge verktøy. Så er det å se på systemet med observerbarhet, evaluere om det er effektivt og rute til riktig modell. I tillegg er det en hel kategori programvare rundt å sørge for at AI gjør det den skal. Rekkverk forhindrer upassende respons. Hastighetsbegrensning hindrer kostnadene i å komme ut av kontroll når et system går galt. Informasjonsinnhenting (RAG - retrieval augmented generation) er avgjørende for ethvert produksjonssystem. I e-postappen min bruker jeg en LanceDB-vektordatabase for å finne alle e-poster fra en bestemt avsender og matche tonen deres. Det finnes andre teknikker for kunnskapsstyring rundt graf-RAG og spesialiserte vektordatabaser. I det siste har hukommelse blitt mye viktigere. Kommandolinjegrensesnittene for AI-verktøy lagrer samtaleloggen som markdown-filer. Når jeg publiserer diagrammer, vil jeg ha Theory Ventures-bildeteksten nederst til høyre, en bestemt skrifttype, farger og stiler. Disse er nå alle lagret i .gemini- eller .claude-filer i en rekke overlappende kataloger. Den opprinnelige enkelheten til store språkmodeller har blitt subsumert av produksjonskompleksitet på bedriftsnivå. Dette er ikke identisk med forrige generasjon maskinlæringssystemer, men det følger en klar parallell. Det som så ut til å være en enkel "AI-magisk boks" viser seg å være et isfjell, med det meste av ingeniørarbeidet skjult under overflaten.

Hvis 2025 er agentenes år, vil 2026 helt sikkert tilhøre agentledere. Agentledere er personer som kan administrere team med AI-agenter. Hvor mange kan en person lykkes med? Jeg kan knapt administrere 4 AI-agenter samtidig. De ber om avklaring, ber om tillatelse, utsteder nettsøk – alt krever min oppmerksomhet. Noen ganger tar en oppgave 30 sekunder. Andre ganger, 30 minutter. Jeg mister oversikten over hvilken agent som gjør hva og halvparten av arbeidet blir kastet bort fordi de feiltolker instruksjoner. Dette er ikke et ferdighetsproblem. Det er et verktøyproblem. Fysiske roboter gir ledetråder om robotlederens produktivitet. MIT publiserte en analyse i 2020 som antydet at den gjennomsnittlige roboten erstattet 3,3 menneskelige jobber. I 2024 rapporterte Amazon at pickpack- og skipsroboter erstattet 24 arbeidere. Men det er en kritisk forskjell: AI er ikke-deterministisk. AI-agenter tolker instruksjoner. De improviserer. Noen ganger ignorerer de instruksjoner helt. En Roomba kan bare drømme om den kreative friheten til å ignorere stuen din og bestemme seg for at garasjen trenger oppmerksomhet i stedet. Ledelsesteori veileder ofte team til et kontrollspenn på 7 personer. Når jeg snakker med noen bedre agentledere, har jeg lært at de bruker en agentinnboks, et prosjektstyringsverktøy for å be om AI-arbeid og evaluere det. I programvareteknikk tjener Githubs pull-forespørsler eller lineære billetter dette formålet. Svært produktive AI-programvareingeniører administrerer 10-15 agenter ved å spesifisere 10-15 oppgaver i detalj, sende dem til en AI, vente til ferdigstillelse og deretter gjennomgå arbeidet. Halvparten av arbeidet kastes, og startes på nytt med en forbedret ledetekst. Agentinnboksen er ikke populær - ennå. Det er ikke allment tilgjengelig. Men jeg mistenker at det vil bli en viktig del av produktivitetsstabelen for fremtidige agentledere fordi det er den eneste måten å holde styr på arbeidet som kan komme inn når som helst. Hvis ARR per ansatt er den nye forfengelighetsberegningen for oppstartsbedrifter, kan agenter administrert per person bli forfengelighetsproduktivitetsmålingen til en arbeider. Hvor mange agenter tror du at du kan klare på 12 måneder? 10? 50? 100? Kan du administrere en agent som administrerer andre agenter?

"Å, kontoret ditt er i Ferry-bygningen, det er så fantastisk, hvordan er det?" «Non-stop busking. Møter avbrutt av sekkepipespillere utenfor. Seter på første rad til neste Santana i gatene.»

Det siste tiåret var den største posten i enhver oppstarts FoU-budsjett forutsigbart talent. Men AI presser seg inn på P&L. Hvor mye bør en oppstart bruke på AI som en prosentandel av forsknings- og utviklingsutgiftene? 10%? 30%? 60? Det er tre faktorer å vurdere. For det første gjennomsnittslønnen for en programvareingeniør i Silicon Valley. For det andre er den totale kostnaden for AI som brukes av den ingeniøren. Cursor er nå på $200 per måned for deres Ultra-plan og anmeldelser av Devin foreslår $500 per måned. For det tredje, antall agenter en ingeniør kan administrere. En første passering : (første bilde) Men abonnementskostnadene er sannsynligvis lave. I løpet av de siste dagene har jeg lekt mye med AI-kodeagenter, og jeg fikk en regning på $1,000 i løpet av fem dager! 😳😅 Så la oss oppdatere tabellen og anta ytterligere $1000 per måned per ingeniør. Så for en typisk oppstart kan et estimat på 10 til 15 % av de totale FoU-utgiftene i dag tenkes å brukes til AI. Variantene vil være mye bredere i praksis ettersom vi alle lærer å bruke AI bedre og det trenger inn i mer av organisasjonen. Mindre selskaper som er AI-innfødte fra begynnelsen, vil sannsynligvis ha betydelig høyere forholdstall. Hvis du er interessert i å delta i en anonym undersøkelse, vil jeg publisere resultatene hvis utvalgsstørrelsen er stor nok til å ha et statistisk signifikant resultat. Undersøkelsen er her: Dette er en grovt forenklet modell der vi kun gjennomgår lønn, ikke inkludert fordeler, maskinvare, utviklings- og testinfrastruktur osv. Dette er et estimat basert på rabattert personlig erfaringskoding.