Fra Bash-skript til AI-CTO

Fra Bash-skript til AI-CTO

Prateek Karnal hadde ikke som mål å bygge en AI som kunne lede programvareteam. Som de fleste byggere startet han med et spesifikt smertepunkt: å koordinere flere AI-kodingsagenter uten at de tråkket på hverandres arbeid eller satt seg fast i uendelige løkker. [7]

Den tradisjonelle tilnærmingen—ReAct-løkker hvor agenter resonnerer, handler og observerer i sekvens—fungerer fint for enkelt-agent-oppgaver. Men når du skalerer til flere agenter som jobber på samme kodebase, støter du på umiddelbare problemer. Agenter overskriver hverandres endringer. De kan ikke håndtere merge-konflikter. Når CI feiler, finnes det ingen klar eskaleringssti. Mest kritisk opererer de isolert uten å lære av hverandres suksesser og feil.

Composios gjennombrudd var å erkjenne at multi-agent-koordinering er fundamentalt forskjellig fra enkelt-agent-intelligens. I stedet for å gjøre individuelle agenter smartere, bygget de infrastruktur for å gjøre agent-team mer effektive. Resultatet er et system som autonomt kan fikse 84,6% av CI-feil på tvers av 41 testtilfeller og håndtere 68% av kodegjennomgangsproblemer uten menneskelig intervensjon. [3]

Men den virkelige valideringen kom da de vendte systemet mot seg selv. "Tingen som ble bygget var tingen som ledet sin egen konstruksjon," forklarer Karnal. "Vi ville se om et AI-system ikke bare kunne skrive kode, men lede en hel programvareutviklingsprosess." [2]

Arkitektur: Orkestreringslageret

I kjernen løser Agent Orchestrator tre fundamentale problemer som ødelegger tradisjonelle multi-agent-systemer: isolasjon, tilbakemeldingsruting og deteksjon av fastlåste agenter. [4]

Isolasjon skjer gjennom Git worktrees—hver agent får sin egen gren og arbeidsområde, noe som eliminerer filkonfliktene som plager naive multi-agent-oppsett. Når Agent A refaktorerer autentiseringssystemet mens Agent B legger til nye API-endepunkter, jobber de i helt separate miljøer frem til merge-tiden.

Tilbakemeldingsruting sikrer at CI-feil, kodegjennomgangskommentarer og merge-konflikter når de riktige agentene. I stedet for å kringkaste hver hendelse til hver agent (dyrt og støyende) eller håpe at agenter vil spørre etter oppdateringer (upålitelig), opprettholder orkestratoren en rettet graf over hvilke agenter som bryr seg om hvilke hendelser. Når en test feiler, får bare agentene som er ansvarlige for den kodestien beskjed.

Deteksjon av fastlåste agenter bruker JSONL-hendelsesporing for å identifisere når agenter slutter å gjøre fremgang. Tradisjonelle systemer stoler på timeouts eller manuell intervensjon. Agent Orchestrator ser etter mønstre—en agent som gjør det samme API-kallet gjentatte ganger, eller genererer identiske kodeendringer—og eskalerer eller omfordeler arbeid automatisk.

Plugin-arkitekturen gjør dette praktisk for ekte ingeniørteam. Åtte utskiftbare slots håndterer alt fra kjøretidsmiljøer (tmux, Docker, Kubernetes) til agenttyper (Claude Code, Aider, Codex) til arbeidsområdehåndtering (worktrees, kloner) til problemsporing (GitHub, Linear). [1]

Konfigurasjon skjer gjennom YAML-filer som definerer reaktive arbeidsflyter. Når CI feiler, prøv på nytt to ganger med samme agent, deretter eskaler til en senior agent, deretter varsle et menneske hvis det fortsatt feiler. Når en PR får gjennomgangskommentarer, rut dem til den opprinnelige forfatter-agenten først, deretter til en kodegjennomgangs-spesialist hvis ikke løst på 2 timer.

Selvbyggingen: 8 dager med autonom utvikling

Den mest overbevisende demonstrasjonen av Agent Orchestrators evner er dens egen skapelseshistorie. Fra 13.-20. februar 2026 bygget systemet seg selv med minimal menneskelig intervensjon—en virkelig stresstest av multi-agent-koordinering i stor skala. [2]

Tallene forteller historien: 30 samtidige agenter på topp, 747 commits, 102 pull requests med 86% opprettet av AI og 65% vellykket merget, 700 gjennomgangskommentarer med 99% håndtert av AI. Claude Opus 4.6 bidro med 512 commits mens Sonnet 4.5 la til 373. Menneskelig innsats: omtrent 3 fokuserte dager med høynivå-retning og eskaleringshåndtering.

Men de interessante innsiktene kommer fra feilmodusene. Merge-konflikter ødela opprinnelig systemet til agenter lærte å koordinere gjennom orkestrerens konfliktløsningsarbeidsflyter. Kodegjennomgangssykler skapte uendelige løkker til timeout- og eskaleringslogikk ble lagt til. Testfeil kaskadet på tvers av agenter til isolerte worktrees og målrettet tilbakemeldingsruting inneholdt skaden.

"Orkestrering betyr mer enn enhver individuell agentforbedring," reflekterer Karnal. "Spørsmålet er ikke hvor smart kan vi gjøre én agent, men hvor bra kan et system bli til å distribuere, observere og forbedre dusinvis av agenter som jobber parallelt." [2]

Selvbyggingen avslørte også emergente atferder som ikke var eksplisitt programmert. Agenter begynte å spesialisere seg—noen fokuserte på frontend-komponenter, andre på backend-tjenester, enda andre på testing og dokumentasjon. De utviklet uformelle overleverings-protokoller, med agenter som etterlot detaljerte commit-meldinger og PR-beskrivelser for sine kolleger.

Utover ReAct: Strukturerte arbeidsflyter for produksjon

Tradisjonelle AI-agenter stoler på ReAct-løkker—resonnér om problemet, utfør en handling, observer resultatet, gjenta. Dette fungerer for isolerte oppgaver men bryter sammen i komplekse, flertrinnsprosesser hvor handlinger har avhengigheter og sideeffekter. [3]

Agent Orchestrator introduserer strukturerte tilstandsbaserte arbeidsflyter med eksplisitt planlegger/utfører-separasjon. I stedet for at hver agent resonnerer om alt fra bunnen av, kartlegger en sentral planlegger arbeidet og tildeler spesifikke, avgrensede oppgaver til utfører-agenter. Dette reduserer kognitiv belastning på individuelle agenter mens global sammenheng opprettholdes.

Just-in-time verktøyruting betyr at agenter bare får tilgang til verktøyene de trenger for sin nåværende oppgave. En agent som jobber med frontend-styling trenger ikke databasemigrasjonsverktøy. En agent som fikser CI-feil trenger ikke tilgang til distribusjonspipelinen. Dette reduserer både kostnad (færre tokens i kontekst) og risiko (færre måter for agenter å forårsake utilsiktede sideeffekter).

Feilgjenopprettingsgrener håndterer realiteten at AI-agenter feiler på uforutsigbare måter. I stedet for å håpe at agenter elegant vil håndtere hvert edge case, definerer orkestratoren eksplisitte gjenopprettingsstier. Hvis en agent ikke kan løse en merge-konflikt etter 3 forsøk, eskaler til et menneske. Hvis CI fortsetter å feile på samme test, tildel en annen agent med frisk kontekst.

Resultatet er observerbarhet som faktisk hjelper med å debugge multi-agent-systemer. Tradisjonelle oppsett gir deg en vegg av agentlogger uten klar narrativ. Agent Orchestrator gir en tidslinjevisning som viser hvilke agenter som jobbet med hva, når de overleverte arbeid, hvor de satt seg fast, og hvordan konflikter ble løst.

Byggerens guide: Fra kaos til koordinering

Å komme i gang med Agent Orchestrator er bevisst enkelt: ao start <repo> spinner opp en grunnleggende konfigurasjon med fornuftige standarder. Men kraften kommer fra tilpasning for dine spesifikke utviklingsarbeidsflyter. [4]

Konfigurasjon starter med å definere dine agentroller. Ikke bare kast generiske kodingsagenter på problemer. Opprett spesialister: en frontend-agent som forstår ditt komponentbibliotek, en backend-agent kjent med dine API-mønstre, en test-agent som kjenner dine kvalitetsstandarder, en DevOps-agent som forstår din distribusjonspipeline.

Eskaleringsstier er kritiske for produksjonsbruk. Definer klare overleverings-regler: når gir en agent opp og ber om hjelp? Hvor lenge skal en agent jobbe med et problem før eskalering? Hvem får beskjed når systemet ikke kan gjøre fremgang? Selvbyggingen avslørte at de fleste feil skjer ved grenser—merge-konflikter, integrasjonstester, distribusjonsproblemer—hvor klar eskalering forhindrer uendelige løkker.

Tilbakemeldingsløkker trenger nøye tuning. For mye tilbakemelding skaper støy og forvirring. For lite etterlater agenter som jobber med foreldet informasjon. Det søte punktet er målrettet, handlingsbar tilbakemelding rutet til de spesifikke agentene som kan handle på det. CI-feil går til agentene som rørte den feilende koden. Kodegjennomgangskommentarer går til de opprinnelige forfatterne. Ytelsesregresjoner går til optimaliseringsspesialistene.

Menneske-i-løkken bør være minimal men strategisk. Agenter håndterer rutinemessig utførelse. Mennesker håndterer arkitektoniske beslutninger, kravavklaring og kompleks debugging. Målet er ikke å eliminere menneskelig dømmekraft men å fokusere den på beslutningene som betyr mest.

Hva endres når AI bygger programvaren

Agent Orchestrator peker mot et fundamentalt skifte i hvordan programvare blir bygget. Vi beveger oss fra individuelle produktivitetsverktøy (Copilot, Cursor) til autonome utviklingsteam hvor mennesker gir retning og agenter håndterer utførelse.

Dette handler ikke bare om hastighet—selv om produktivitetsgevinstene er betydelige. Det handler om å endre naturen til programvareutviklingsarbeid. Når agenter kan håndtere rutinekoding, testing og distribusjon, blir menneskelige utviklere arkitekter, produktdesignere og systemintegratorer. Flaskehalsen skifter fra å skrive kode til å ta beslutninger om hva som skal bygges og hvordan det skal organiseres.

Nordiske selskaper er spesielt godt posisjonert for denne overgangen. Regionens vektlegging av automatisering, systematisk tenkning og menneskesentrert design stemmer perfekt overens med orkestrert AI-utvikling. Mens Silicon Valley jager de siste modellforbedringene, fokuserer nordiske byggere på å gjøre AI-systemer pålitelige, forutsigbare og nyttige for ekte ingeniørteam.

Implikasjonene strekker seg utover individuelle selskaper. Når programvareutvikling primært blir om orkestrering heller enn implementering, skifter konkurransefortrinn. Selskapene som vinner vil ikke nødvendigvis ha de beste individuelle utviklerne—de vil ha de beste systemene for å koordinere AI-utviklingsteam.

Åpen kildekode blir enda mer kritisk i denne verdenen. Agent Orchestrators suksess kommer delvis fra dens åpne arkitektur—team kan tilpasse, utvide og bidra med forbedringer. Proprietære agentsystemer blir svarte bokser som ikke kan tilpasse seg spesifikke arbeidsflyter. Åpne orkestreringsplattformer blir grunnlaget for hele økosystemer av spesialiserte agenter og verktøy.

Post-kode-æraen: Orkestrering som den nye programmeringen

Vi går inn i det Up North AI kaller post-kode-æraen—ikke fordi kode forsvinner, men fordi å skrive kode blir en vare. Den knappe ressursen skifter fra implementering til dømmekraft: hva som skal bygges, hvordan det skal organiseres, når det skal sendes, hvordan det skal vedlikeholdes.

Agent Orchestrator representerer den første produksjonsklare infrastrukturen for denne overgangen. Den gjør utførelse til en vare mens den setter søkelys på menneskelig dømmekraft på arkitektur, koordinering og eskalering. Kode er gratis. Dømmekraft er det ikke.

Byggerne som trives i dette miljøet vil ikke være de raskeste koderne eller de mest produktive committerne. De vil være de som best forstår hvordan man orkestrerer autonome systemer for å oppnå menneskelige mål. De vil designe arbeidsflyter, definere kvalitetsstandarder og ta arkitektoniske beslutninger mens agenter håndterer det mekaniske arbeidet med implementering.

Dette er fremtiden for programvareutvikling: menneskelig kreativitet og dømmekraft som styrer AI-utførelse og -optimalisering. Agent Orchestrator viser oss hvordan den fremtiden ser ut—og den kommer raskere enn de fleste innser.

Kilder

1. https://github.com/ComposioHQ/agent-orchestrator
2. https://composio.dev/blog/the-self-improving-ai-system-that-built-itself
3. https://www.marktechpost.com/2026/02/23/composio-open-sources-agent-orchestrator-to-help-ai-developers-build-scalable-multi-agent-workflows-beyond-the-traditional-react-loops
4. https://mintlify.com/ComposioHQ/agent-orchestrator/introduction
5. https://composio.dev/
6. https://www.reddit.com/r/machinelearningnews/comments/1rd8cfk/composio_open_sources_agent_orchestrator_to_help
7. https://pkarnal.com/blog/open-sourcing-agent-orchestrator