Databricks har frigivet Omnigent som open source under Apache 2.0. Kort fortalt er det et meta‑lag over AI‑agenter, der gør dem udskiftelige, mere styrbare og nemmere at dele i teams. Ifølge Databricks’ egen præsentation (Marktechpost‑referencen) samler Omnigent tre ting: composition, control og collaboration. Det lyder abstrakt. Det er det ikke. Det er et forsøg på at gøre hverdagen med flere forskellige agenter mindre rodet – og mere enterprise‑klar.
Nyhedsværdien lige nu er, at mange udviklingsteams allerede kører flere agenter parallelt. Tekst flyttes rundt mellem coding‑agenter, søgeværktøjer, Docs, Slack. Det koster tid og spilder kontekst. Omnigent lægger et fælles lag ovenpå, så man kan bytte mellem Claude Code, Codex og Pi uden at omskrive kode, sætte politikker på adfærden og dele en live session med en kollega via en URL. Hvis det holder i praksis, forkorter det vejen fra idé til forsøg – og måske til drift.
Hvad er Omnigent — konkret
Omnigent beskrives som en “meta‑harness”. En harness er i Databricks’ ordvalg det stykke software, der pakker en model ind og gør den til en agent i terminalen eller et SDK. Eksemplerne, som kilden nævner, er Claude Code, Codex og Pi. Omnigent ligger et niveau over de enkelte harnesses og behandler dem som udskiftelige moduler i et større system (Marktechpost‑referencen).
I praksis betyder det, at Omnigent både kan wrappe terminal‑agenter (som de tre nævnte) og også arbejde med agent‑SDK’er som OpenAI Agents og Claude Agents SDK. Interfacet standardiseres: beskeder og filer ind; tekststrømme og værktøjskald ud. Det er standardiseringen, der gør udskifteligheden mulig.
Hvordan det virker — arkitekturen
Arkitekturen er todelt, ifølge kilden: en runner og en server. Runneren pakker enhver agent ind i en sandboxed session med et ensartet API. Serveren leverer politikker og deling på tværs. Hver session eksponeres i terminalen, i en app og via web‑API’er. Én kommando starter en session og åbner en lokal web‑UI på localhost:6767. Den samme session kan ses i browseren og på telefonen – med synkroniserede beskeder, underagenter, terminaler og filer (Marktechpost‑referencen).
CLI’en installerer under to navne, omnigent og omni, og kører ens. Ved første kørsel detekterer Omnigent de model‑credentials, der allerede ligger i miljøet. Små detaljer – men de afgør, om noget kører på fem minutter eller først i morgen.
Komposition i praksis: skift modeller uden at omskrive kode
Komposition‑tanken handler om at sammensætte modeller, harnesses og teknikker uden at rive kodebasen fra hinanden. Ifølge Databricks’ beskrivelse kan man skifte mellem Claude Code, Codex, Pi og egne agenter med en‑linje ændringer. Fordi interfacet er ens, kan CI/CD‑pipelines genbruge de samme tests, logs og scripts, mens man eksperimenterer.
I udviklerhverdagen ligner det her: en session mod Claude Code bliver for langsom til refaktorering af en stor monorepo. Man bytter til en anden harness med bedre værktøjskald til netop den opgave. Beskeder og filer går ind på samme måde, output kommer som tekststrømme og tool calls. Det giver kortere feedback‑loops i eksperimenter. Men det kræver også disciplin i testdata og kontrakter, så “ens interface” faktisk er ens nok i praksis, når edge cases rammer.
Control: governance og sikkerhed i meta‑laget
Kontrol‑delen er der, hvor det bliver interessant for drift og compliance. Omnigent beskrives som et lag, der kan håndhæve stateful, kontekstuelle politikker. Eksemplerne i kilden er konkrete: pause et run efter hver 100 dollars forbrug, eller kræv menneskelig godkendelse, før en git push kan gennemføres, når agenten lige har installeret en ny npm‑pakke. Det er politikker for adfærd, ikke bare prompt‑tricks.
Under det ligger Omnibox, et OS‑sandboxlag, der kan låse OS‑adgang ned og transformere netværksanmodninger. Et eksempel fra kilden: GitHub‑tokenet holdes skjult for agenten og injiceres kun i egress‑proxyen på godkendte kald. Det mindsker eksponerede hemmeligheder. Men det er ikke fuld procesisolering alene. Netværkstransformation er stærkt, men man må stadig tænke i namespaces, container‑sandboxing og klare netværkspolicys, hvis trusselsmodellen er skarp.
Collaboration: live deling og synkronisering
Deling sker via URL: teamkolleger kan se agenten arbejde live, chatte med den i realtid, kommentere på filer, co‑drive sessionen eller forke samtalen. Ifølge Marktechpost‑gennemgangen er hele sessionen synkroniseret mellem terminal, web og telefon. Det giver oplagte fordele i support og pair‑programmering. Samtidig rejser det driftsspørgsmål: hvem må se hvad? Hvad logges, hvor længe, og hvordan maskeres hemmeligheder i live‑delestrømme.
Det lyder småpraktisk, men i en incident midt på dagen kan en synkroniseret session gøre forskellen mellem at sidde fast og at løse problemet et kvarter hurtigere. Bagsiden er klar: deling øger risikoen for utilsigtet dataeksponering, hvis adgangskontrollen ikke er knivskarp.
Use cases og eksempler
To eksempelagenter følger med repoet: Polly og Debby. Polly er en multi‑agent orkestrator til kode. Den skriver ikke selv kode; den planlægger og delegerer til coding‑underagenter i parallelle git‑worktrees. Hvert diff sendes til review hos en anden leverandør end den, der skrev ændringen. Merging er op til mennesket. Debby er en idémakker med to hoveder: Claude og GPT. Samme spørgsmål sendes til begge, og svar vises side om side. Med kommandoen /debate lader man de to kritisere hinanden, før de konvergerer (Marktechpost‑referencen).
I en bredere kontekst ligner værditesen den, man ser i andre agent‑drevne forløb. AWS beskriver eksempelvis i en separat case, hvordan Rocket Close byggede “Supercharger” for at strømline tinglysnings‑ og titelarbejde med agentisk AI og Bedrock‑services. Det er ikke Omnigent, men illustrerer værdien i orkestrerede agenter, der trækker viden sammen og guider teams gennem tunge processer (AWS‑kilden). Overfør det mønster til udvikling, dokumentanalyse eller kundesupport: én planlæggende agent, flere udførende underagenter, ensartet deling og styring.
Implementeringsrealiteter og tradeoffs
Credential management: Omnigent opdager eksisterende model‑nøgler ved første kørsel og kan skjule dem via Omnibox’ egress‑injektion. Det forenkler opstarten, men rejser krav til, hvor nøgler opbevares, rotation, og hvordan maskinelle godkendelser auditeres. Uden en klar nøglepolitik kan bekvemmelighed hurtigt blive en sikkerhedsrisiko.
Drift: Lokal vs. cloud. Omnigent starter let lokalt, men enterprises vil før eller siden lægge det i en kontrolleret runtime – containeriseret, med netværks‑policies, IAM‑bindinger og central logging. Hvordan Omnigent skalerer til mange samtidige sessioner er ikke beskrevet i kilden. Det er et hul, der bør lukkes, før man lover SLO’er.
Performance: Koordinering af flere agenter kan øge latens. Kilden leverer ingen produktions‑benchmarks for throughput eller svartider under belastning. Det betyder, at hvert team bør måle egne workloads, især hvis planlægnings‑agenten skal orkestrere flere parallelle workers med stramme tidskrav.
Logs og audit: Collaboration og control er kun værdifuldt, hvis hændelser kan spores. Hvem gjorde hvad, hvornår, på hvilket datasæt. Det kræver et bevidst design af logstruktur, retention‑politik og adgangsstyring, så audit ikke bliver endnu et kaoslog‑lager.
Komposition i CI/CD og QA
Udskiftelighed er en gave til eksperimenter – og en udfordring for QA. Når samme interface dækker flere harnesses, kan subtile forskelle i tool‑calling, fejlmeddelelser og filhåndtering give regressionsfejl. En praktisk tilgang er kontrakttests for agent‑interaktioner, fikserede testprompter og goldens for kritiske værktøjskald. Ellers bliver “én linje” i koden til ti linjer i incident‑kanalen.
Deployment‑modellen bør skelne skarpt mellem eksperimentelle sessions og godkendte flows. De to må ikke dele nøgler og netværksruter. Og policies som “pause efter $100” skal testes i staging med realistiske opgaver, ellers bliver de enten for stramme eller ligegyldige.
Sikkerhedsbilledet i praksis
Omnibox’ idé om at transformere netværk og gemme tokens i egress‑leddet er fornuftig. Men isolation er lagdelt. Reelle enterprise‑mål kræver proces‑/container‑sandboxes, read‑only filsystemer, proxy‑tilladelser per destination og scanning af downloads og npm‑pakker. Omnigent kan være kontrolplanet – ikke hele muren.
Et andet hjørne: session‑deling via URL. Det er praktisk, men kræver entydig mapping mellem sessioner og brugere, MFA for adgang, scopes for hvilke filer og værktøjer en gæst må aktivere, samt klart banner for “recording on”, hvis sessions logges for audit. Små detaljer. Men de afgør, om compliance hænger sammen.
Risici og uafklarede punkter
Skalerbarhed: Kildematerialet beskriver funktioner, men ikke, hvordan systemet skalerer på tværs af mange samtidige brugere og sessions. Ingen tal for kø‑dybder, state‑håndtering eller horisontal skalering. Det er en åben kant, som gør enterprise‑løfter svagere, indtil der foreligger erfaringer.
Ydelse: Ingen målinger for latens eller omkostninger ved at koordinere flere agenter. Det kan være glimrende, men uden benchmarks skal teams selv bevise det i egne miljøer, før kritiske flows flyttes.
Sikkerhedsgarantier: Omnibox beskrives som en OS‑sandbox og egress‑proxy med token‑injektion, men styrken af isolation – og kendte angribsmønstre – er ikke dokumenteret i kilden. Her kræves ekstra due diligence og sandsynligvis egne sikkerhedstests.
Interoperabilitet: Understøttelsen nævner Claude Code, Codex, Pi samt bl.a. OpenAI Agents og Claude Agents SDK. Der står ikke meget om niche‑harnesses, proprietære værktøjer eller indsatsen for at bygge nye adapters. Det kan blive et integrationsarbejde, som først ligner en time – og ender på en uge.
Afhængighed af Neon: Marktechpost skriver, at Databricks AI‑teamet byggede Omnigent med Neon. Hvad det præcist betyder for kompatibilitet, licens og performance er ikke foldet ud. Uden klarhed vil nogle teams køre ekstra kompatibilitetstests, før de standardiserer på platformen.
Hvad bør virksomheder gøre nu
Start småt: vælg et lavrisiko‑workflow, hvor agent‑udskiftelighed er en gevinst. Et sandboxet miljø, faste testprompter, goldens på kritiske værktøjskald. Mål tid, kvalitet og omkostning.
Gennemspil governance: implementér policies for forbrug (f.eks. pause ved 100 dollars), human‑in‑the‑loop ved sensitive handlinger (git push, dataeksport), og test nøgle‑injektion via Omnibox. Verificér, at hemmeligheder ikke kan lækkes via logs, delte links eller fejlhåndtering.
Observability før skala: definér logstruktur, event‑skema og retention, og sørg for, at collaboration‑funktionerne efterlader et meningsfuldt audit‑spor. Uden det er deling bare en risikofaktor.
Evaluer leverandøruafhængighed: open source og Apache 2.0 er et stærkt udgangspunkt. Men kortlæg stadig afhængigheder (herunder Neon), SDK‑versioner og adaptere. Lav en plan for rollback, hvis en harness skiftes ud – inklusive kontrakttests og incident‑procedure.
Konklusion
Omnigent er et ambitiøst forsøg på at standardisere, hvordan teams komponerer, styrer og deler AI‑agenter. Ifølge Marktechpost‑referencen får man et meta‑lag, der kan orkestrere Claude Code, Codex, Pi og agent‑SDK’er under samme paraply, med politikker og live‑deling ovenpå. Det er et vigtigt skridt – især hvis hverdagen i forvejen er fem åbne agenter og copy‑paste mellem dem.
Men nogle nøgletal og drifterfaringer mangler stadig: skalering, performance under belastning og den hårde sikkerhedsafprøvning. Den kloge vej er en fokuseret pilot med klare guardrails og målinger. Man opdager først forskellen, når man sidder med det i hænderne.
