Y Combinator åpnet QM – AI-agenter for hele bedriften

QM er Y Combinators forsøk på å gjøre AI-agenten til en kollega hele bedriften kan bruke, uten at alle deler samme rotete minne eller låses til én modell. Hver ansatt og hvert arbeidsrom får sitt eget avgrensede område med filer, tillatelser, minne og en vedvarende sandbox.

Det er en viktig forskjell. De fleste agentverktøy begynner med én person, én samtale og én maskin. Så prøver bedriften å strekke den samme assistenten over økonomi, juridisk arbeid, arrangementer og utvikling. Da blir spørsmålet raskt hvem agenten er, hva den får se og hvilke nøkler den kan bruke.

Y Combinator åpnet kildekoden til QM ved utgangen av juli 2026 under MIT-lisens. Systemet kjører i Slack og på web, støtter flere agentmotorer og kan installeres i bedriftens egen skykonto. Det er gode bein her. Men dette er også tidlig, eksperimentell programvare som ikke bør få nøklene til hele huset første dag.

Hva er QM?

QM er et flerbrukersystem for AI-agenter på jobb. Ifølge Y Combinators egen presentasjon av QM vokste det fram etter flere interne forsøk, blant annet en flåte på over 50 Hermes-agenter. Målet ble å beholde fleksibiliteten, men gjøre administrasjonen langt enklere.

Navnet er en forkortelse for «quartermaster», personen som holder orden på forsyninger og arbeid under dekk på et skip. Det passer egentlig ganske godt. QM er ikke den smarte modellen i seg selv. Det er laget rundt modellen som holder orden på identitet, arbeidsflate, bakgrunnsjobber, tilgang og historikk.

Ordet «multiplayer» kan være litt misvisende hvis du forventer en sverm av agenter som diskuterer med hverandre. Hovedpoenget er at mange mennesker kan arbeide med agenter i samme organisasjon, både privat og i delte Slack-kanaler eller prosjekter. Dette handler mer om organisering av arbeid enn om et spektakulært agentmøte på skjermen.

Hva får hver ansatt og hvert rom?

Hver person og hvert rom får ett avgrenset scope med eget minne, egne filer, en begrenset visning av nøkkelringen, tillatelser, crons, webapper og en vedvarende sandbox. Det offisielle QM-repositoriet beskriver hvordan samme identitet og konfigurasjon følger brukeren mellom Slack og webgrensesnittet.

I praksis betyr det at agenten i en juridisk kanal ikke automatisk blir den samme agenten som rydder i innboksen til en utvikler. Samtidig kan en delt prosjektkanal ha sitt eget minne og sine egne ressurser. Det er denne avgrensningen som gjør QM mer interessant enn enda en chatbot koblet til Slack.

Skills kan eies av et scope og deles gjennom eksplisitte tillatelser. En administrator må godkjenne før en skill løftes til hele organisasjonen, og skill-pakker kan importeres fra Git-repositorier. Crons og overvåkingsjobber gjør dessuten at agenten kan arbeide i bakgrunnen, ikke bare når noen sitter og skriver til den.

Y Combinator sier selv at organisasjonen bruker agentene på tvers av blant annet økonomi, juridisk arbeid, arrangementer og utvikling. MarkTechPosts gjennomgang av lanseringen trekker fram søk i interne kilder, innbokssortering, testing av kode, pull requests og prosjektoppfølging som konkrete bruksområder.

Hvordan er QM bygget?

QM har én sentral, headless kjerne som håndterer API, identitet, regler og planlegging. Postgres lagrer økter, minne, kø og annen vedvarende tilstand. Når agenten skal gjøre noe på en datamaskin, kjører verktøyet execute kommandoer i scopets egen isolerte sandbox.

Den sandkassen er vedvarende. Installerte verktøy blir liggende til neste økt, i stedet for at agenten våkner i et tomt engangsmiljø hver gang. Det gjør det mulig å arbeide videre i et repository, holde en intern app oppdatert eller kjøre planlagte oppgaver uten å sette opp miljøet på nytt for hver samtale.

Selve kjernen kjører TypeScript direkte på Node og bruker Fastify til HTTP. Slack-integrasjonen er bygget med Bolt, mens webgrensesnittet bruker Vite og Lit. Web, administrasjonspanel og offentlig portal er valgfrie plugins over samme kjerne. Organisasjonens egne innstillinger, verktøy, skills og sandbox-image ligger separat i en deployment-mappe.

Dette er en ganske fornuftig grense. Kjernen kan oppdateres uten at bedriftens private oppsett må presses inn i det offentlige prosjektet. Vil du ha alt samlet, anbefaler dokumentasjonen et vanlig privat repository med upstream-kobling, ikke GitHubs offentlige fork-mekanisme.

Hvorfor er modellfriheten viktig?

QM kan bruke minst fire forskjellige agentmotorer over samme kjerne: Pi, OpenCode, Codex og Claude Code. Organisasjonen velger også hvilke modeller ansatte får tilgang til. Dermed blir identitet, minne, sandbox og Slack-opplevelse liggende på plass selv om motoren eller modelltilbyderen byttes.

Det er dette som faktisk reduserer leverandørlåsingen. En MIT-lisens alene hjelper lite hvis hele arbeidsflyten fortsatt er vevd inn i én modell, ett minneformat og én skytjeneste. QM legger disse delene bak grensesnitt som kan byttes gjennom konfigurasjonen.

Jeg liker retningen. Modeller endrer pris, kvalitet og vilkår fort, og den beste modellen til kode trenger ikke være den beste til e-post eller dokumentsøk. Den samme tanken ligger bak åpen ruting mellom språkmodeller: infrastrukturen bør tåle at du ombestemmer deg.

Men QM gjør ikke modellbyttet magisk. Forskjellige motorer har ulike verktøy, arbeidsmåter og sikkerhetsmodeller. At de kan drive samme kjerne betyr at du slipper å bygge hele plattformen på nytt. Det betyr ikke at resultat, kostnad og risiko blir identisk.

Er sikkerheten god nok for bedriftsdata?

QM har tre sikkerhetsnivåer. Strict ber om menneskelig godkjenning for nesten hvert verktøykall. Auto, som er standard, bruker en klassifikator til å kontrollere merket eksternt innhold og verktøyresultater. Dangerous fjerner både denne kontrollen og pausene, men beholder forhåndsdefinerte sperrer mot blant annet rekursiv sletting og destruktiv SQL.

Det høres betryggende ut helt til man leser detaljene. Og det bør man. QMs eget sikkerhetsdokument sier rett ut at programvaren er tidlig og eksperimentell, og at scope-isolasjonen ikke er et løfte om at data aldri kan lekke.

Kommando-policyen kan omgås med tilsløring eller ved å skrive og kjøre et script. Nettleserhandlinger går utenom enkelte av kjernens godkjenningsporter. Nøkler er lesbare i klartekst av prosesser mens de brukes i sandkassen, og standardfangst av modellforespørsler kan gjøre at varige data lever lenger enn brukeren forventer.

Dokumentet lister også ufullstendig filtrering av data med blandede tillatelser, manglende secret scanning ved filskriving og en uferdig «kill switch» for hele organisasjonen. På den positive siden har prosjektet en forsinkelse på 7 dager før helt nye npm-pakkeversjoner kan havne i lockfilen, som et vern mot kortvarige angrep i leverandørkjeden.

Dette gjør ikke QM ubrukelig. Det gjør bare pilotprosjekt til et bedre første ord enn produksjonsplattform. Start med ufarlige data, få kontroll på logging og tilganger, og test hva hver agent faktisk kan nå. De samme spørsmålene gjelder også når man bruker sandboxing og guardrails i andre agentplattformer.

Hva krever det å ta QM i bruk?

QM er ikke en app du laster ned på en PC og åpner etter to minutter. Installasjonen oppretter et organisasjonseid deployment-repository, kobler inn pakken @yc-software/qm og setter opp målmiljøet i Fly.io eller AWS. Bedriften trenger også Postgres, innlogging, connector-nøkler og eventuelt Slack-oppsett.

Hver installasjon kjører i operatørens egen skykonto. Det gir kontroll over infrastrukturen og dataflyten, men også ansvar for drift, database, nettverk, identitetsleverandør, krypteringsnøkler og oppdateringer. Open source betyr at du får kildekoden og friheten til å endre den. Det betyr ikke gratis drift eller fravær av modellkostnader.

Det mest realistiske første prosjektet er derfor én avgrenset arbeidsflyt med tydelig eier. Prosjektoppfølging i en intern kanal, søk i et ufarlig dokumentsett eller en sandbox uten produksjonsnøkler er langt mer fornuftig enn å koble økonomisystem, e-post og kundedata samtidig.

Hvem passer QM for?

QM passer best for en teknisk bedrift som allerede har flere ansatte som bruker AI-agenter, og som kjenner smerten ved separate oppsett, overlappende nøkler og minne som flyter feil vei. Har du én bruker og én agent på en lokal maskin, er dette sannsynligvis langt mer plattform enn du trenger.

For små og mellomstore bedrifter er den viktigste ideen likevel verdt å merke seg: En bedriftsagent trenger ikke ett stort felles minne med tilgang til alt. Personer, rom og prosjekter kan ha separate arbeidsflater, og deling kan skje bevisst gjennom tillatelser. Det er sunnere enn å håpe at en lang systemprompt skal holde grensene på plass.

QM løser ikke alle problemene rundt agentisk arbeid. Sikkerheten er ikke moden, og egen drift krever kompetanse. Men Y Combinator har åpnet noe mer interessant enn en demo: et konkret forslag til hvordan mange ansatte kan bruke forskjellige agenter over samme organisatoriske grunnmur.

Det er hovedfunnet. Modellen er ikke lenger hele produktet. Når agentene flytter inn i arbeidsdagen, blir identitet, avgrensning, minne, varige miljøer og retten til å bytte leverandør minst like viktig. QM er tidlig ute, litt skarp i kantene og absolutt ikke klar for blind tillit. Men retningen er riktig.

Ofte stilte spørsmål