De fleste AI-agenter arbeider innenfor en fast ramme. Modellen får en oppgave, noen verktøy og et arbeidsområde. Hvis den mangler en funksjon, må en utvikler vanligvis bygge den inn før agenten kan bruke den.
Octopus OS prøver å snu på dette. I prosjektets egen beskrivelse kan agenten under en policy opprette og endre mål, triggere, verktøy, arbeidere og arbeidsmiljøer som påvirker senere oppgaver. Den kan altså være med på å endre vilkårene for sitt eget videre arbeid. [1]
Det er en stor idé. Men Octopus kaller seg selv en research preview, og prosjektet sier tydelig at «self-evolution» ikke er det samme som at systemet allerede har oppnådd selvforbedring. [1]
TL;DR
Octopus OS er en eksperimentell agentplattform som lar en agent foreslå endringer i verktøyene og arbeidsmiljøet rundt seg. Det er ikke en ferdig plattform for vanlige virksomheter. For de fleste norske småbedrifter er den praktiske lærdommen å bygge avgrensede agenter med logging, testmiljø og menneskelig godkjenning.
Den som vil teste prosjektet må også regne med teknisk oppsett: prosjektet oppgir macOS 14 eller nyere, Node 24, Rust og ChatGPT-konto. Den lokale pakken er heller ikke notarisiert for macOS. Test derfor bare i et separat miljø uten produksjonsnøkler eller kundedata. [1]
Hva er Octopus OS?
Octopus OS er en agentplattform bygget med prinsipper fra operativsystemer. I stedet for at hver integrasjon blir en spesialkobling inne i en stor agentloop, beskriver prosjektet systemet som en samling av avgrensede grensesnitt, arbeidsmiljøer, verktøy og regler.
Prosjektet oppgir at kjernen er skrevet i Rust og består av rundt 45 000 linjer kode. Det er likevel ikke dette som er hovedpoenget for en vanlig virksomhet. Det interessante er modellen for hvordan arbeid og tilgang organiseres rundt agenten. [1]
Octopus kan bruke filer, nettleser, skrivebord, apper og kontoer på samme måte som andre agenter. Forskjellen er at disse delene behandles som deklarerte komponenter i et system med grenser og policyer.
Hva betyr det at agenten kan endre arbeidsplassen sin?
Tenk på en agent som skal følge med på en bedrifts ordreinngang. I et vanlig oppsett kan den lese en mappe, bruke et bestemt verktøy og lage en rapport. Hvis dere senere vil at den også skal lese en temperatursensor eller starte en egen kontroll, må en utvikler koble dette inn.
I Octopus-modellen kan agenten i prinsippet opprette en oppgave for en annen arbeider som lager en ny driver eller et nytt grensesnitt. Når en verifikator har godkjent resultatet, kan den nye funksjonen registreres i systemet og bli tilgjengelig for senere arbeid. [1]
Det er dette som ligger bak formuleringen om at agenten kan «endre sitt eget harness». Et harness er ganske enkelt rammene rundt agenten: regler, kontekst, verktøy, tester og tilganger. Octopus skriver ikke nødvendigvis om Rust-kjernen mens den løper. Den kan heller forme miljøet rundt kjernen ved å opprette nye verktøy, triggere, arbeidere eller kontekstrammer.
Self-evolution er ikke det samme som self-improvement
Her er skillet som er viktigst å forstå:
| Begrep | Hva det betyr | Hva det ikke betyr |
|---|---|---|
| Self-evolution | Systemet endrer betingelsene, verktøyene eller arbeidsmiljøet for fremtidige oppgaver | At resultatene automatisk blir bedre |
| Self-improvement | Systemet blir faktisk mer effektivt, presist eller robust over tid | At enhver endring i systemet er en forbedring |
| Agentloop | Modellen får oppgave, bruker verktøy og lager et resultat | At modellen kan endre hele plattformen |
| Harness engineering | Mennesker bygger struktur, regler, tester og kontekst rundt modellen | At agenten får frie tøyler |
Et nytt verktøy kan gjøre en agent mer kapabel. Det kan også gi nye feil, større kostnader eller en uventet tilgang til data. Derfor må «systemet kan endre seg selv» alltid følges av spørsmålet: Hvem godkjenner endringen, og hvordan kan den rulles tilbake?
Hvordan er dette forskjellig fra en vanlig agent?
En vanlig chatbot svarer på en melding. En agent kan i tillegg lese filer, bruke verktøy og arbeide mot et mål. En orkestreringsløsning kan fordele oppgaver mellom flere agenter.
Octopus prøver å legge et ekstra lag oppå dette. Agenten skal ikke bare utføre arbeidet, men også kunne påvirke hvordan senere arbeid blir organisert.
| Systemtype | Typisk ansvar |
|---|---|
| Chatbot | Svarer på spørsmål og lager tekst |
| Agent | Utfører oppgaver med filer og verktøy |
| Fleragent-system | Fordeler oppgaver mellom spesialiserte agenter |
| Harness | Setter regler, kontekst, tester og tilgang rundt agenten |
| Octopus-modellen | Lar agenten også forme deler av fremtidig arbeidsmiljø under policy |
Dette er ikke nødvendigvis bedre for alle oppgaver. For en enkel kodeendring kan et vanlig verktøy være like nyttig. Octopus-prosjektet sier selv at det i en ordinær kodeoppgave ikke nødvendigvis gir mer enn Codex CLI allerede gjør. Forskjellen ligger i forskningsspørsmålet om langsiktig initiativ og utvikling. [1]
System, verden og deklarerte grenser
Octopus beskriver et skille mellom systemet og verden. Systemet er det agenten kan påvirke. Verden er alt utenfor. De møtes gjennom erklærte grensesnitt, som for eksempel en filmappe, en nettleser, en konto eller et verktøy.
Dette er en nyttig måte å tenke på også uten Octopus. En AI-agent bør ikke ha «tilgang til alt». Den bør ha tilgang til et bestemt område, med en bestemt rolle og et bestemt formål.
Prosjektet bruker blant annet disse byggesteinene:
- Interface: En typed inngang eller utgang for en tjeneste, sensor, kanal eller arbeider.
- Artifact: Det som krysser en grense, for eksempel en melding, en diff, et verktøykall eller et minne.
- Run: En varig registrering av en kjøring som kan stoppe og fortsette senere.
- Worker: En beskrivelse av en agentrolle og hva den maksimalt kan berøre.
- Policy: Reglene som bestemmer om en handling er tillatt.
- Mark: Et bevis på at en handling er gjennomført etter at en kontroll har passert.
For en bedrift kan dette sammenlignes med forskjellen mellom «en ansatt kan bruke datamaskinen» og «denne rollen kan lese ordredata, men ikke endre lønn eller sende betalinger». I et enkelt rapportcase kan et interface være koblingen til en testmappe, et artifact være rapportutkastet, et run være den loggførte kjøringen, og en mark være beviset på at en kontroll har godkjent rapporten før den deles.
Hva kan dette bety i praksis?
Foreløpig bør Octopus først og fremst leses som en mulig arkitektur, ikke som en ferdig produksjonsløsning. Men ideene kan gjøre det lettere å se for seg noen konkrete bruksområder.
En agent som bygger et nytt rapportverktøy
En agent får i oppgave å følge med på ordre, lager og kundeservice. Den oppdager at den mangler tilgang til et internt datasett. I stedet for å late som den kan løse oppgaven, oppretter den en avgrenset utviklingsoppgave for å lage en ny kobling.
Koblingen må testes mot testdata. En verifikator kontrollerer at den bare kan lese de avtalte feltene. Først etter godkjenning kan koblingen bli tilgjengelig for rapportagenten.
En agent som tilpasser oppfølgingen
En salgsagent kan ha et mål om å følge opp tilbud. Den kan oppdage at virksomheten trenger et nytt varsel når et tilbud har vært urørt i sju dager. I et kontrollert system kan den foreslå en ny trigger, men en person må godkjenne både regelen og hvem som får varselet.
Et lite AI-team som endrer arbeidsdelingen
Et system kan starte med én generell agent. Når oppgavene blir tydeligere, kan det opprette egne roller for research, kontroll, tekst og rapportering. Dette minner om tankene bak Paperclip og Hermes Kanban, men Octopus legger større vekt på at arbeidsmiljøet og arbeidsfordelingen kan formes underveis.
Hva betyr dette for harness engineering?
Harness engineering handler om å bygge miljøet rundt en modell slik at den kan arbeide på en mer stabil måte. Det kan være prosjektfiler, regler, tester, kontekst, verktøy, godkjenninger og logging.
Octopus tar denne tanken et steg videre: Harnesset er ikke bare noe utviklerne lager én gang. Det kan bli et objekt agenten foreslår å endre.
Det gjør god harness engineering enda viktigere. Før en agent får lov til å endre arbeidsmiljøet sitt, bør dere vite:
- Hvilket mål endringen skal støtte.
- Hvilke filer, kontoer og systemer den nye funksjonen kan berøre.
- Hvordan endringen testes.
- Hvem som godkjenner den.
- Hvordan dere ser hva som er endret.
- Hvordan dere ruller tilbake hvis noe går galt.
Artikkelen om Claude Code Mods viser en mindre og mer tilgjengelig variant av samme problem: En mod kan gjøre agenten mer synlig og nyttig, men får også rettigheter som må vurderes. Artikkelen om OpenClaw 2 viser en annen retning, der assistenten får minne, verktøy og en mer kontinuerlig arbeidsdag.
Den store sikkerhetsutfordringen
En agent som kan endre sitt eget miljø, kan også endre mer enn dere hadde tenkt. En feil i en ny driver kan føre til feil data. En for bred trigger kan starte oppgaver for ofte. Et nytt verktøy kan få tilgang til kundedata eller hemmeligheter som den opprinnelige agenten ikke hadde.
Derfor bør et slikt system ikke bygges rundt én stor «godkjenn alt»-knapp. En tryggere modell er å skille mellom nivåer:
| Nivå | Eksempel | Godkjenning |
|---|---|---|
| Lav risiko | Lage et utkast eller lese en testfil | Kan automatiseres med logging |
| Middels risiko | Opprette en ny intern rapport eller trigger | Krever gjennomgang |
| Høy risiko | Endre tilgang, koble på konto eller skrive til produksjon | Krever navngitt godkjenner og test |
| Ikke tillatt uten særskilt styring | Betaling, sletting eller publisering til kunder | Bør være blokkert eller håndteres utenfor agenten |
Octopus beskriver at bevegelser og avslag skal registreres i en ledger. Det er en god retning. Et avslag må også være synlig, slik at dere kan se hva agenten forsøkte å gjøre og hvorfor det ble stoppet. [1]
Bør en norsk bedrift bruke Octopus nå?
For de fleste små og mellomstore bedrifter er svaret foreløpig nei – ikke som produksjonsplattform. Kravene og modenheten er omtalt i TL;DR-en over, og de understreker at dette først og fremst er et prosjekt for teknisk utprøving i et separat miljø. [1]
Det betyr ikke at prosjektet er irrelevant. Det kan brukes som inspirasjon til å stille bedre spørsmål om egne AI-agenter:
- Hvilke deler av arbeidsflyten kan agenten endre?
- Hvilke endringer må godkjennes?
- Har vi testmiljø og versjonshistorikk?
- Kan vi se alle verktøykall og avslag?
- Kan vi stanse systemet uten å miste oversikten?
For en virksomhet som vil teste videre, er det tryggere å begynne med en avgrenset agent i et separat prosjekt, med testdata og uten produksjonsnøkler. Kom i gang med AI-agenter gir en mer praktisk og lavrisiko start.
Konklusjon
Octopus OS viser en mulig ny retning for AI-agenter: Systemet skal ikke bare bruke verktøy, men kunne være med på å forme verktøyene, arbeidsområdene og oppgavene som kommer etterpå.
Det er ikke det samme som at agenten allerede er selvforbedrende. Det er heller ikke et bevis på at en virksomhet bør gi en agent frie tøyler. Men det gjør en viktig forskjell synlig: Når AI får mulighet til å endre arbeidsplassen sin, blir arbeidsplassen en del av sikkerhetsmodellen.
For norske bedrifter er lærdommen praktisk. Bygg agenten med avgrensede rom. Loggfør handlinger og avslag. Test nye verktøy før de får tilgang til ekte data. Krev godkjenning for endringer med større rekkevidde. Og sørg for at noen mennesker fortsatt forstår og kan stoppe systemet.
Før en agent i det hele tatt får foreslå å endre arbeidsmiljøet sitt, bør grunnmuren være på plass. Harness Engineering fra grunnen av forklarer instruksjoner, tilstand, kontrollsløyfer og verifisering i en mer tilgjengelig rekkefølge.
Kilder
[1] Octopus Superintelligence OS — GitHub-repositoriet