Det er fristende å lete etter «den beste AI-modellen» og la den gjøre mest mulig. Men i praksis er det sjelden modellen alene som avgjør om en AI-løsning er nyttig. AI-orkestrering handler om å sette sammen hele arbeidsmåten: hvilken oppgave som skal løses, hvilken modell som egner seg, hvilke verktøy den får bruke, hvilken kontekst den får se, og når et menneske må kontrollere eller godkjenne resultatet.
En dyr modell med feil informasjon, for vide rettigheter og ingen kontrollrutine kan gjøre mer skade enn en enklere modell med en god arbeidsflyt rundt seg.
Fra «hvilken modell?» til «hvordan skal arbeidet flyte?»
En språkmodell kan skrive, oppsummere, sortere og resonnere. Men den kjenner ikke automatisk bedriften din, reglene dine eller hva som teller som et godt resultat. Den trenger et gjennomtenkt oppsett rundt seg. I teknisk språk kalles dette ofte et harness — seletøyet eller rammen som gjør at modellen kan jobbe målrettet og kontrollert.
OpenAI beskriver et agent-harness som laget som hjelper en modell å hente kontekst, bruke verktøy, arbeide innenfor konfigurerte grenser, be om godkjenning og føre arbeidet videre. [1] Med andre ord: Modellen er motoren. Harnesset er arbeidsbordet, oppgavelisten, tilgangskortet, sjekklisten og nødbremsen rundt den.
Hva er et harness i praksis?
Et harness trenger ikke være et stort utviklingsprosjekt. Det kan være en enkel og kontrollert arbeidsflyt i et verktøy dere allerede bruker. Poenget er at AI-en ikke bare får en løs prompt, men tydelige rammer for jobben.
| Del av harnesset | Det betyr i praksis |
|---|---|
| Kontekst | AI-en får riktig kundeinformasjon, interne regler, eksempler og avgrenset dokumentasjon — ikke hele virksomheten. |
| Verktøy | Den får bare tilgang til handlingene den faktisk trenger, som å lese en innboks, finne en sak eller lage et utkast. |
| Regler | Den får klare grenser: Ikke send, slett, lov pris, endre data eller ta faglige avgjørelser uten godkjenning. |
| Tilbakekobling | En test, sjekkliste eller menneskelig vurdering forteller om resultatet er godt nok eller må forbedres. |
| Sporbarhet | Teamet kan se hva AI-en brukte, gjorde og foreslo — og stanse den hvis noe ikke stemmer. |
Dette er grunnen til at to mennesker kan bruke samme modell og få helt ulike resultater. Den ene gir AI-en en kort beskjed i et tomt chatvindu. Den andre gir den en tydelig oppgave, relevante kilder, godkjente verktøy og en kontroll før handling. Modellen er kanskje den samme. Arbeidsmåten er ikke det.
Det videoen viser: Samme modell, ulikt resultat
I videoen som er lagt ved nederst i artikkelen, blir samme Qwen 3.8-modell, med samme vekter, kvantisering og prompt, kjørt gjennom ulike harness. I det ene tilfellet ender oppgaven i et svart vindu. I det andre får agenten en bedre arbeidsloop med verktøy og tilbakekobling, og leverer et fungerende visuelt resultat. [2]
Det er en teknisk demonstrasjon — ikke et løfte om at alle lokale modeller plutselig blir like gode som de dyreste tjenestene. Men lærdommen er viktig: Benchmark-tall og modellnavn forteller ikke hele historien. Resultatet påvirkes også av hvordan oppgaven brytes ned, hva agenten får undersøke, hvilke verktøy den kan bruke, hvor lenge den får jobbe, og hvordan den oppdager at første forsøk ikke holder.
Martin Fowler oppsummerer den samme tanken som «agent = modell + harness». Han løfter spesielt frem styringssløyfer, relevant kontekst, tester og menneskets rolle når agenter skal arbeide med mindre tett oppfølging. [3]
Harness engineering: arbeidsmiljøet rundt modellen
Guiden Learn Harness Engineering gjør harness-begrepet mer praktisk. Hovedpoenget er at dere ikke får en stabil agent bare ved å skrive en bedre prompt. Dere må bygge et arbeidsmiljø som styrer hva agenten leser, hva den får gjøre, hvordan fremdrift lagres og hva som teller som bevis på at oppgaven er ferdig.
Guiden deler et slikt miljø i fem deler:
- Instruksjoner: En kort `AGENTS.md` eller `CLAUDE.md` forklarer prosjektet, reglene og hvor mer detaljert dokumentasjon finnes.
- Tilstand: En fremdriftslogg, en feature-liste og Git-historikk gjør at neste økt kan fortsette uten å gjette hva som skjedde.
- Verifisering: Tester, lint, typekontroll eller en smoke test må kjøres før agenten kan si at arbeidet er ferdig.
- Avgrensning: Agenten velger én konkret funksjon eller leveranse om gangen, med en synlig definisjon av «ferdig».
- Livssyklus: En init-sjekk ved start og en ryddig overlevering ved slutt gjør neste økt enklere å starte.
Dette passer direkte med Claude Code, Codex og andre agentverktøy. Det kan også passe med Jev: Claude kan gjøre planlegging og produksjon, mens Jev tar avgrensede beslutninger i flyten. Harnesset bestemmer hvilke data som går inn, hvilke valg som stopper løpet, hvordan resultatet blir kontrollert og når et menneske må overta.
For en liten bedrift trenger dette ikke begynne som en stor plattform. Start med en prosjektmappe, en kort instruksjonsfil, en liste over oppgaver og en enkel kontroll som faktisk kan kjøres. En god første test kan være et internt dokumentutkast eller en liten kodeendring der agenten må vise hvilke filer den endret, hvilke tester som passerte og hva som fortsatt ikke er kontrollert.
Guiden har også en viktig praktisk lærdom: Ikke la agenten jobbe med tre halvferdige oppgaver samtidig. Velg én leveranse, gjør ferdig kontrollen og lagre status før neste økt. Det reduserer risikoen for at agenten hopper videre, glemmer en feil eller erklærer en uferdig løsning som ferdig.
Omnigent: Et kontrollag over agentene
Omnigent er et aktuelt eksempel når én arbeidsflyt begynner å bruke flere modeller eller agentmiljøer. Prosjektet beskriver seg som en åpen kildekode-meta-harness: et lag som kan legge en felles sesjon, policy og sandbox rundt blant annet Claude Code, Codex, Hermes, Pi og egne agenter. [4]
Det er ikke det samme som å velge «enda en agent». Tenk heller på Omnigent som laget over agentene: Det gjør det mulig å bytte eller kombinere utførere, men beholde felles regler for tilgang, kostnad, historikk og menneskelig godkjenning.
| Løsning | Primær rolle |
|---|---|
| OpenClaw | Arbeids- og kommunikasjonslag for en alltid-på assistent, kanaler, minne og verktøy. |
| Hermes Kanban | Vedvarende oppgaveflyt og overlevering mellom tekniske agentprofiler. |
| Paperclip | Styring av mål, status, oppgaver, kostnad og governance. |
| Omnigent | Meta-harness som legger felles policy, sandbox og sesjon rundt flere agentharness. |
Dette kan være interessant i tekniske team som allerede bruker mer enn ett miljø. Men Omnigent er fortsatt oppgitt som alpha. Se det derfor som et utviklerverktøy og en kontrollert testarena, ikke som en ferdig standard for drift av kundedata eller produksjonssystemer. Start med én avgrenset oppgave, egne testnøkler og en policy som stopper skal- og filhandlinger til en ansvarlig person har godkjent dem.
Videoen «Getting Started with Omnigent» viser grunnoppsettet, mens Tiiny x Omnigent demonstrerer hvordan ulike agenter kan kombineres. Se begge som produktdemonstrasjoner, ikke som dokumentasjon på at en bestemt arbeidsflyt er trygg eller lønnsom hos dere.
Et eksempel fra en liten bedrift: Nye kundehenvendelser
Se for deg at en bedrift får henvendelser fra nettside, e-post og Facebook. Uten et harness kan du be en AI: «Håndter innboksen.» Det er en uklar og risikabel oppgave. Med et enkelt harness blir den tryggere:
- AI-en får bare se nye henvendelser i en avgrenset kø.
- Den bruker bedriftens godkjente tjenester, åpningstider og tone som kontekst.
- Den foreslår kategori, hastighet og et kort svarutkast.
- Den kan ikke sende noe, opprette avtale eller love pris uten menneskelig godkjenning.
- Hvis informasjon mangler eller saken er følsom, skal den flagge saken og stoppe.
Her kan en lettere og rimeligere modell være god nok til sortering og førsteutkast. En sterkere modell kan brukes når saken krever mer analyse, et vanskelig dokument eller et større planarbeid. Orkestrering betyr ikke at alt må automatiseres. Det betyr at hver del får et passende nivå av AI og kontroll.
Dette ligner på hvordan en god arbeidsplass fungerer. Ikke alle saker går til daglig leder. Ikke alle oppgaver trenger en spesialist. Men alle trenger klare overleveringer, riktig informasjon og noen som er ansvarlig når konsekvensene blir store.
Hvorfor dette er viktigere enn en «billig modell»
Noen snakker om orkestrering mest som kostnadskutt: bruk en mindre eller lokal modell til billige oppgaver, og spar den sterke modellen til det vanskelige. Det kan være fornuftig. Men en billig modell som får gjøre feil handling i et CRM-, økonomi- eller kundesystem blir fort dyr.
Det mest verdifulle er derfor ikke bare å finne lavest mulig pris per forespørsel. Det er å finne en arbeidsflyt som gir godt nok resultat, er lett å kontrollere og kan stoppes. Lokal kjøring kan i enkelte situasjoner gi mer teknisk kontroll over dataflyt, men det gjør ikke en løsning automatisk GDPR-riktig eller sikker. Dere må fortsatt vurdere hvilke data som brukes, tilgangene som gis, logging, leverandører og hvem som har ansvar.
Slik starter du med orkestrering uten å bygge en stor plattform
Start med prosesskartlegging. Finn én oppgave som gjentar seg ofte, har en tydelig start og slutt, og tåler at et menneske godkjenner før noe skjer. Det kan være å sortere henvendelser, klargjøre møteagendaer, oppsummere prosjektstatus eller finne avvik som en person skal se på.
Deretter bestemmer dere hvilke kilder AI-en trenger, hvilke handlinger den aldri skal gjøre alene, og hvordan dere måler om resultatet er nyttig. Når arbeidsflyten er tydelig, kan MCP og Connectors hjelpe dere å knytte AI-en til godkjente verktøy på en mer strukturert måte. Og hvis oppgaven trenger flere forsøk og kvalitetskontroller, forklarer Loop Engineering hvordan en tydelig feedback-sløyfe kan bygges inn.
Den beste første agenten er ikke den som får tilgang til mest. Det er den som løser én nyttig oppgave, viser hva den gjorde og stopper når den er usikker.
Når blir dette teknisk fordypning?
Når dere begynner å bytte mellom lokale og skybaserte modeller, sette opp egne agentmiljøer, styre langvarige oppgaver eller lage avanserte feedback-sløyfer, er dere over i teknisk fordypning. Da kan det være relevant å lese om Qwen og autonomt arbeid, Omarchy og de andre artiklene i den tekniske delen av artikkeloversikten.
For de fleste små og mellomstore bedrifter på Sunnmøre er det likevel mer verdifullt å starte nøkternt: velg én arbeidsflyt, bygg et lite harness rundt den og mål om den faktisk sparer tid eller gjør arbeidet bedre. Ta kontakt hvis dere vil vurdere en trygg første pilot.
Vil dere gå fra prinsipp til et konkret arbeidsmiljø for en agent, forklarer Harness Engineering fra grunnen av hvordan instruksjoner, prosjektkontekst, minne, tester og stopppunkter kan bygges opp steg for steg.
Kilder
[1] OpenAI Developers — Codex as a platform: build on the open agent harness
[2] Kai på YouTube — You Don't Need Frontier Models Anymore (Qwen 3.8 27B + DeepSeek Harness)
[3] Martin Fowler — Harness engineering for coding agent users
[4] Omnigent — åpen kildekode-meta-harness for AI-agenter [5] Walking Labs — Learn Harness Engineering