OpenRig og AI-routing: Når flere agenter blir ett arbeidslag

Når man begynner å bruke flere AI-verktøy, oppstår det fort et praktisk problem: Hvilken modell skal gjøre hvilken oppgave – og hvordan skal flere agenter samarbeide uten at det blir en samling løse terminalvinduer?

OpenRig er et åpen kildekode-prosjekt som prøver å løse den siste delen. Det bygger et fast styringslag rundt flere harnesser – altså agentmiljøer som gir en modell verktøy, arbeidsområde, regler og en måte å utføre oppgaver på. OpenRig kan samle blant annet Claude Code, Codex og Pi. Du kan definere et team med roller i YAML, starte det som én rigg og følge arbeidet gjennom CLI, terminalgrensesnitt eller MCP.

OpenRig er derfor relevant i en diskusjon om routing, men det er viktig å bruke ordene riktig: Det er først og fremst et koordineringslag for arbeid mellom agenter og roller. Det er ikke en modellrouter som automatisk velger mellom GPT, Claude, Gemini eller en lokal modell for hvert enkelt spørsmål.

Tre forskjellige typer routing

Ordet «routing» brukes ofte om flere ting. Før dere velger verktøy, er det nyttig å skille mellom tre nivåer.

Et godt system kan bruke alle tre, men de løser ulike problemer.

Hva er OpenRig?

OpenRig beskriver seg som et system der en harness omslutter en modell, mens en rig omslutter flere harnesser. Tanken er at Claude Code, Codex eller Pi kan kjøre i egne sesjoner, men likevel organiseres i en vedvarende struktur.

Du kan definere:

• Rigs – den overordnede agentgruppen
• Pods – grupper av agenter med nærstående oppgaver
• Seats – stabile roller, som `builder`, `reviewer` eller `lead`
• Edges – forbindelser og overleveringer mellom rollene
• AgentSpecs – gjenbrukbare beskrivelser av kompetanse, regler og oppstart
• Continuity policies – regler for hva som skjer etter omstart eller avbrudd

OpenRig har også en lokal daemon, CLI, TUI, SQLite-lagring, tmux-sesjoner og MCP-verktøy. Det betyr at agenter kan sende meldinger, dele status, oppdage eksisterende sesjoner og starte eller stoppe deler av riggen.

Dette er en annen type løsning enn en vanlig chat-app. Målet er ikke bare å få ett svar, men å holde en arbeidsgruppe i gang over tid.

OpenRig sammenlignet med en modellrouter

En modellrouter ligger vanligvis mellom applikasjonen og flere modelltilbydere. Den kan gi ett felles API og velge modell basert på pris, kapasitet, kvalitet, tilgjengelighet eller type oppgave.

LiteLLM er et eksempel på et slikt gateway- og routingmønster. OpenRig kan brukes ved siden av en slik løsning, men erstatter den ikke. En typisk modellrouter kan for eksempel ha denne logikken:

• kort klassifisering: lokal modell
• vanlig tekstutkast: rimelig skymodell
• krevende analyse: sterkere modell
• personfølsomt dokument: lokal eller godkjent europeisk modell
• utilgjengelig leverandør: reserveleverandør

OpenRig gjør noe annet. Den kan ha en `lead`-agent som sender en kodeoppgave til en `builder`, ber en `reviewer` gå gjennom endringen og lar en `qa`-rolle kjøre tester. Hvilken modell Claude Code eller Codex bruker inne i hver rolle er et eget valg.

En enkel måte å huske forskjellen på er:

Modellrouteren velger motor. OpenRig organiserer sjåførene, oppgavene og arbeidslaget.

Et konkret eksempel

Tenk at en bedrift vil bygge et lite internt system for å registrere serviceoppdrag.

Med bare én agent kan man be den lage alt. Det kan fungere for en prototype, men det er lett å overse testing, tilgangsstyring og dokumentasjon.

Med en rigg kan arbeidsflyten se slik ut:

1. Lead bryter prosjektet ned i avgrensede oppgaver.
2. Builder lager første versjon i et eget arbeidsområde.
3. Reviewer vurderer kode, risiko og brukervennlighet.
4. QA kjører tester og prøver feilsituasjoner.
5. Lead oppsummerer hva som er klart og hva som må godkjennes av en person.

I dette eksempelet er OpenRig nyttig fordi rollene, sesjonene og overleveringene kan være vedvarende. Hvis maskinen starter på nytt, finnes det en struktur å gjenopprette i stedet for en rekke uforståelige terminalvinduer.

Det gjør likevel ikke systemet autonomt på en trygg måte av seg selv. Tilganger, arbeidsområder, git-regler, secrets, testdata og godkjenningspunkter må fortsatt settes opp av mennesker.

Hvor kommer lokal og skybasert AI inn?

Et OpenRig-team kan i prinsippet bruke ulike modeller i ulike roller. En enkel dokumentasjonsagent trenger kanskje ikke samme modell som en agent som skal analysere en vanskelig kodebase.

Her kan modellrouting og agentorkestrering kombineres:

• en lokal modell gjør en første sortering av ufølsomme oppgaver
• en sterkere modell lager et forslag til arkitektur
• en kodeagent gjør endringen i et avgrenset repository
• en separat reviewer kontrollerer resultatet
• en menneskelig ansvarlig godkjenner før publisering

Dette må ikke forveksles med at aktiv parameterstørrelse alene bestemmer kostnad eller kvalitet. Kolibri 1-artikkelen viser hvorfor en MoE-modell kan ha få aktive parametere, men fortsatt kreve mye GPU-minne. DeepGEMM-artikkelen viser det enda lavere infrastrukturnivået: hvordan GPU-kjernene under modellene optimaliseres.

For de fleste bedrifter vil det være mer praktisk å starte med en ferdig tjeneste eller en mindre lokal modell. Artikkelen om offline AI og Tiiny forklarer når lokal kjøring kan være interessant, og når skyen er enklere.

OpenRig, Bionic, OpenClaw og Paperclip

OpenRig kan plasseres i et landskap med flere forskjellige typer verktøy:

• LM Studio Bionic er et agentmiljø for å arbeide med åpne modeller, lokalt eller i skyen.
• OpenClaw 2 er mer rettet mot en assistent som har minne, verktøy og en arbeidsdag.
• Paperclip og Hermes Kanban handler om hvordan oppgaver, mål og status kan organiseres når flere agenter samarbeider.
• Loop Engineering handler om feedback-sløyfer som får en agent til å forsøke, kontrollere og forbedre et resultat.
• Gauntlet Loop og /goal viser en mer målrettet variant, der agenten arbeider mot en definert sluttbetingelse.

Forskjellen er ikke alltid knivskarp, og verktøyene kan overlappe. Men de har ulike tyngdepunkter:

Hva OpenRig ikke løser

Det er lett å tro at en rigg automatisk løser de største problemene med agenter. Det gjør den ikke.

OpenRig sørger ikke automatisk for at:

• modellen har rett faglig svar
• en agent ikke sletter feil filer
• hemmeligheter ikke havner i logger
• en reviewer faktisk oppdager alle feil
• et eksternt verktøy har riktig tilgang
• kostnadene holder seg innenfor budsjettet
• personopplysninger behandles lovlig

OpenRig-dokumentasjonen advarer blant annet om at oppstart kan skrive hooks, trust-innstillinger og andre konfigurasjoner i agentmiljøene. Det bør leses før installasjon. Ta sikkerhetskopi av relevante filer, bruk testkontoer og start med et repository som ikke inneholder produksjonshemmeligheter.

Prosjektet krever macOS eller Linux, Node.js 22 eller 24 og tmux. Native Windows er ikke støttet ennå, og WSL2 er ikke testet ifølge README-en. Det gjør OpenRig mest relevant for tekniske team som allerede arbeider i terminalen.

En tryggere start for en liten bedrift

For en liten eller mellomstor bedrift er det sjelden riktig å starte med et stort agentteam. Begynn heller slik:

1. Velg én avgrenset oppgave, for eksempel å foreslå tester til et lite internt prosjekt.
2. Bruk et separat repository uten produksjonsnøkler.
3. Start med én builder og én reviewer.
4. La alle endringer skje i en gren som et menneske må godkjenne.
5. Logg hvilke modeller, verktøy og data som ble brukt.
6. Mål tidsbruk, feil og kostnad før dere utvider riggen.

Dette følger samme prinsipp som i artikkelen om AI-orkestrering: En god arbeidsflyt begynner med rolle, ansvar, kilder og stoppunkter – ikke med flest mulig agenter.

Før dere installerer OpenRig, bør dere også lese Trendslop-artikkelen. Den handler om risikoen ved å bygge en imponerende teknisk arkitektur før man har dokumentert hvilket problem som faktisk skal løses.

Når er OpenRig relevant?

OpenRig er mest interessant når dere:

• allerede bruker Claude Code, Codex eller tilsvarende terminalagenter
• har et utviklerteam som trenger faste roller og overleveringer
• arbeider med oppgaver som varer i dager eller uker
• vil kunne gjenopprette agentarbeid etter avbrudd
• ønsker en åpen og lokal kontrollflate fremfor et lukket SaaS-team
• trenger å se hvilke agentprosesser som faktisk kjører

Det er mindre relevant hvis dere bare vil ha en chat-assistent, sortere noen dokumenter eller lage et enkelt tekstutkast. Da er et vanlig chatverktøy, en enkel agentharness eller en ferdig automatisering sannsynligvis mer passende.

Konklusjon

OpenRig er interessant fordi det flytter oppmerksomheten fra «hvilken agent er smartest?» til «hvordan organiserer vi flere harnesser slik at de kan arbeide sammen over tid?».

Det gjør OpenRig til et supplement til modellrouting, ikke en direkte erstatning for den. En modellrouter velger modell. En harness gir en agent verktøy og arbeidsmiljø. OpenRig organiserer flere slike miljøer i en vedvarende rigg.

For de fleste virksomheter er den riktige rekkefølgen:

1. kartlegg arbeidsflyten
2. velg hvilke data og verktøy AI-en faktisk trenger
3. test én agent på én avgrenset oppgave
4. legg til routing når dere har flere modeller eller datakrav
5. legg til flere roller først når overleveringene gir målbar verdi

Flere agenter er ikke automatisk bedre. Men når oppgavene er tydelige, kontrollpunktene er synlige og ansvaret er plassert, kan OpenRig bli et interessant styringslag for mer langvarig AI-arbeid.

Kilder

• OpenRig på GitHub
• LiteLLM