Slik bygger du superintelligens inn i en bedrift

Kort fortalt

I en ny episode av Lightcone-podkasten snakker Y Combinator med Pete Koomen om hvordan YC bygde sin egen AI-infrastruktur fra bunnen av. Samtalen handler ikke om hvilke AI-verktøy man bør kjøpe. Den handler om noe mer grunnleggende:

Hvordan gjør du AI til selve operativsystemet selskapet kjører på?

Den gamle tanken er at AI er en assistent ved siden av arbeidet. Du har en chatbot her, en skrivehjelp der, kanskje en Copilot i utviklingsmiljøet. Det er nyttig, men ikke transformerende.

Den nye tanken er at AI er et arbeidslag under hele organisasjonen. Agenten leser bedriftens data, bruker bedriftens verktøy, lærer av bedriftens beslutninger, og forbedrer seg over tid. Da blir AI mer som strøm eller internett: en infrastruktur alt annet jobber gjennom.

Fra copilot til operativsystem

De fleste selskaper bruker AI på en overflatisk måte i dag. En oppsummering her, en chatbot der, kanskje litt automatisering av e-post. Det er ikke galt, men det utnytter ikke det modellene faktisk kan.

YC beskriver en annen tilnærming. AI er ikke et tillegg. Det er et arbeidslag. Agenten har tilgang til bedriftens kontekst, kan bruke interne verktøy, og lærer av tidligere arbeid. En ny ansatt kan spørre agenten hvordan ting fungerer hos akkurat dette selskapet, og agenten svarer ut fra reell kjennskap til historikken, rutinene og kundene.

Forskjellen er stor:

Det er ikke bare effektivisering. Det er en ny organisasjonsform. Pete Koomen kaller det «the personal computer moment for AI». Vi har gått fra at AI var noe få aktører kontrollerte sentralt, til at hver bedrift kan bygge sin egen agent-plattform.

Det startet med et finansproblem

YC begynte ikke med en abstrakt strategi om superintelligens. De begynte med et konkret problem: finansarbeidet krevde mye fram og tilbake mellom domeneeksperter og utviklere.

Den gamle prosessen var omtrent slik:

1. Finans forklarer en prosess til utviklere.
2. Utviklere prøver å forstå prosessen.
3. Utviklere bygger spesiallaget programvare.
4. Finans tester. Noe mangler.
5. Prosessen gjentas.

Pete Koomen beskriver dette som ineffektivt. Ideen ble: hva om finans kunne beskrive arbeidsflytene sine på engelsk, og agentene kunne bruke interne verktøy for å gjøre arbeidet? Målet var å fjerne utviklere fra den tunge oversettelsesloopen og la finans «kode arbeidsflyter som engelsk med prompts».

Før måtte fagfolk oversette kunnskapen sin til utviklere, som så oversatte den til kode. Nå kan noe av denne oversettelsen gå via AI-agenten direkte. Det betyr ikke at kode forsvinner. Det betyr at koden blir mer som et sett trygge, gjenbrukbare verktøy agenten kan bruke.

SQL-tilgang var det første gjennombruddet

Det første store gjennombruddet kom da agentene fikk lov til å kjøre read-only SQL-spørringer mot databasen. Read-only betyr at agenten kan lese data, men ikke endre dem.

Dette høres nesten for enkelt ut. Men det er hele poenget.

Hvis agenten kan lese databasen og forstå strukturen, kan den svare på spørsmål som tidligere krevde timer med manuelt SQL-arbeid. Et eksempel fra samtalen: «Vis meg alle investorer som har investert i et romfartsrelatert selskap i de siste fire batchene.»

Fordi alt viktig hos YC lå i én Postgres-database, kunne agenten svare på vilkårlige spørsmål om virksomheten. En ikke-teknisk, men smart person i finansavdelingen kunne stille ekte spørsmål til dataene uten å vente på ingeniørbakgrunn.

Det viktige rådet fra denne erfaringen er enkelt:

Samle viktig kontekst og gjør den lesbar for agenten.

Ikke gi agenten farlig skrive-tilgang fra dag én. Start read-only. La den lese. La den forklare. La den hjelpe ansatte å stille bedre spørsmål.

Én database å samle dem alle

YC hadde en undervurdert fordel: nesten alt viktig lå i én database. Selskaper, gründere, finansielle transaksjoner, notater og interne CRM-data lå samme sted. Mange andre selskaper har dette spredt over Slack, Notion, Salesforce, HubSpot, Excel, Google Drive, Jira og e-post.

Dette er en innsikt mange overser:

AI-agenten er ikke bare begrenset av hvor smart modellen er. Den er begrenset av hvor rotete organisasjonens kunnskap er.

Tenk på agenten som en ny ansatt. Hvis alt ligger i forskjellige permer, private mapper og gamle e-poster, bruker den nye ansatte måneder på å skjønne sammenhengen. Hvis alt ligger i et ryddig bibliotek med kart og indeks, går læringen mye raskere.

Det viktigste er ikke nødvendigvis én fysisk database, men ett sammenhengende kontekstlag, et lag som samler relevant kunnskap slik at AI kan bruke den. Det kan være en stor felles datakilde (data lake), et koblet kunnskapsnettverk (knowledge graph), en intern wiki eller et søkesystem laget for AI. Poenget er at agenten skal kunne nå frem til sannheten på ett sted.

Bedrifter som vil bli AI-native bør spørre seg:

• Hvilke systemer inneholder sannheten?
• Hvilke data er duplisert?
• Hvilke data er låst inne i SaaS-verktøy?
• Hvilke data kan trygt eksponeres read-only?
• Hvilke begreper må standardiseres?

AI-transformasjon begynner ofte ikke med modellen. Den begynner med informasjonsarkitekturen.

Når spørsmål blir billigere, spør folk mer

Et viktig poeng i samtalen er økonomisk. Agentene gjorde det ikke bare lettere å svare på spørsmål. De gjorde at folk stilte flere og mer komplekse spørsmål.

Tidligere ville et spørsmål til dataanalytikerne tatt timer eller dager. Da spurte man bare når det var veldig viktig. Når agenten kan hjelpe umiddelbart, spør man mye mer.

Dette er Jevons paradox i kunnskapsarbeid. Jevons paradox er et prinsipp fra økonomi: når noe blir mer effektivt å bruke, kan totalbruken øke i stedet for å falle.

• Når analyse blir billigere, blir det mer analyse.
• Når programmering blir billigere, blir det mer programvare.
• Når intern kunnskap blir lettere å hente, tar flere beslutninger faktisk i bruk intern kunnskap.

AI senker transaksjonskostnaden ved informasjonsarbeid. Det kan endre organisasjonskulturen. En organisasjon med høy friksjon tar færre datadrevne beslutninger. En organisasjon med lav friksjon tør å teste flere hypoteser.

Men det krever modenhet. Flere spørsmål betyr ikke automatisk bedre beslutninger. Agenten må kunne vise kilder, forklare usikkerhet og gjøre det lett å kontrollere svar.

Tool registry: verktøykassen agenten trenger

En AI-agent uten verktøy er som en smart kollega uten tilgangskort, kalender, database eller tastatur. Den kan snakke, men ikke gjøre så mye.

YC bygde en intern tool registry, altså en katalog over verktøy agenten kan bruke. I starten hadde de rundt 20 verktøy. Etter hvert vokste det til over 350, der ulike team la inn sine egne verktøy for finans, office hours, events og andre viktige prosesser.

Dette er kjernen i agentisk arbeid. Forskjellen ligner på å ha en konsulent som bare kan gi råd, versus en kollega som faktisk kan logge inn i systemene, hente tallene, oppdatere status og starte prosesser.

En tool registry beskriver hvilke funksjoner agenten kan bruke, hvilke parametere de tar, hvilke rettigheter som kreves, og hva de returnerer. For eksempel:

book_journal_entry(amount, account, date, memo)
get_company(company_id)
list_founders(batch)
schedule_office_hours(partner_id, founder_id)
query_readonly_sql(sql)

Agenten velger riktig verktøy basert på brukerens mål og konteksten. For en bedrift er dette kanskje viktigere enn å kjøpe «den beste modellen». Lag en liten, trygg verktøykatalog:

• les kundedata,
• søk i interne dokumenter,
• hent ordrestatus,
• opprett forslag,
• lag rapportutkast,
• oppsummer samtaler,
• send til menneskelig godkjenning.

Start read-only. Legg til skrivehandlinger med godkjenning. Bygg tillit gradvis.

Et viktig stykke infrastruktur her er MCP, Model Context Protocol. Det er en åpen standard for å koble AI-applikasjoner til eksterne systemer som databaser, filer, verktøy og workflows. Anthropic introduserte MCP som en universal kontakt mellom AI og datakilder, og den offisielle dokumentasjonen sammenligner det med en USB-C-port for AI.

Skills: organisasjonens beste arbeidsmåter, gjort gjenbrukbare

Når noen i bedriften finner en god måte å gjøre noe på, bør den måten bli gjenbrukbar for alle. YC kaller dette en skill: en gjenbrukbar instruksjon eller arbeidsmåte for en agent.

Hvis en erfaren selger alltid skriver gode oppfølgings-e-poster etter kundemøter, kan man lage en skill:

«Skriv oppfølging etter kundemøte med tydelig oppsummering, neste steg, ansvarlig person, frist og vennlig tone.»

Etter hvert lærer agenten av gode eksempler og forbedrer skillen. Da blir én persons erfaring tilgjengelig for mange.

I samtalen forklares «skillify» som en meta-skill: når agenten har gjort noe nyttig, kan man gjøre fremgangsmåten om til en skill. Deretter sjekkes om den nye skillen overlapper med eksisterende. Målet er at skill-registeret skal være DRY (Don't Repeat Yourself, altså ikke lag ti nesten like ting) og MECE (Mutually Exclusive, Collectively Exhaustive, altså kategorier som ikke overlapper unødvendig, men dekker helheten).

En skill kan inneholde:

• formål,
• når den skal brukes,
• hvilken input agenten trenger,
• steg-for-steg-prosess,
• eksempler,
• feil den bør unngå,
• evalueringskriterier,
• hvilke verktøy den kan bruke.

Dette er et mellomlag mellom ren prompt og full programkode. Bedrifter bør begynne å samle sine beste arbeidsmåter som skills: «Slik oppsummerer vi kundemøter», «Slik vurderer vi en inbound lead», «Slik skriver vi en prosjektstatus», «Slik kvalitetssikrer vi et blogginnlegg».

Dette er kunnskapsledelse, men med AI som aktiv bruker av kunnskapen. Skills gjør taus kunnskap operasjonell. Det som før bare satt i hodet til flinke folk, kan bli et delt arbeidsverktøy.

Dream cycle: agenten som forbedrer seg om natten

Den mest spennende delen av samtalen er kanskje dream cycle, en periodisk prosess der agenten analyserer tidligere arbeid og oppdaterer minne, skills eller kontekst.

YC har en generell agent som hver natt leser gjennom agent-samtalene ansatte har hatt. Den leter etter ting den kunne gjort bedre, og finner kontekst som ville gjort den mer effektiv neste gang. Resultatet er at skills forbedres gradvis uten at noen sitter og redigerer dem.

Mange AI-systemer starter på nytt hver gang. De glemmer. De lærer ikke av organisasjonens bruk. Dream cycle prøver å gjøre AI-systemet mer som en organisasjon som lærer over tid.

Et eksempel fra samtalen er YCs «two-sentence description»-skill. Partnere har lang erfaring med å hjelpe gründere forklare hva selskapet gjør på to setninger. Når møter og tilbakemeldinger transkriberes, kan agenten bruke dette materialet til å forbedre skillen. Etter en runde med slik læring ble skillen merkbart bedre.

En dream cycle kan gjøre flere ting:

1. Lese samtalelogger.
2. Finne mislykkede eller ineffektive svar.
3. Trekke ut manglende kontekst.
4. Foreslå forbedringer i skills.
5. Oppdatere intern wiki eller kunnskapsbase.
6. Lage evalueringsoppgaver.
7. Flagge ting som krever menneskelig godkjenning.

Dette bør ikke være helt ukontrollert. Selvforbedring uten review kan også forsterke feil. Den beste varianten kombinerer automatiske forslag med menneskelig kontroll.

Et lite eksempel med stor betydning: two-sentence pitch

«Two-sentence description» høres ut som en bagatell, men det viser mekanismen bak superintelligens i organisasjoner.

YC bruker en kort forklaring på hva et selskap gjør og hvorfor det er interessant. To setninger, naturlig språk. Pete Koomen beskriver dette som vanskelig fordi gründere ofte har perfekt kontekst i eget hode, men ikke klarer å overføre den til andre.

Dårlig pitch:

Vi bruker AI til å optimalisere workflows for moderne teams.

Bedre pitch:

Vi hjelper regnskapsbyråer å finne feil i bilag før de sendes til kunden. Systemet leser bilag, e-poster og tidligere saker, og foreslår hva regnskapsføreren bør sjekke først.

Den andre er bedre fordi leseren forstår hvem det er for, hva problemet er, hva produktet gjør og hvorfor det kan være verdifullt.

YC har gjort dette til en skill. Først skrev en partner en prompt basert på egen erfaring. Senere fikk agenten lese utskrifter fra møter der partnere veiledet gründere. Da lærte agenten av faktiske samtaler, ikke bare av en instruksjon.

Hver bedrift har sine egne «two-sentence pitch»-oppgaver:

• Hvordan forklarer vi produktet vårt?
• Hvordan skriver vi gode kundesvar?
• Hvordan vurderer vi en kandidat?
• Hvordan forklarer vi en teknisk feil til en kunde?
• Hvordan lager vi en god styreoppdatering?

Hvis dere kan gjøre én slik oppgave bedre og mer gjenbrukbar, kan dere gjøre det samme med hundre andre.

Hvor superintelligensen egentlig kommer fra

Her må vi være presise. YC bruker ordet «superintelligence» bredt. De mener ikke nødvendigvis en science fiction-maskin som er smartere enn alle mennesker på alt. De beskriver en organisasjon der menneskelig erfaring, data, verktøy og AI-agentarbeid forsterker hverandre.

Mekanismen er en snøballeffekt:

Over tid kan organisasjonen få et felles ferdighetsnivå som er høyere enn enkeltpersonenes isolerte ferdigheter. Superintelligens i bedrifter er ikke én magisk knapp. Det er mange små læringssløyfer som kobles sammen.

Dette krever en arkitektur med datatilgang, agent loops, tool registry, skill registry, minne, observability, feedback, tilgangskontroll, evalueringssystemer og menneskelig review. OpenAI beskriver en agent loop i Codex som et samspill mellom brukeren, modellen og verktøyene som modellen bruker for å utføre reelt utviklingsarbeid. Det samme prinsippet kan overføres fra kode til annet arbeid i en organisasjon.

Å registrere alt: kraftig, men farlig

YC sier man må begynne å lagre artefakter (møter, samtaler, beslutninger) fordi disse kan brukes til å forbedre arbeid på tvers av organisasjonen.

Hos YC var agent-samtaler som standard synlige for fulltidsansatte, blant annet fordi folk lærte av å se hvordan andre brukte agentene. Det skapte også åpenhet og felles læring.

Dette er spennende, men ikke universelt overførbart.

YC er en relativt liten, tillitsbasert organisasjon med høy teknologisk modenhet. En større bedrift med sensitive persondata, kundedata, regulatoriske krav eller fagforeninger må være mer forsiktig.

Et godt system må skille mellom:

• offentlig intern kunnskap,
• team-kunnskap,
• personlig kunnskap,
• kundekonfidensiell informasjon,
• juridisk sensitiv informasjon,
• sikkerhetskritisk informasjon.

MCP og lignende standarder gjør det lettere å koble AI til eksterne systemer, men de løser ikke automatisk governance. Bedriften må fortsatt definere egne rettigheter, logging og policyer.

En praktisk startmodell:

1. Start med ikke-sensitive dokumenter.
2. Gi read-only tilgang.
3. Logg alle agenthandlinger.
4. Vis kilder i svar.
5. Bruk menneskelig godkjenning for handlinger.
6. Skill mellom personlig, team og organisasjonsminne.
7. Ha klare regler for møteopptak og samtykke.

Horseless carriages: hvorfor mange AI-produkter er bygget feil

Pete Koomen skrev essayet «AI Horseless Carriages» før denne samtalen, og det diskuteres også i podkasten. Poenget er at mange AI-produkter kopierer gammel programvarelogikk i stedet for å tenke nytt rundt AI.

De første bilene lignet hestevogner uten hest. Folk visste ikke ennå hva en bil egentlig kunne være. På samme måte ser mange AI-produkter ut som gamle apper med en liten «skriv med AI»-knapp limt på toppen.

Tradisjonell programvare er skjema-drevet:

Agentisk programvare er mer mål-drevet:

Når du vurderer et AI-produkt, spør:

• Kan jeg gi det mine egne instruksjoner?
• Kan det bruke mine data?
• Kan det lære mine preferanser?
• Kan det bruke verktøy?
• Kan det forbedres over tid?
• Kan jeg se og endre hvordan det arbeider?

Hvis svaret er nei, er det kanskje bare en horseless carriage.

Chat er et overraskende sterkt grensesnitt

Mange trodde chat bare var en midlertidig AI-løsning. I samtalen argumenterer YC for at chat faktisk kan være et svært godt grensesnitt for agentarbeid.

Argumentet er at chat er nært menneskelig språk, og språk er vårt beste verktøy for å uttrykke tanker, mål, nyanser og usikkerhet. Tradisjonelle grensesnitt tvinger deg inn i bokser: felt, dropdowns, knapper, faste dashboards. Chat lar deg si:

«Finn de tre viktigste kundene som sannsynligvis er misfornøyde, forklar hvorfor, og lag et forslag til oppfølging.»

Det er vanskelig å lage en knapp for alle slike behov.

Fremtidens interne verktøy kan bli mindre dashboard-fokuserte og mer agent-fokuserte. Du spør ikke nødvendigvis «hvilket dashboard viser dette?». Du spør agenten, og agenten lager riktig visning eller analyse. Det kalles ofte just-in-time software: visninger og verktøy som lages akkurat når du trenger dem.

Sentralisert eller personlig AI

Mot slutten blir samtalen filosofisk. Skal AI være kontrollert av noen få store aktører, eller skal mennesker og bedrifter kunne eie, endre og styre egne agenter?

Pete Koomen sammenligner dagens AI-øyeblikk med personal computer-revolusjonen. Før PC-en var datakraft sentralisert og kontrollert av institusjoner. PC-en gjorde datakraft personlig, eksperimentell og demokratisk.

Han frykter en AI-fremtid der noen få selskaper kontrollerer modellene, promptene, verktøyene og brukeropplevelsen. Alternativet er en fremtid der folk og bedrifter kan kontrollere egne prompts, egne datakilder og egne agentarbeidsflyter. Garry Tan har publisert et åpent prosjekt kalt gbrain, et selvhostet «brain layer» for agenter med Postgres, markdown, skills og agentminne.

For mange organisasjoner er dette en strategisk vurdering:

• Hvor ligger dataene?
• Hvem kontrollerer promptene?
• Kan systemet forbedres lokalt?
• Kan det flyttes hvis leverandøren endrer seg?
• Kan det revideres?
• Kan brukeren forstå hvordan det virker?

AI-revolusjonen kan bli sentralisert eller personlig. Valgene som tas nå, bestemmer mye av hvordan fremtidens arbeid vil føles.

Slik kan en bedrift starte

Ikke bygg «superintelligens» først. Bygg én nyttig læringssløyfe.

Et godt første prosjekt kan være:

• support-oppsummeringer,
• møteoppsummeringer,
• CRM-spørsmål,
• intern onboarding,
• kundeanalyse,
• rapportutkast,
• pitch-forbedring,
• kode-review,
• prosjektstatus.

Det viktige er at prosjektet må være konkret nok til å evalueres. Hvis det virker, utvid.

Oppsummert

Det viktigste fra denne samtalen er ikke at YC har 350 verktøy eller én stor Postgres-database. Det viktigste er prinsippet:

En organisasjon blir AI-native når den gjør kunnskap, verktøy og læring tilgjengelig for agenter på en trygg og systematisk måte.

Det krever mer enn en chatbot. Det krever samlet kontekst, trygg tilgang til data, tool registry, skills, logging, feedback-sløyfer, en kultur for deling og tydelige grenser for sikkerhet og personvern.

Den enkle versjonen er at AI må få tilgang til bedriftens bibliotek, ikke bare stå utenfor døren og gjette hva som står i bøkene.

Den mer tekniske versjonen er at fremtidens organisasjoner vil bygge interne agent-plattformer der modeller, verktøy, data, minne, skills og menneskelig feedback kobles sammen i lærende systemer.

Det er her superintelligensen i en bedrift begynner. Ikke som én stor maskin, men som tusen små forbedringssløyfer som gjør alle litt bedre, hver dag.

Ordliste

Kilder og ressurser