Maguyva Blog

Kontekst der rejser med dig

Mon, 07 Sep 2026 00:00:00 GMT

Cursors indekser er fremragende inde i Cursor. Tabulator-autofuldførelse, inline-redigering, chat, og agenten i det vindue hviler allerede på et projektindeks, som Cursor driver for det åbne arbejdsområde. Hvis Cursor er den eneste flade, du skriver i, og det indeks allerede finder de rigtige filer, så bliv der. Det er det ærlige ‘bliv hvor du er’-tilfælde, og det fortjener at være den første sætning på denne side.

Denne tekst handler om den anden halvdel af en almindelig uge. Det samme repository åbnes også i Claude Code, spørges fra Codex CLI, gennemgås på en anden maskine, eller spørges af en agent, der kører i CI. Spørgsmålet er ikke ‘hvilken indekser er bedre’. Spørgsmålet er, om det kort, agenten stoler på i ét vindue, er det samme kort, den stoler på i det næste.

Maguyva er det kort, der rejser med dig. Det er et fjernt MCP-lag for kodebasekontekst. Agenten spørger det på samme måde, som den spørger ethvert andet MCP-værktøj. Resultaterne kommer tilbage som rangerede stier med linjenumre. Cursor forbliver editoren. Det er konteksten, der flytter sig.

Hvad Cursors indekser er til

Cursors indbyggede indeksering findes, så chat, agent og søgning inde i editoren kan hente relevant kode i stedet for udelukkende at stole på det, der passer i modellens rå kontekstvindue. Det er det rigtige design til en IDE. Dette indeks er nativt for Cursor. Det er ikke en MCP-server og er ikke tilgængeligt fra nogen anden klient.

Sådan fungerer det, som beskrevet i Cursors offentlige dokumentation og Cursors egen fremstilling på skrivetidspunktet: den primære søgevej er ikke længere et cloud-embeddingindeks. Cursors team har udtalt på deres community-forum, at dedikeret semantisk, embedding-baseret søgning trappes ned til fordel for grep-baseret hentning, fordi nutidens modeller allerede udforsker et levende træ godt nok på egen hånd. I stedet er der Instant Grep, et lokalt søgeindeks bygget af n-grammer, inverterede lister og Bloom-filtre, holdt i en hukommelseskortlagt opslagstabel, så forespørgsler løses på udviklerens egen maskine i stedet for på en server.

Selve indekset lever inde i repositoriets eget .git/cursor/-katalog, forankret til et bestemt git-commit; ændringer siden det commit lægger sig oven på det i stedet for at udløse en ny scanning, og indekset genopbygges kun, når den lokale tilstand har afveget langt fra det, det blev bygget mod. Fordi det ligger inde i .git, spores det aldrig og pushes aldrig — slet mappen, og indekset er væk. .gitignore respekteres af konstruktion, da kun git-sporet indhold er kvalificeret, og .cursorignore håndhæves på læsevejen. Der er ikke længere noget embedding-trin på serversiden eller en fjern vektordatabase på den vej. Tidligere dokumentation beskrev et cloud-assisteret design — kryptering af chunks, synkronisering via et Merkle-træ, genbrug af indeks mellem teammedlemmer — og Cursors eget team har siden sagt, at det design trappes ned, så denne tekst beskriver det ikke længere som aktuelt.

Et fremtrædende træk inde i editoren er Cursors Explore-subagent. Den kan starte flere parallelle søgninger i sit eget kontekstvindue på en hurtigere model og kun returnere de relevante fund, så hovedsamtalen ikke svulmer op af søgeresultater. Det er en ægte styrke inde i editoren. Behold den.

Multi-rod-arbejdsområder understøttes: konteksten for hver åbnet mappe er tilgængelig for Agent. Nogle git-afhængige funktioner, som worktrees, er deaktiveret i multi-rod-opsætninger, og Cloud Agents understøtter slet ikke multi-rod-arbejdsområder.

Ingen af disse ting er en grund til at forlade Cursor. Det er en præcis beskrivelse af et kort, der er fremragende dér, hvor det lever.

Hvad ‘rejse med dig’ egentlig betyder

Et kort rejser med dig, når de samme spørgsmål returnerer samme type svar, med citater du kan åbne, fra mere end én klient.

I Cursor: ‘Hvor er parseConfig defineret, og hvem kalder det?’
I Claude Code, på samme repo: samme spørgsmål.
I Codex CLI, på en gennemgangsmaskine, der aldrig har åbnet Cursor-vinduet: samme spørgsmål.
I en CI-agent, der taler MCP: samme spørgsmål, mod det samme hostede øjebliksbillede.

Hvis hver flade bygger sit eget private indeks, har du ikke ét kort. Du har flere caches, der driver fra hinanden. Editorindekset kan være opdateret for træet på disk. CLI-sessionen kan være en dag bagud. CI-jobbet kan se på et andet checkout. Og agenten vil stadig lyde selvsikker.

Cursors indekser er ikke ment til at løse det. Fordi det lever inde i editoren, er den kontekst, det bygger, til den editor. En læser, der også har brug for en CLI, en CI-pipeline, eller en anden editor, har brug for et separat værktøj til de flader. Det er en kendsgerning om omfang, ikke en mangel. Maguyva er det separate værktøj.

Et offentliggjort antal sprog for Cursors indekser er ikke angivet i det materiale, denne tekst må bruge. Maguyva offentliggør understøttelse af over 279 sprog og tekstbaserede teknologier. Cursors priser gengives heller ikke her; se deres prisside. Maguyva opkræver pr. arbejdsområde, ikke pr. plads, med offentliggjorte planer på $0, $19, $49 og $149 afhængigt af indekseret omfang og arbejdsområdets størrelse.

Ét hostet kort, hver MCP-klient

Maguyva er en fjern MCP-server. Du forbinder GitHub, vælger repositorierne, og cloud-pipelinen bygger symboler, grafkanter og et rangeret kort. Du tilføjer en API-nøgle til MCP-konfigurationen for den klient, du allerede bruger. Maguyva har opsætningsguider til 24 dokumenterede MCP-klienter — inklusive Cursor — og kan forbinde til andre MCP-kompatible klienter, der understøtter standardkonfiguration.

Cursor-opsætningssiden er den editorspecifikke vej, hvis det er der, du arbejder. Den samme server svarer Claude Code, VS Code, Windsurf, Codex CLI og resten. Du skifter ikke editor. Du giver hver agent den samme værktøjsflade: 11 kundevendte MCP-værktøjer på tværs af søgning, symboler, afhængighedsanalyse, filhentning, repo-kontekst og deterministiske hjælpeværktøjs-workflows. Semantisk, strukturel, graf- og tekstsøgning smeltes sammen til rangerede resultater.

Det er portabilitetsfordelen. De citater, du tjekkede i Cursor i morges, har samme form som de citater, Codex CLI returnerer i aften. Filsti og linjenummer. Åbn dem. Hvis de er forkerte, kan du se det. Hvis de er rigtige, har den næste ændring et sted at lande. Det godkendte udsagn er færre hallucinerede ændringer, ikke et løfte om, at hver ændring er korrekt.

Friskhed er offentliggjort. Øjebliksbilleder er tidsstemplede, så agenten ved, hvilken version af træet den læser. Genopbygningstakten er daglig på den gratis plan og hver time på betalte planer. Den ærlige begrænsning er usynkroniseret lokalt arbejde: en ændring, der kun findes i et arbejdstræ, er endnu ikke i det hostede kort. Denne begrænsning er den samme, uanset hvilken klient du spørger fra, og det er netop pointen. Drift mellem klienter er ikke længere en anden, skjult begrænsning.

Dokumentationen giver den aktiveringsløkke, der gælder for hver klient: indekser et repo, du allerede kender, forbind klienten, stil ét spørgsmål, du kan verificere. Gør det én gang i Cursor. Gør det igen fra den CLI, du faktisk bruger på gennemgangsdage. Hvis begge svar citerer den samme handler, har kortet virkelig rejst med dig.

Hvordan de to kort eksisterer side om side

Brug begge. De er ikke alternativer i en sammenligningssides forstand.

Lad Cursors indekser være tændt for projektet på disk. Lad Explore, Instant Grep og agenten inde i editoren bruge det. Den løkke er nativ og hurtig.
Tilføj Maguyva som en MCP-server i Cursor, så den samme session også kan spørge det hostede arbejdsområdekort. Cursor er en dokumenteret Maguyva-klient. Du vælger ikke ét indeks og sletter det andet.
Tilføj den samme Maguyva-server til Claude Code, Codex CLI, eller enhver anden MCP-klient, der rører repoet. Én API-nøgleform. Ét arbejdsområde.
Hvis en CI-agent er MCP-kompatibel, så peg den mod den samme server. Den vil læse det samme tidsstemplede øjebliksbillede, som bærbaren læste.

Editorindekset forbliver det bedste værktøj til ‘hvad er der på disk i dette vindue, lige nu’. Det hostede kort er det bedste værktøj til ‘hvordan ser dette arbejdsområde ud for hver agent, der rører det i dag’. De sætninger konkurrerer ikke.

Arbejdsområdekvoter offentliggøres på prissiden: repos, indekserede linjer og brugere, faktureret pr. arbejdsområde. Agenter og mennesker deler det samme brugerantal. Start gratis med et repo, du allerede kan vurdere. Øg arbejdsområdet først, efter citaterne har overlevet kontakt med træet.

Hvad denne side ikke hævder

Den hævder ikke, at Cursors indekser er svag, ufuldstændig, eller en grund til at skifte editor. Den første sætning i denne tekst siger det modsatte.

Den hævder ikke, at Maguyva erstatter Instant Grep eller Explore-subagenten. Det er Cursor-funktioner. De bliver i Cursor.

Den opfinder ikke et antal sprog, et latenstal, eller en token-besparelse for nogen af produkterne. Ukendte tal forbliver upublicerede.

Den lader ikke som om upushet lokalt arbejde er i det hostede kort. Tidsstemplede øjebliksbilleder gør den begrænsning synlig. De fjerner den ikke.

Testen er almindelig. Indekser et repo, du allerede kender. Stil ét spørgsmål, du kan verificere, først i Cursor, derefter i en anden MCP-klient. Kontekst, der rejser med dig, er det samme citat begge steder.

// same map, wherever you opened it.

Kort først, gennemgang bagefter

Mon, 07 Sep 2026 00:00:00 GMT

To forskellige opgaver sidder på hver sin side af en pull request. Før agenten skriver, har den brug for et kort over det træ, den er ved at ændre. Efter agenten har åbnet en PR, bør noget læse den ændring op mod resten af systemet og efterlade kommentarer, som et menneske kan handle på.

Disse opgaver ligner hinanden på afstand, fordi begge involverer ‘at forstå kodebasen’. De er ikke det samme produkt. Den ene svarer på ‘hvor bør denne ændring lande?’. Den anden svarer på ‘hvad ødelagde dette diff, som en linje-for-linje-linter vil overse?’. At blande dem sammen giver et dårligere første udkast og en mere støjende gennemgang.

Denne tekst er en guide til en fælles workflow. Maguyva er kortet, agenten spørger først. Greptile er gennemgangsagenten, der kommenterer PR’en bagefter. Parret er komplementært af konstruktion: Maguyva gennemgår ikke pull requests, og Greptile erstatter ikke det kontekstlag, agenten brugte til at skrive dem.

Hvorfor denne opdeling er nyttig

En kodende agent, der starter fra træningspriorer plus nogle få indsatte filer, vil opfinde en plausibel sti og redigere den. Det er ‘forkert fil’-fejlen, og det er et hentningsproblem. Maguyva er et fjernt MCP-lag for kodebasekontekst: semantisk, strukturel (AST), graf-/afhængigheds- og tekstbaseret hentning smeltes sammen til rangerede resultater, plus symbolsøgning og filhentning. Underbyggede svar kommer tilbage som path/file.ext:line, så du kan afvise en fejl, før en patch findes. Påstanden forbliver beskeden: færre hallucinerede ændringer. Modellen kan stadig gætte. Det er bare det første skridt, der holder op med at være et gæt.

Greptile er en AI-kodegennemgangsagent. Med deres egne ord gennemgår den automatisk hver pull request med fuld forståelse af kodebasen, og stiller det op mod traditionelle lintere, der tjekker filer isoleret i stedet for hele systemet. Opsætningen består i at installere GitHub- eller GitLab-appen og vælge repositorier. Der er intet lokalt indeks, du skal drive. Hosting er Greptile Cloud (de angiver SOC 2 Type II-overholdelse, med en rapport tilgængelig på anmodning), med en selvhostet mulighed tilbudt til virksomheder.

Deres eget nummererede flow er: forbind og byg en afhængighedsgraf for hver funktion, klasse og afhængighed; ved hver pull request, analyser ændringen ved hjælp af den fulde repo-graf og udgiv fund som PR-kommentarer med foreslåede rettelser på cirka tre minutter; hver kommentar kan overdrage problemet til en kodende agent, teamet allerede bruger. De angiver også, at de læser tidligere menneskelige PR-kommentarer over tid for at lære et teams kodestandarder og reducere støjende forslag. Deres læringssystem har efter deres egne udsagn brug for 2-3 uger til at tilpasse sig.

Det er gennemgang, ikke udkast. Greptiles styrke er kontekst fra en fuld repo-graf på den ændring, der allerede er landet i en PR, efterfulgt af en lukket løkke, der sender fundet til Claude Code, Codex, Conductor, Cursor, eller Devin. Maguyvas styrke er det rangerede kort, agenten spurgte, før den ændring blev skrevet. Brug begge. Bed ikke nogen af dem om at gøre den andens job.

En førstepartsproduktintegration mellem Maguyva og Greptile er ikke angivet. Du har heller ikke brug for den. Maguyva taler med agenten over MCP. Greptile taler med GitHub eller GitLab gennem deres egen app. De mødes ved pull requesten. Intet limscript, ingen cron, der forbinder det ene værktøj til det andet. Parret klarer sig uden bash, fordi hvert produkt allerede sidder på den flade, det ejer.

Hvad det her ikke er

Dette er ikke en nedrivning af Greptile. Det er ikke en ‘skift anmelder’-side. Greptile lancerede på Hacker News den 5. marts 2024 som et Y Combinator W24-firma, og den tråd er, hvordan mange mennesker først mødte produktet. Hvis det er sådan, du fandt dem, så bliv ved med at bruge dem. Denne side er den manglende forreste halvdel af den løkke: at forankre agenten på forhånd, så den PR, Greptile ser, allerede sigter på de rigtige filer.

Greptiles markedsføringsmateriale fører med påstande om gennemgangshastighed og fejlfangst. Behandl dem som Greptiles egne påstande, ikke uafhængigt verificerede tal. Denne tekst gentager dem ikke som fakta.

Sprogdækning er samme slags ærlighed. Greptile rammer support ind som dækning af alle programmeringssprog i stedet for en opremset liste; et præcist tal er ikke angivet. Maguyva offentliggør understøttelse af over 279 sprog og tekstbaserede teknologier, med en teknisk opdeling (parser-understøttet AST versus kun tekst) på sitet, når spørgsmålet er teknisk. Det er forskellige produkter, der kommer med forskellige påstande. Bland dem ikke.

Greptiles priser er ikke angivet i det materiale, denne tekst må bruge. Betalte planer findes; se deres prisside. Maguyva opkræver pr. arbejdsområde, ikke pr. plads. Planer starter gratis. Prissiden viser de offentliggjorte niveauer, hvis du har brug for arbejdsområdetallene.

Workflow

Tre navngivne trin. Udfør dem i denne rækkefølge. Spring ikke nogen af dem over, første gang du prøver parret.

1. Maguyva-kontekst

Indekser ét repository, du allerede kender. Forbind MCP-klienten, du allerede skriver i — Claude Code, Cursor, Codex CLI, VS Code, Windsurf, eller en anden MCP-kompatibel klient. Maguyva har opsætningsguider til 24 dokumenterede MCP-klienter og kan forbinde til andre klienter, der understøtter standard MCP-konfiguration.

Stil et spørgsmål, du kan vurdere, før nogen skriver en linje. ‘Hvor håndteres sessionsudløb, og hvad kalder det?’ er et bedre første træk end ‘fiks auth’. Kræv citater. Åbn file.ext:line-resultaterne. Følg symbolet. Bekræft den afhængighed, du er ved at røre.

Maguyva eksponerer 11 kundevendte MCP-værktøjer på tværs af søgning, symboler, afhængighedsanalyse, filhentning, repo-kontekst og deterministiske hjælpeværktøjs-workflows. Fire hentningstilstande smeltes sammen til rangerede resultater; find_symbol er et separat værktøj, når du allerede kender navnet. Dokumentationen beskriver den korteste vej: start gratis, indekser et repo, du allerede kender, forbind klienten, stil derefter ét spørgsmål, du kan verificere.

Øjebliksbilleder er tidsstemplede, så agenten kan sige, hvilken version af træet den læser. Den ærlige begrænsning er usynkroniseret lokalt arbejde. Hvis ændringen kun findes i et arbejdstræ og ikke er pushet, indeholder det hostede kort den endnu ikke. Instruktionsfiler (CLAUDE.md, AGENTS.md) hører stadig hjemme her, til konventioner og det, der ikke skal røres. De er ikke et levende kort. Brug dem til adfærd. Brug Maguyva til fakta.

Lad ikke agenten åbne en PR, før citaterne overlever kontakt med repoet. Den port er hele pointen med dette trin.

2. Agentens PR

Den samme agent skriver nu ændringen i den klient, du allerede betaler for. Maguyva er hverken en editor eller en anmelder. Agenten producerer stadig diffet. Du åbner stadig pull requesten på GitHub eller GitLab, som du allerede gør.

Det, der bør være anderledes, er den første fil. PR’en bør nævne den handler, der rent faktisk implementerer adfærden, den kalder, der vil gå i stykker, og den test, der vil fejle, hvis ændringen er forkert. Hvis trin 1 blev sprunget over, vil trin 3 bruge sine kommentarer på en ændring, der landede i den forkerte pakke. Greptile kan stadig finde systemiske problemer. Den burde ikke også skulle komme sig oven på en hallucineret sti.

Hold PR’en afgrænset. En underbygget første fil er ikke en licens til at omskrive modulet. Dette komplementære par fungerer, når agenten udførte ét job med et kort, og derefter bad en anmelder udføre et andet job på et afgrænset diff.

3. Greptile-gennemgang

Greptile er allerede forbundet til repositoriet via GitHub- eller GitLab-appen. På den nye pull request analyserer den ændringen ved hjælp af den fulde repo-graf, den byggede, og udgiver fund som kommentarer med foreslåede rettelser. Deres eget materiale sætter denne gennemgang til cirka tre minutter.

Læs kommentarerne, som du ville læse en omhyggelig kollega: åbn det citerede sted, afgør om fundet er ægte, og handl derefter. Hvor Greptile tilbyder ‘Fix with your Agent’, sender den problemet — filstier, linjenumre, foreslået kode — til Claude Code, Codex, Conductor, Cursor, eller Devin. ‘Fix All’ sender alle problemer i gennemgangen på én gang. De leverer også en Greptile MCP og et Claude Code-plugin til den overdragelse. Maguyva er ikke på den navngivne målliste; det fravær er ikke et problem. Maguyva har allerede gjort sit arbejde i trin 1. Den kodende agent, der skrev PR’en, er den, der bør modtage rettelsesnyttelasten.

Forvent støj de første 2-3 uger, mens Greptiles læringssystem tilpasser sig de kommentarer, dit team rent faktisk efterlader. Det er deres angivne tidsplan, ikke en mangel ved parret. Menneskelig gennemgang forbliver i løkken. Greptile er den automatiserede første gennemgang, ikke sammenlægningsknappen.

Hvis en Greptile-kommentar peger på en fil, agenten aldrig spurgte i trin 1, er det et nyttigt signal. Enten gik kortet glip af en kalder, eller også sprang agenten et citat over. Ret udkastet i overensstemmelse med kommentaren. Deaktiver ikke anmelderen.

Sådan holder du dette komplement ærligt

Maguyva altid først. En gennemgang af en PR med forkert fil er stadig en gennemgang af den forkerte fil.
Greptile altid bagefter. Et velciteret udkast har stadig brug for en gennemlæsning af diffet på hele systemets niveau.
Bed ikke Maguyva om at udgive PR-kommentarer. Det gør den ikke.
Bed ikke Greptile om at være agentens første hentningslag, mens den stadig vælger en sti. Det er ikke det job, deres GitHub- eller GitLab-app er koblet til.
Opfind ikke en bash-pipeline, der ‘synkroniserer’ dem. PR’en er grænsefladen.
Verificer begge sider uafhængigt. Indekser et repo, du allerede kender. Stil ét spørgsmål, du kan verificere. Åbn derefter en lille PR og læs, hvad Greptile rent faktisk kommenterer.

Løkken er almindelig, så snart den får et navn. Kort først. Agentens PR. Gennemgang bagefter. Hvert produkt bliver på den side af pull requesten, det er godt til.

// map first. review second. in that order.

Giv en AI-agent kontekst om et stort repo uden en lokal indekser

Fri, 14 Aug 2026 00:00:00 GMT

Et stort repository passer ikke i et kontekstvindue, og hvis du nogensinde har rettet en bærbar-indekser mod et rigtigt monorepo, ved du, at det heller ikke passer komfortabelt der — RAM’en skyder i vejret, den første indeksering tager en time, og din agent starter alligevel den næste session med at gætte, hvilke filer der betyder noget.

Det sædvanlige svar er at køre en indekser ved siden af editoren, og for et repo, der passer komfortabelt på én maskine, er det et godt svar. Hvis dit monorepo allerede indekseres hurtigt i Cursor, og det er det eneste sted, du har brug for kortet, har denne tekst intet at tilføje — spring den over.

Denne tekst handler om det andet tilfælde — når en agent har brug for et søgbart kort over et stort repository, og du ikke vil køre en lokal indekser for at få det.

Hvornår en lokal indekser er det forkerte værktøj

Et lokalt indeks antager, at koden lever på den maskine, der spørger det, og i reel monorepo-skala strammes den antagelse selv inden for en enkelt editor. Repoet er simpelthen større, end du vil holde ‘varmt’ på en bærbar: du arbejder i én pakke, mens blast radius ligger tre kataloger væk, og en første kold indeksering af et træ på to millioner linjer er ikke noget, du vil gennemgå to gange — hverken på din egen maskine eller på en CI-runner, der aldrig har klonet det træ før. Eller en kollega burde kunne spørge det samme kort som dig, uden at vente på, at deres egen maskine kæmper sig gennem det samme indeks.

Ingen af disse ting er en grund til at smide en god editor-indekser væk. Det er en grund til også at have et hostet kort, som enhver af dine agenter kan spørge via MCP.

Og skalaproblemet går dybere end ‘for mange filer at indsætte’. På et stort træ er det interessante spørgsmål næsten aldrig ‘vis mig denne fil’ — det er hvilken fil, hvilket symbol, hvilke kaldere, hvilke tests. En agent, der starter med at liste src/ og læse de tre første resultater, vil muntert overse handleren i apps/api og den genererede klient i packages/sdk. Det, du har brug for, er hentning bygget fra hele træet, derefter rangeret, derefter citeret.

Hvad ‘kontekst om et stort repo’ egentlig betyder

At dumpe filer ind i prompten er ikke kontekst — det er en mindre, ringere kopi af træet. Det, din agent virkelig har brug for, er at stille spørgsmål og få citerede svar tilbage: hvor dette symbol er defineret, og hvem der kalder det, hvad der afhænger af det modul, jeg er ved at ændre, hvilken testfil der dækker denne adfærd, og hvordan træet ser ud nu, ikke sidste kvartal.

Disse svar skal komme fra et indeks bygget ud fra dit repo, ikke fra modellens hukommelse om andres repos, og indekset skal leve et andet sted end agentens kontekstvindue. For dette problem bør det også leve et andet sted end din bærbare.

Endnu en ting instruktionsfiler ikke kan gøre for dig: CLAUDE.md og AGENTS.md er det rigtige sted for konventioner og adfærd, men de er ikke et levende, rangeret, søgbart kort over et træ på to millioner linjer. Brug regler til adfærd; brug repo-intelligens til fakta.

Vi bygger kortet i skyen, spørger det fra enhver klient

Maguyva er et fjernt MCP-lag for kodebasekontekst. Du forbinder GitHub, vælger dine repositorier, og kan gå din vej, mens cloud-pipelines analyserer træet, bygger symboler og grafkanter, og vedligeholder et rangeret kort — aldrig en lokal indekser.

Når du pusher kode, analyseres ændrede filer inkrementelt, og graf- og rangeringslagene genopbygges efter en tidsplan: dagligt på den gratis plan, hver time på betalte planer. Hvert øjebliksbillede er tidsstemplet, så din agent kan sige, hvilken version af træet den læser. Den ærlige begrænsning her er usynkroniseret lokalt arbejde — en ændring, der kun findes i dit arbejdstræ, aldrig pushet, er endnu ikke i det hostede kort.

Derefter forbinder du enhver klient, du allerede bruger, ved at tilføje en API-nøgle til dens MCP-konfiguration. Der findes opsætningsguider til 24 dokumenterede MCP-klienter, og enhver anden MCP-kompatibel klient, der understøtter standardkonfiguration, kan også forbinde. Hvis Cursor er der, du bor, går Cursor-siden den vej; den samme server svarer Claude Code, VS Code, Windsurf, Codex CLI og resten.

Du skifter ikke editor. Du giver din agent en værktøjsflade — 11 MCP-værktøjer på tværs af søgning, symboler, afhængighedsanalyse, filhentning og repo-kontekst — med dækning af over 279 sprog og tekstbaserede teknologier, hvilket betyder mere, end du tror, på et monorepo, der holdt op med at være ét sprog for mange år siden.

Svar kommer tilbage underbygget, som filstier med linjenumre. Semantisk, strukturel, graf- og tekstsøgning smeltes sammen til rangerede resultater, så et spørgsmål som ‘hvad afhænger af parseConfig’ hverken giver dig et grep-dump eller et enkelt semantisk uddrag, men den håndfuld steder, der virkelig betyder noget.

En konkret fremgangsmåde

Start ikke med at indeksere hele virksomheden. Her er vejen, der virker:

Vælg ét repository, du allerede kender godt — en pakke, du kan vurdere i hånden, er mere værd end det største træ, du har.
Start gratis: 3 repos, 50k indekserede linjer, alle 11 værktøjer, ingen månedlig forespørgselskvote. Hvis dit repræsentative repo er større, viser prissiden arbejdsområdeniveauerne ($0, $19, $49, $149) efter indekseret omfang — ikke efter antal pladser.
Forbind GitHub og vent på, at den første indeksering er færdig. Du kompilerer intet lokalt.
Forbind MCP-klienten — nogle få linjer konfiguration. Maguyva er en fjern MCP-server, så der er ingen plugins, ingen udvidelser, og ingen anden editor at tage til sig.
Stil ét spørgsmål, du kan verificere. ‘Hvad afhænger af parseConfig?’ eller ‘Hvor håndteres udløb af login-sessionen?’ Åbn derefter de citerede file.ext:line-resultater og tjek dem mod træet foran dig.
Først efter citaterne overlever den kontakt, lader du agenten redigere.

Hvis det første repo passer godt, og dit træ er stort, så hæv arbejdsområdet til at matche dine indekserede linjer og genopbygningstakt. Mennesker og agenter deler det samme brugerantal — Maguyva opkræver pr. arbejdsområde, ikke pr. plads — så at tilføje en tredje agent til løkken koster dig ingenting.

Aktiveringstesten er den samme, som dokumentationen anbefaler til enhver første kørsel: indekser et repo, du allerede kender, stil ét spørgsmål, du kan verificere. Et stort repo ændrer ikke testen; det gør bare en forkert første fil dyrere.

Hvad du skal holde øje med efter tilslutning

Hold øje med tre ting. Friskhed: betalte planer genopbygges hver time, gratis planer dagligt, og upushet lokalt arbejde vil ikke være i kortet — det er den afvejning, du accepterer. Omfang: indekser et repræsentativt sæt af repos, ikke hver arkiveret fork; det gratis niveau er bevidst dimensioneret til at finde ud af, om svarene er værd at beholde. Og verificering: et kort over et stort repo, der ikke kan citere stier og linjenumre, er bare en langsommere gættemaskine, så lad din agent vise stedet, før den leverer patchen.

Kør derefter den samme test, du ville køre på et lille repo. Indekser et repo, du allerede kender. Stil ét spørgsmål, du kan verificere. Hvis kortet er ægte, holder din agent op med at starte fra et koldt træ.

// no laptop got hot building this map.

Hvorfor din AI-kodende agent hallucinerer filstier

Fri, 14 Aug 2026 00:00:00 GMT

Kendetegnet er ikke en forkert funktionskrop. Det er en selvsikker ændring i en fil, der ikke findes, eller i en fil, der findes, men ikke er den, der implementerer adfærden.

Du bad om en fix til sessionsudløb. Agenten åbnede src/auth/session.ts. Den sti er plausibel. Den er også forkert. Den ægte handler lever i apps/api/src/middleware/expiry.ts, omdøbt to refaktoreringer siden. Agenten løj ikke for dig. Den fuldførte en stiformet streng ud fra træningspriorer plus alt det, der allerede var i kontekstvinduet.

Dette er det almindelige fejlmønster på et ægte repository. Modellen kan skrive kode. Fejlen ligger i at vælge det forkerte sted at skrive den.

Hvorfor agenter opfinder stier

En kodende agent er en model til forudsigelse af det næste token med værktøjer. Når du siger ‘fiks sessionsudløb’, skal den navngive en fil, før den kan læse eller patche noget. Hvis den ikke allerede har et forankret kort, konstruerer den en sti ud fra:

Navngivningskonventioner, den har set i andre repositorier. src/auth/session.ts er en hyppig form.
Filer allerede i samtalen, som måske er dem, du indsatte sidste uge, ikke dem, der betyder noget nu.
Mappelister, den tilfældigt kørte, ufuldstændige på et stort træ.
Instruktionsfiler. CLAUDE.md og AGENTS.md fortæller agenten, hvordan den skal opføre sig. De er ikke et levende indeks over symboler, kaldere, eller aktuelle stier.

Ingen af disse kilder er et kort over dette repository, i dag. Modellen udfylder hullet på samme måde, som den udfylder ethvert hul: med en fortsættelse med høj sandsynlighed. Den fortsættelse ligner ofte en ægte sti. Nogle gange findes filen og ligger ved siden af den rigtige. Nogle gange fandtes den på en gren, der blev merget sidste måned. Nogle gange fandtes den aldrig.

Grep redder dig ikke her, hvis agenten slet ikke søger efter den rigtige streng. Agenten gættede en sti, læste derefter hvad den sti returnerede, og redigerede den så. Det første forkerte skridt var stien, ikke patchen.

At læse filer er heller ikke det samme som at finde de rigtige. Claude Code, Cursor, Codex, og lignende værktøjer kan åbne, hvad end du peger dem mod. Spørgsmålet er, om de pålideligt finder de rigtige filer, de vigtige symboler, afhængighederne, testene, og blast radius, før de redigerer. Filadgang uden et kort begynder stadig med et gæt.

Redigering af den forkerte fil er et hentningsproblem

Behandl den opdigtede sti som en hentningsfejl, ikke som en personlighedsbrist.

Hvis agenten skulle returnere path/file.ext:line, før den fik lov til at redigere, ville to ting ske. For det første kunne du åbne citatet og afvise arbejdet på ti sekunder. For det andet ville agenten skulle spørge noget, der rent faktisk kender træet.

Det er jobbet for et kodebasekontekstlag. Semantisk søgning alene er ikke nok. Et uddrag, der ‘lyder som sessionsudløb’, kan stadig lande i en udfaset pakke. Du har også brug for præcis tekst, når du kender strengen, symbolsøgning, når du kender navnet, strukturel søgning, når du kender formen, og en afhængighedsgraf, når du har brug for kaldere og blast radius.

Maguyva er det lag til MCP-kompatible kodende agenter. Det er ikke en editor. Claude Code, Cursor, Codex CLI, VS Code, Windsurf, og andre MCP-klienter bliver, hvor de er. Agenten spørger et rangeret kort, før den rører en linje.

Påstanden er bevidst beskeden: færre hallucinerede ændringer. Maguyva fjerner ikke modellens evne til at gætte. Det ændrer det første standardskridt fra ‘opfind en plausibel sti’ til ‘bed om rangerede, citerede steder’.

Sådan ser et underbygget svar ud

Et nyttigt svar på ‘hvor håndteres sessionsudløb’ er ikke et afsnit. Det er en kort liste over steder:

apps/api/src/middleware/expiry.ts:48 - handleren
apps/web/src/lib/auth-client.ts:112 - kalderen
apps/api/tests/expiry.test.ts:20 - testen, der fejler, hvis ændringen er forkert

Du kan åbne disse linjer. Hvis de er forkerte, stopper du. Hvis de er rigtige, kan agenten redigere. Verifikationen er pointen, ikke et slogan.

Maguyva eksponerer 11 kundevendte MCP-værktøjer på tværs af søgning, symboler, afhængighedsanalyse, filhentning, repo-kontekst og deterministiske hjælpeværktøjs-workflows. Fire hentningstilstande (semantisk, strukturel, graf/afhængighed, og tekst) smeltes sammen til rangerede resultater; symbolsøgning er et separat MCP-værktøj (find_symbol). Underbyggede svar kommer tilbage med filstier og linjenumre, så du kan vurdere dem mod træet foran dig.

Dokumentationen beskriver den korteste vej: start gratis, indekser et repo, du allerede kender, forbind klienten, stil derefter ét spørgsmål, du kan verificere.

En løkke, der ændrer den første ændring

Du har ikke brug for en ny workflow-religion. Du har brug for ét ekstra skridt før den første skrivning.

Stil et spørgsmål, du allerede kan vurdere. ‘Hvilken kode håndterer login og sessionsudløb?’ er bedre end ‘fiks auth’.
Kræv citater. Filsti og linjenummer, ikke et resumé af ‘auth-modulet’.
Åbn de citerede filer. Følg symbolet. Bekræft den afhængighed, du er ved at røre.
Først da lader du agenten patche.

Hvis trin 2 ikke returnerer noget nyttigt, har agenten ikke ret til at improvisere en sti. Den søger igen, eller du peger den. Netop denne ene port er, hvad der giver færre hallucinerede ændringer. Modellen er den samme model. Kortet er det, der har ændret sig.

Instruktionsfiler betyder stadig noget. Behold dem. Brug dem til konventioner, gennemgangsregler, og det, der ikke skal røres. Bed dem ikke om at være indekset. En CLAUDE.md, der lister tre vigtige kataloger, vil være forældet ugen efter en pakke-opdeling. Et søgbart kort opdateres, når repoet opdateres.

En beslægtet fejl er den næsten-rigtige fil: agenten åbner auth.ts, når adfærden lever i auth-client.ts, eller patcher en genereret fil i stedet for kilden, eller redigerer kopien i packages/legacy, fordi navnet matchede. Citater gør ikke disse fejl umulige. De gør dem synlige, før diffet lander.

Hvad et kort ikke løser for dig

Vær nøgtern om, hvad du får. Et underbygget kort gør ikke enhver ændring korrekt — din agent kan stadig skrive en dårlig patch i præcis den rigtige fil. Hvis din kodebase læner sig op ad dynamisk dispatch, refleksion, eller monkey-patching, vil nogle symbolsøgninger komme tilbage tyndere, end du ville ønske, fordi det er, hvad kørselstidsindirektion gør ved ethvert statisk indeks. Og hvis du håber på en procentdel — ‘hallucinerede stier reduceret med X%’ — finder du den ikke her, fordi ingen ærligt kan måle det tal for dit repo undtagen dig selv.

Det, du kan forvente, er smallere og mere nyttigt: agenten holder op med at åbne sine ændringer med en gættet sti. Det første skridt bliver forankret i et ægte kort, og det er derfra, færre hallucinerede ændringer kommer. Alt efter citatet — at læse diffet, vurdere patchen — er stadig dit job, ligesom det altid har været.

Testen koster dig næsten intet: indekser et repo, du allerede kender, og stil ét spørgsmål, du kan verificere. Start med en sti, du allerede er blevet brændt af. Hvis citaterne er forkerte, ser du det med det samme. Hvis de er rigtige, har din agents næste ændring et bedre sted at lande.

// it doesn't know the file. it knows how to find it.

Hvorfor vi opgraderede kodesøgning til voyage-4-large

Tue, 09 Jun 2026 00:00:00 GMT

Benchmark-tallene i dette indlæg afspejler RTEB-ranglisterne på udgivelsestidspunktet (juni 2026). Ranglister flytter sig; betragt placeringerne som et øjebliksbillede, ikke en permanent kendsgerning.

Semantisk søgning er kun så god som de embeddings, der ligger under den.

Når en agent spørger Maguyva “hvor håndterer vi retries,” grepper den ikke efter ordet “retry.” Den spørger efter meningen — backoff-løkken, circuit breakeren, den ting, der pakker et upålideligt kald ind. Det spørgsmål besvares af en vektormodel, der gør kode til et punkt i rummet og finder naboerne. Vælg en bedre model, og enhver semantisk forespørgsel i produktet bliver stille og roligt skarpere.

Så vi ændrede vores. Fra og med juni 2026 kører Maguyvas kode-embeddings på voyage-4-large, som erstatter voyage-code-3.

Benchmarken

Vi traf ikke denne beslutning på mavefornemmelse. Den offentlige Retrieval Embedding Benchmark (RTEB) rangerer embedding-modeller på reelle retrieval-opgaver, og på dens Code-rangliste ligger voyage-4-large på 1.-pladsen samlet (90.86) — foran gemini-embedding-2-preview (90.26) og, bemærkelsesværdigt, foran den model, vi allerede brugte, voyage-code-3 (89.73, #3).

Det er en lille forskel i den absolutte score. Men det er en forskel i den rigtige retning, på en offentlig benchmark, på præcis den opgave, vi er optaget af: at hente kode ud fra mening.

Det kompromis, vi accepterer: binær kvantisering

Her er den del, de fleste “vi opgraderede vores model”-indlæg udelader.

Maguyva gemmer ikke fuldpræcisions-vektorer. Vi gemmer binært kvantiserede embeddings: hver 2048-dimensionel vektor kollapser til en 2048-bit signatur — 256 bytes pr. vektor. De signaturer søges med Hamming-afstand, indekseres og partitioneres pr. tenant.

Det er et bevidst kompromis. Binær kvantisering opgiver noget retrieval-præcision til gengæld for dramatisk mindre lagerplads og hurtige afstandsberegninger med lave omkostninger uden en separat vektordatabase at drive. For et produkt, der indekserer hele repositorier pr. workspace, betyder den økonomi mere end at presse den sidste brøkdel ud af et benchmarkpoint.

voyage-4-large passer ind i dette design uden at tvinge en migrering af lagerlaget: det producerer 2048-dimensionelt output, samme som voyage-code-3, så vores bit(2048)-kolonner og Hamming-søgesti ændrede sig ikke. Modellen blev bedre; skemaet stod stille.

Kode var kun begyndelsen

Maguyva er et kodeintelligensværktøj. Men vi er også vores egen første kunde, og vi peger det på noget andet: den markdown, der lever i vores repositorier ved siden af koden. Arkitekturbeslutningsregistreringer, driftsvejledninger, kontrakter, finans- og politikdokumenter — det hele versionsstyret i Git, det hele bag den samme MCP-server, et semantisk indeks over dokumenterne, ikke kun kildekoden.

Det er præcis derfor, voyage-4-larges bredde betyder noget. På den samme RTEB-familie af ranglister er den #1 på finans, #1 på sundhed og #1 på samlet tekst-retrieval — foran Googles Gemini Embedding, Coheres Embed v4 og OpenAIs text-embedding-3-large. (Voyage er medskaber af RTEB, så vi læser det som et stærkt offentligt signal snarere end en fuldstændig neutral dommer — men den er benchmarket direkte mod hver eneste større kommercielle model, på private hold-out-sæt.) Det samme indeks, der finder den rigtige funktion til en agent, finder den rigtige klausul i en kontrakt eller den rigtige linje i en politik — og på de områder er voyage-4-large ikke et kompromis, det er lederen.

Hvorfor vi betaler for premium-embeddings

Der findes en billigere måde at søge på, og meget af det er gratis. Leksikalsk søgning — BM25 og dens slægtninge — matcher nøgleord, kører lokalt og koster ingenting. Open source-embedding-modeller som BGE, Nomic og embeddinggemma giver reelt anstændig semantisk retrieval, og man kan selv hoste dem for prisen af en GPU. Maguyva bruger også den gratis side: hver forespørgsel fusionerer tekst-, AST-, graf- og semantisk søgning. Det, vi ikke sparer på, er det semantiske lag.

Vi betaler pr. token for premium-embeddings — voyage-4-large — i stedet for selv at hoste en gratis model, af to grunde. For det første kan nøgleordssøgning alene ikke besvare “hvor håndterer vi retries,” når koden siger backoff og circuit breaker og aldrig siger ordet “retry” — mening er hele pointen med embeddingen, og på de områder, vi betjener, halter de åbne modeller efter premium-modellerne: et par point bagud på generel tekst, og længere bagud i nicher som kode, kontrakter og finans. For det andet former retrieval-kvalitet efter vores erfaring det endelige svar mere end modellen i den anden ende gør — en stærk agent, der får den forkerte kontekst, svarer stadig forkert, og den ser aldrig det dokument, den aldrig fik.

Så premium-embeddings er en pr.-token-regning, der skalerer med hvert repository og dokument, vi indekserer — og vi betaler den med vilje. For det resultat, vores brugere får, den rigtige funktion eller den rigtige klausul, mener vi, at det kompromis er det værd.

Den ærlige del

Voyages egen dokumentation kalder stadig voyage-code-3 for den kode-optimerede model. Så hvorfor skifte?

Fordi vi læser den offentlige benchmark, ikke bare leverandørens modeltabel, og benchmarken satte voyage-4-large i toppen for kode-retrieval. Dette var en fremadskuende beslutning: tag den nyere, generelt stærkere model og validér den mod en offentlig rangliste på de opgaver, der betyder noget. Vi er trygge ved at tage det væddemål, fordi beviserne er brede — voyage-4-large vinder ikke bare på kode, den fører også på finans, sundhed og samlet retrieval.

Det stille fundament

Hvert værktøj, vi eksponerer — semantisk søgning, task-context-indsamling, forankret spørgsmål-svar — bunder i retrieval. Når retrieveren forbedres, får agenten i den anden ende bedre evidens, tager færre forkerte drejninger og forankrer sine svar i den rigtige kode — eller den rigtige klausul, eller den rigtige politik. En skarpere embedding-model er ikke en prangende funktion. Det er fundamentet under alt det andet, og vi har lige styrket det. Du vil ikke bemærke det. Det er hele pointen.

Rekursiv selvforbedring af sprogunderstøttelse: Sådan forbedrer vi kodeintelligens på tværs af ~280 sprog

Tue, 26 May 2026 00:00:00 GMT

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (maj 2026). Se vores team-side for aktuelle tal.

Maguyva udtrækker symboler, referencer og en afhængighedsgraf fra kildekode på omkring 280 sprog. Hvert sprog er en custom tree-sitter-handler — forespørgsler, heuristikker, grænsetilfælde — og enhver handler kan være subtilt forkert på sin egen måde. Et metodekald udsendt som en læsning. En funktion tilskrevet det forkerte omsluttende scope. En relation, der simpelthen ikke findes.

Det kan man ikke gennemgå manuelt. Intet team kan læse udtræksoutput på tværs af 280 grammatikker og spotte de dårlige kanter. Så det interessante spørgsmål er ikke “er vores udtræk korrekt” — det er “hvordan finder man ud af, at det er forkert, i denne bredde, uden et menneske i hver eneste løkke.” Vores svar er rekursiv selvforbedring af sprogunderstøttelsen: en kvalitetsløkke drevet af sprogagenter, en LLM, der agerer dommer, og én regel, vi bliver ved med at genlære: grønt er ikke det samme som korrekt.

Grønt er ikke korrekt

Hvert sprog har en fixture-suite, og en release-gate scorer det på fem dimensioner — nøjagtighed, strukturel integritet, fuldstændighed, kvalitet og performance. Et sprog bliver kun GRØNT, når præcisionen på dets fixtures er ≥ 0.95, recall ≥ 0.99, og F1 ≥ 0.97, med mindst 20 forventede kanter for statistisk konfidens. Under det er det GULT eller RØDT, og det shippes ikke.

Den gate er nødvendig, men ikke tilstrækkelig. Fixtures validerer mod fixtures, vi har skrevet. De indkoder de tilfælde, vi allerede har tænkt på. En handler kan være fejlfri på sine fixtures og stadig ødelægge et mønster, der kun dukker op i rigtig kode — et makro-idiom, en metode med begrænsninger på generiske typer, en sprogfunktion, ingen skrev en fixture til. GRØNT betyder, at fixtures består. Det betyder ikke, at et rigtigt repository udtrækkes rent. Så løkken må lægge fixtures bag sig og undersøge kode fra rigtige projekter.

Den indre løkke: tag stikprøver, bedøm, ret, bevis

Kerneløkken kører ét sprog ad gangen:

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  1. corpus run ── clone real-world repos, extract relationships   │
        │                                                          │
        ▼                                                          │
  2. spot-check 100 edges (seed 42, then seed 123 to cross-check)  │
        │                                                          │
        ▼                                                          │
  3. LLM judge classifies every sampled edge:                      │
        CORRECT · FALSE_POSITIVE · TYPE_ERROR ·                    │
        SCOPE_ERROR · METADATA_ERROR                               │
        │                                                          │
        ▼                                                          │
  4. fix ONE thing — handler .py, .scm query, or config           │
        │                                                          │
        ▼                                                          │
  5. re-validate — F1 + re-classify + manifest diff (no regressions)│
        │                                                          │
   better? ──no──► revert, try a different fix ────────────────────┤
        │ yes                                                       │
        ▼                                                           │
  6. promote the fix into fixtures (a permanent regression guard) ──┘

Et par ting gør, at dette virker i stedet for at køre i ring.

Dommeren er agenten, ikke et API-kald. Når vi siger “LLM som dommer”, mener vi, at sprogagenten selv læser hver udtaget kant mod den rigtige kilde og klassificerer den med faste vurderingskriterier med fem kategorier: er denne kant korrekt, en falsk positiv, den rigtige relation med den forkerte type, tilknyttet det forkerte scope, eller bærer den forkerte metadata? De vurderingskriterier er afgørende — “23% fejlrate” er meningsløst, indtil man ved, om det er reelle defekter, eller om dommeren tæller forkert.

Ret én ting, og bevis det så. Hver iteration ændrer præcis ét redigerbart asset, kører derefter igen mod et fast testmiljø og beholder kun ændringen, hvis F1 forbedres, og re-klassificeringen ser bedre ud. Hvis ikke, rulles den tilbage. Ingen batch af spekulative rettelser, intet “burde være bedre.” En ændring skal fortjene sin plads, ellers forsvinder den. Og når en rettelse holder, bliver den forfremmet til fixture-suiten — så den fejl, den rettede, aldrig kan snige sig tilbage stiltiende. Det forfremmelsestrin er det, der gør løkken rekursiv frem for bare gentagende: hver omgang hærder det orakel, den næste omgang validerer mod.

Lektien, vi bliver ved med at genlære: metrikker overrapporterer

Her er fælden, og vi gik lige i den. De sekundære korpusmetrikker — hvor ofte et udtrukket mål ikke kan kobles til et symbol, hvor mange symboler der ser “forældreløse” ud, og så videre — overrapporterer massivt problemer. De er for det meste paradigme-artefakter, ikke fejl.

Det reneste eksempel: llvm viste engang en 73% “kilde-uden-symbol”-rate og blev stemplet katastrofal. Vi gravede i det. Den reelle nøjagtighed var 98.5%. De “manglende symboler” var næsten alle legitime eksterne referencer — kald ind i standardbiblioteket, ind i frameworks, ind i kode, der lever uden for repositoriet. Metrikken målte en egenskab ved sproget, ikke en defekt i handleren. Sprog som Zig, COBOL og Odin viser 65–70% “forældreløs”-rater og er fuldstændig korrekte; COBOL havde nul reelle fejl.

Hvis vi havde ladet de tal styre arbejdet, ville vi have brugt uger på at “rette” handlere, der allerede var korrekte, og ignoreret de sprog med stille, reelle fejl. Konklusionen er ligetil: de aggregerede metrikker er højst et groft triage-signal. Det reelle kvalitetssignal er stikprøven med kantklassificering — at se på faktiske kanter i faktiske repositorier og bedømme dem én for én. Data frem for intuition, men kun når man ved, hvilke data der taler sandt.

Den ydre løkke: en flåde, ikke et maraton

Ét sprog ad gangen ville tage evigheder på tværs af 280 af dem, så den indre løkke er pakket ind i en ydre, der kører mange parallelt.

   pick a wave of near-GREEN / high-error languages
        │
        ▼
   fan out 10–15 agents, each ISOLATED in its own git worktree,
   each grinding ONE language, committing to its own branch
        │
        ▼
   orchestrator integrates serially: file-scoped apply, then
   `manifest diff` — any cross-language regression blocks the batch
        │
        ▼
   gated push (reviewed and confirmed) ──► rotate to the next wave

Hver agent arbejder i et midlertidigt worktree, så de ikke kan træde hinanden over tæerne. Orkestratoren integrerer deres rettelser én ad gangen, hver bag et fuldt manifest-regressionstjek: en ændring, der hjælper sit eget sprog, men stiltiende ødelægger tre andre, lander ikke. Integration er gatet og bekræftet, før noget pushes — regressions-gaten afgør, hvad der er sikkert, et menneske afgør stadig, hvad der shippes. Så roterer poolen til det næste sæt sprog, og det hele kører igen.

Hvad der stadig er ufuldkomment

Dommeren kan tage fejl, og fejlbarheden har en retning: en agent, der kører med for lidt kontekst, overrapporterer. I én batch blev otte sprog flagget med 5–20% fejl; ved nærmere eftersyn havde kun ét en reel sprogspecifik fejl — resten var dommerfejl fra at overse sprogets egen semantik (én kildelinje, der legitimt udsender flere kanter, parameterbindinger modelleret som tildelinger, reference-per-identifikator-sprog). Det er derfor, vi udtager stikprøver med to seeds og krydstjekker, og hvorfor en uenighed mellem dommeren og fixtures behandles som det mest interessante signal, ikke en afgjort dom — nogle gange er det fixturet, der tager fejl.

Vi er også ærlige omkring målet. Målet er nul reelle fejl, punktum — men “nul” er en retning, vi arbejder os hen imod, sprog for sprog, ikke en boks, der krydses af. Der er altid endnu et repository med endnu et idiom.

Fortjent, ikke påstået

Alt, hvad Maguyva gør for en agent — at finde et symbol, spore en afhængighed, besvare et spørgsmål med citeret kode — hviler på, at udtrækket nedenunder er korrekt. På tværs af 280 sprog kan “korrekt” ikke påstås; det skal løbende fortjenes mod rigtig kode. Løkken er, hvordan vi fortjener det: en autonom stikprøve-og-ret-cyklus, der behandler sine egne metrikker med mistænksomhed, beviser hver ændring og gør hver rettelse til en vagt mod den næste regression. Det er ikke glamourøst. Det er det arbejde, der lader os sige “vi understøtter dit sprog” og mene det. Grønt er nemt. Korrekt er fortjent.

Multimodal fusionssøgning: Sådan vælges den rette retriever til hver forespørgsel

Wed, 15 Apr 2026 00:00:00 GMT

Note om det historiske design: Denne artikel fra april 2026 beskriver routingdesignet på det tidspunkt, ikke den nuværende standardadfærd. Rettelsen fra september nedenfor vedrører kun en påstand om en måling. Se Sådan virker det for aktuel routing, forudindstillinger og eksplicit styring af søgemodaliteter.

En søgeforespørgsel er ikke bare én ting.

“hvor er parseConfig defineret” ønsker et eksakt symbol — ét præcist sted, hurtigt. “hvordan fungerer autentificering” ønsker mening — spredningen af relateret kode, der forklarer et koncept. “hvad går i stykker, hvis jeg ændrer denne funktion” ønsker afhængighedsgrafen. “find strengen ECONNREFUSED” ønsker et bogstaveligt match, intet klogt.

Grep er fremragende til bogstavelige matches og nyttigt til nogle referencejagter, men det er ikke en afhængighedsgraf, og det forstår ikke mening. Embeddings dækker den semantiske side, men de er det forkerte værktøj til eksakte strenge og konsekvensanalyse. De fleste kodesøgningsværktøjer vælger én motor og lader enhver forespørgsel leve med det valg. Maguyva låser sig ikke til én motor. Det udreder, hvilken slags spørgsmål du stillede, og blander derefter fire retrievere i det forhold, spørgsmålet fortjener.

Fire modaliteter

Under motorhjelmen er der fire uafhængige måder at finde kode på:

semantisk — vektorsøgning over Voyage binære embeddings; finder kode ud fra mening.
tekst — trigram-matching; finder literals, fejlstrenge, eksakte identifikatorer.
strukturel — AST-forespørgsler; finder definitioner, signaturer og sprogkonstruktioner.
graf — afhængighedsgrafen; finder kaldere, kaldte og blast radius.

Hver er stærk på en anden klasse af spørgsmål. Kunsten er at afgøre, hvor meget man skal stole på hver enkelt for den forespørgsel, der ligger foran én.

Intentionsklassificering

Før nogen retrieval kører, sorterer en letvægtsklassifikator forespørgslen i en af seks intentioner med en konfidensscore. Den er bevidst billig — ordnede heuristikker, første match vinder — fordi den kører på den ofte benyttede eksekveringssti og kun tilføjer et millisekund eller to:

starter med def , class , func , import … → find_definition (konfidens 0.95)
“who calls”, “usages of”, “references to” → find_references (0.90)
“impact”, “blast radius”, “what depends on” → impact_analysis (0.90)
en streng i anførselstegn som "string" eller et fejltoken som traceback → exact_match (0.85–0.90)
en CamelCase- eller snake_case-identifikator → find_definition (0.60–0.80)
“how”, “why”, “explain”, “architecture” → understand_code (0.75)
intet matcher → understand_code, lav konfidens (0.40)

Hver intention bærer en vægtprofil på tværs af de fire modaliteter. Dette er de reelle tal:

Intention	semantisk	tekst	strukturel (AST)	graf
find_definition	0.2	0.1	0.6	0.1
find_references	0.1	0.2	0.2	0.5
understand_code	0.5	0.2	0.2	0.1
find_similar	0.4	0.3	0.2	0.1
impact_analysis	0.1	0.1	0.1	0.7
exact_match	0.0	0.9	0.1	0.0

Så “hvor er parseConfig defineret” læner sig kraftigt op ad AST (0.6). “hvordan fungerer auth” læner sig op ad semantiske vektorer (0.5). “hvad afhænger af dette” er næsten udelukkende graf (0.7). “find ECONNREFUSED” er næsten udelukkende trigram (0.9), hvor embedding-modellen er slået helt fra — fordi semantisk lighed er præcis det forkerte værktøj til en eksakt streng.

Den hurtige sti og den fusionerede sti

Når klassifikatoren er sikker — score ≥ 0.85 — og forespørgslen har en almindelig form, springer Maguyva fusion helt over og dirigerer direkte til den ene dominerende modalitet. “hvor er X defineret” har ikke brug for fire retrievere; det har brug for AST-indekset, nu. Den direkte sti rapporteres tilbage som fusion_strategy: "direct".

Alt tvetydigt går gennem fusion. De fire (eller tre, i standardpresettet) modaliteter kører parallelt, hver returnerer sin egen rangerede liste, og vi kombinerer dem.

Vægtet Reciprocal Rank Fusion

At fusionere heterogene retrievere er sværere, end det lyder: en kosinuslighed på 0.82 og en trigram-score på 137 og en graf-centralitet på 0.004 er ikke på samme skala, så man kan ikke bare lægge dem sammen. Reciprocal Rank Fusion omgår problemet ved at smide de rå scorer væk og kun beholde den rang, hver motor tildelte. Et resultats bidrag fra én modalitet er:

contribution = weight × 1 / (k + rank + 1)

hvor rank er dets position på den pågældende modalitets liste, og k er en udjævningskonstant. Bidrag summeres på tværs af modaliteter for ethvert resultat, som mere end én motor fandt — enighed mellem retrievere flyder naturligt til tops. Vi bruger k = 40 i standardpresettet og 60 på thorough (quick kører kun semantisk, så fusion træder aldrig i kraft der). Det oprindelige RRF-arbejde landede på k = 60 til almenformåls-retrieval; vores standardindstilling giver lidt mere vægt til resultater, som flere modaliteter placerer højt — og vi anbefaler ikke at finjustere den manuelt.

Oven i det bærer resultater et graf-vigtigheds-boost. Et knudepunkt — en funktion, hele kodebasen læner sig op ad — bør rangere højere end en mindre kendt bladnode, selv ved samme tekstlige relevans, så vi ganger hvert bidrag med:

boost = min(1 + 0.3 × ln(1 + centrality), 1.5)

Centralitet kommer fra pipelinens forudberegnede PageRank/degree-metrikker, og boostet er begrænset til 1.5×, så en populær funktion ikke helt kan begrave en mere relevant, men mindre kendt funktion. Til sidst nedgraderer vi resultater fra vendor-, build- og arkivstier og fjerner dubletter til det bedste chunk pr. fil.

Hvad der stadig er ufuldkomment

Intent-klassifikatoren er en samling regulære udtryk, ikke en trænet model. Den håndterer almindelige forespørgselsmønstre med heuristikker, og en tvetydig forespørgsel falder tilbage på understand_code og en blanding med vægt på semantik. En tidligere version af dette indlæg beskrev et fald i andelen af søgninger uden resultater fra cirka 15 % til under 5 % som opnået. Forslaget fra december 2025 angav faktisk en anslået udgangsværdi og et mål; der er ikke fremlagt et understøttende forespørgselssæt eller en målerapport. Vi trækker påstanden om en opnået forbedring tilbage; se kildeevidens og rettelse. Vi har ikke erstattet klassifikatoren med en trænet model, fordi den billige version er hurtig og god nok til sin tiltænkte routingopgave, og fordi en klassifikator, der tager fejl med stor sikkerhed, er værre end et ærligt fallback. Selve vægtene er håndvalgte forhåndsantagelser, ikke lært fra klikdata, som vi ikke indsamler.

Stil spørgsmålet uden at vælge værktøj

En agent burde ikke behøve at vide, om den skal ty til grep eller embeddings eller kaldegrafen — den bør stille sit spørgsmål i almindelige vendinger og få det rigtige svar. Multimodal fusion er det, der lader find_symbol, semantisk søgning og afhængighedsanalyse sidde bag ét fælles forespørgselsinterface: systemet aflæser spørgsmålets form og samler stille og roligt den rette retriever til det. Den model, der scorer embeddings, betyder noget, men det gør det også at vide, hvornår man ikke skal bruge dem. At vælge det rette værktøj til hver forespørgsel er sin egen slags kvalitet, og det er en, vi hellere selv vil eje end skubbe over på den kaldende part.

// you bring the question. it brings the tools.

Agent-observability: Hooks, Alloy og Grafana

Tue, 24 Mar 2026 00:00:00 GMT

Agentsystemer fejler på mærkelige måder.

Nogle gange er modellen problemet. Nogle gange er værktøjet problemet. Nogle gange er din MCP-server fin, men agenten valgte den forkerte specialist, eller brugte halvdelen af sessionen på shell-arbejde, du ikke havde forventet, eller lod omkostningerne løbe ubemærket op i en løkke, der så produktiv ud udefra.

Hvis du ikke kan se forskellen, driver du ikke rigtig et agentsystem. Du gætter.

Så vi byggede en observability-stak til vores egen arbejdsgang: Claude Code, Codex, Claude hook-events, Codex notify-events, native OpenTelemetry, Grafana Alloy og Grafana Cloud i den anden ende.

Den interessante del er ikke “vi lavede et dashboard.” Den interessante del er, at vi var nødt til at opdele telemetri i to forskellige strømme, fordi intet enkelt feed gav os hele billedet.

Problemet: agent-telemetri er fragmenteret

Moderne kodeagenter udsender allerede noget telemetri. Det hjælper, men det er ikke nok.

Native OTEL er god til at besvare spørgsmål som:

Hvor mange requests foretog vi?
Hvor meget kostede en session?
Hvor er spans og traces?
Steg latensen?

Den er meget dårligere til at besvare spørgsmål som:

Hvilken MCP-server lænede agenten sig op ad?
Var denne fejl i Bash, et indbygget filværktøj eller et MCP-kald?
Hvilken skill blev rent faktisk aktiveret?
Hvilken subagent-type blev afsendt?
Udførte sessionen nyttigt arbejde, eller kørte den bare i ring?

Den anden klasse af spørgsmål lever tættere på hooks end på traces.

Men det omvendte gælder også: nogle af de vigtigste performance-spørgsmål lever tættere på traces end på hooks.

Hvis du vil vide, hvor latensen faktisk akkumulerede sig, hvilke spans der var langsomme, eller om sessionen brugte tid på modelkald frem for værktøjseksekvering, har du brug for trace-data lige så vel som semantiske events.

Arkitekturen, vi endte med

Vi kører to telemetristier side om side.

Claude Code
  native OTEL -> Alloy -> Grafana Cloud
  hooks        -> send_event.py -> Grafana Cloud Loki

Codex
  native OTEL -> Alloy -> Grafana Cloud
  notify hook -> codex_notify.py -> shared Loki schema

Den opdeling er bevidst.

Den er også asymmetrisk. Claude Code giver os en langt rigere grænseflade til livscyklus-hooks. Codex giver os native OTEL plus en notify-grænseflade, så vi normaliserer mindre detaljerede events om afsluttede samtalerunder ind i det samme log-skema i stedet for at foregive, at begge runtimes eksponerer de samme kontroller.

Native OTEL giver os basisstrømmen: logs og traces fra selve runtimet, plus metrikker der, hvor runtimet rent faktisk udsender dem.

Hook- og notify-events giver os det semantiske lag: ting som PreToolUse, PostToolUse, PostToolUseFailure, UserPromptSubmit, SubagentStop, SkillActivated og de klassificerede metadata, vi rent faktisk bekymrer os om, når vi debugger agentadfærd. Claude Code bidrager med den rigere event-strøm her. Codex bidrager med en mindre detaljeret, men stadig nyttig normaliseret strøm.

Hvorfor hooks overhovedet findes

Vores hook-pipeline beriger events, før de rammer Loki.

I stedet for bare at sige “et værktøj kørte”, klassificerer vi eventet i felter som:

tool_type: builtin, mcp, skill, agent, bash
mcp_server: hvilken MCP-backend håndterede kaldet
bash_cli: shell-kommandofamilien
subagent_type: hvilken slags specialist blev afsendt
agent_tool: om kilden var Claude Code eller Codex

Det betyder, at vi kan stille spørgsmål, der betyder noget driftsmæssigt:

{service_name="claude-code-hooks"} | agent_tool="codex-cli"
{service_name="claude-code-hooks"} | tool_type="mcp"
{service_name="claude-code-hooks"} | json | bash_cli="git"

De felter er ikke bare til pynt. De er forskellen mellem “agenten føltes langsom” og “agenten brugte de sidste ti minutter på shell-tunge git-operationer med en høj værktøjsfejlrate.”

Én implementeringsdetalje, der ser mærkeligere ud, end den er: den delte Loki-strøm bruger stadig service_name="claude-code-hooks" som label, selv når eventet kom fra Codex. Den reelle opdeling mellem runtimes sker på agent_tool.

Hvorfor Alloy sidder i midten

Grafana Alloy er ikke bare en videresender i denne opsætning. Det er her, reglerne for telemetrien håndhæves.

Vi peger den native OTEL-strøm fra Claude Code og Codex mod en lokal Alloy-proxy på localhost:4318 og lader derefter Alloy rydde op i payloaden, før den videresendes til Grafana Cloud.

Det betyder noget, fordi rå agent-telemetri er fuld af høj-kardinalitetsfelter, der er nyttige til analyse, men forfærdelige som indekserede labels:

session_id
prompt_id
token-antal
varigheder
værktøjsparameter-blobs

Hvis du indekserer alt, får du en label-eksplosion og en dårlig dag.

Så Alloy gør tre ting for os:

Holder et meget lille sæt lav-kardinalitetslabels indekseret.
Flytter støjende, men nyttige felter over i strukturerede metadata.
Dropper ren støj helt.

Den vigtige idé er simpel: observér mere, indeksér mindre.

Hvorfor hook-strømmen springer Alloy over

Hook-strømmen er allerede formet til Loki.

I det øjeblik send_event.py pusher et event, har vi allerede besluttet, hvilke felter der fortjener label-behandling, og hvilke der hører hjemme i den strukturerede JSON-krop. Den strøm går direkte til Grafana Clouds OTLP-gateway i stedet for at tage endnu en tur gennem Alloy.

Så systemet har en klar arbejdsdeling:

Alloy tæmmer den rå native OTEL-strøm.
Hook-berigelse gør semantiske events forespørgelige.

Det holder arkitekturen enklere end at forsøge at tvinge alt gennem én sti.

Hvad dashboardet rent faktisk viser

Skærmbilledet nedenfor er fra et af observability-dashboardene bag vores agent-arbejdsgang. Det er ikke en benchmark, og tallene er blot et øjebliksbillede. Pointen er formen på dataene: activity feed, værktøjskald, fejl, prompts og opdelinger efter agent, indbyggede værktøjer, MCP-brug, shell-kommandoer og skills.

Det nyttige er, at dette dashboard lever på den samme Grafana-stak som resten af agent-telemetrien. Vi kan filtrere efter kilde-agent og værktøjsfamilie og se på tværs af runtimes uden at opfinde en særskilt observability-løsning for hvert system.

Et af de live dashboards bag vores agent-arbejdsgang. Dette skærmbillede er blot ét udsnit af en delt Grafana-stak, der også modtager telemetri fra vores andre agent-runtimes og -systemer. Klik på billedet for versionen i fuld opløsning.

Hvorfor traces betyder mere, end de først ser ud til

Logs fortæller os, hvilken kategori af arbejde der skete. Traces fortæller os, hvordan arbejdet udfoldede sig over tid.

Den skelnen betyder noget i agentsystemer, fordi “langsom” er for groft til at være nyttigt.

Et trace kan fortælle os, om problemet skyldtes:

modellatens
værktøjseksekveringstid
gentagne retries
én særligt dyr MCP-interaktion
en lang hale af små operationer, der isoleret set så harmløse ud

I praksis bruger vi hook-strømmen og Tempo-traces sammen.

Hook-logs besvarer: hvilken slags ting skete der?
Traces besvarer: hvor gik tiden hen?

Kombinationen er det, der forvandler observability fra et dashboard til en forklaring.

Hvor Codex passer ind

Codex er en del af den samme stak, men den er ikke identisk med Claude Code.

For Codex kobler vi to dele sammen:

Native OTEL fra Codex ind i Alloy
Et notify-webhook ind i codex_notify.py, som mapper afsluttede samtalerunder til det samme Loki-skema, vi bruger til hook-events

Det giver os et samlet filter som agent_tool="codex-cli" inden i den samme log-strøm.

Det ærlige forbehold: Codex’ notify-payload er i øjeblikket mindre detaljeret end Claude Codes hook-payload, fordi det ikke er den samme slags integrationsgrænseflade. I vores nuværende opsætning kan afsluttede samtalerunder i Codex normaliseres ind i det delte skema, men detaljeret værktøj-for-værktøj-udtræk er stadig bedre i den native OTEL-strøm end i notify-broen.

Det er ikke en grund til at undgå indlægget. Det er hele pointen med indlægget. Rigtige observability-systemer samles ud fra ufuldkomne signaler.

Grafana over MCP ændrer spillet

Det større skifte er, at Grafana ikke kun er et sted, mennesker besøger i en browser.

I dette repository eksponerer vi også Grafana gennem MCP. Det betyder, at en agent kan forespørge Loki, Prometheus og Tempo direkte i stedet for at vente på, at et menneske manuelt inspicerer dashboardene først.

Det gør observability til et aktivt input til arbejdsgangen.

En agent kan spørge:

Hvilke værktøjsfamilier fejlede mest i den seneste time?
Hvilken MCP-server dominerede en session?
Reducerede seneste ændringer værktøjsfejl, eller flyttede de bare arbejdet over i mere shell-tunge stier med de samme fejl?
Hvilke traces viser den højeste latens eller gentagne retries?

Når du har det, er du meget tæt på en selvforbedringsløkke.

Fra dashboard til feedbackløkke

Det er den del, vi finder mest interessant.

Når observability-stakken er forespørgelig fra agentlaget, holder telemetri op med at være en passiv rapporteringsflade og bliver et kontrolsignal.

Løkken ser sådan ud:

Agentaktivitet udsender traces, metrikker og berigede hook-logs.
Grafana gemmer beviserne i Loki, Tempo og Prometheus, hvor metrikker findes.
Agenter forespørger de beviser gennem Grafana MCP.
Systemet identificerer en uhensigtsmæssig blanding af værktøjer, skrøbelige skills, svag routing eller shell-tunge arbejdsgange, der bliver ved med at producere undgåelige fejl.
Agenter eller operatører justerer prompts, agentkonfigurationer, skill-beskrivelser, routing-regler eller værktøjsadgang.
Den næste session producerer et nyt mønster i telemetrien, og cyklussen gentages.

Sådan bevæger man sig fra “interessant dashboard” til “målbart forbedringssystem.”

Målet er ikke at maksimere én værktøjskategori. Det er at lande på den rette blanding af CLI, indbyggede værktøjer, MCP-kald og skills til det arbejde, der rent faktisk udføres.

Hvad dette lader os besvare

Når begge runtimes lander i den samme Grafana-stak, kan vi besvare driftsspørgsmål meget hurtigere:

Er fejl koncentreret i én værktøjsfamilie?
Skaber shell-tunge arbejdsgange undgåelige fejl, hvor et højere-niveau-værktøj burde eksistere?
Hvilke MCP-servere bærer arbejdsbyrden?
Betaler vi for agentaktivitet, der ikke producerer meningsfuld fremdrift?
Er en session usund på grund af modellen, værktøjerne eller orkestreringslaget?

Det er særligt nyttigt i multi-agent-arbejdsgange, hvor “agenten var travlt optaget” fortæller dig næsten ingenting.

Hvis én specialist bliver ved med at blive afsendt og producerer høje fejlrater, er det et routing- eller prompt-formningsproblem.

Hvis én MCP-server dominerer alle kald, kan det være god arkitektur eller et tegn på, at alt andet er dødvægt.

Hvis værktøjsfejl stiger, mens omkostningerne forbliver høje, har du et driftsproblem, ikke et kvalitetsproblem.

Hvis shell-arbejde bliver ved med at fejle på forudsigelige, undgåelige måder, hvor et højere-niveau-værktøj burde eksistere, er det et produktsignal.

Hvis én skill aktiveres konstant, men ikke forbedrer resultaterne, er det et prompt- eller routing-signal.

Den reelle lektie

Den dybere lektie her er, at agent-observability har brug for både runtime-telemetri og arbejdsgangs-telemetri.

Runtime-telemetri fortæller dig, hvad systemet gjorde.

Arbejdsgangs-telemetri fortæller dig, hvad agenten troede, den var i gang med.

Vi har brug for begge dele.

Hvis du kun beholder traces og tællere, går du glip af det semantiske lag. Hvis du kun beholder hook-events, går du glip af latens, spans og det bredere runtime-billede.

Og hvis du beholder begge dele, men aldrig fodrer dem tilbage ind i agentlaget, har du monitorering, ikke tilpasning.

Kombinationen er det, der gør systemet forklarligt nok til at drive og finjusterbart nok til at forbedre.

Hvad der stadig er ufuldkomment

Der er stadig ting, som mangler finpudsning.

Ikke ethvert hook-event inkluderer de varigheds- og token-data, vi gerne ville have.
Nogle af de bedste timing-visninger kommer stadig fra Tempo-traces, ikke hook-logs.
Codex er i dag mindre semantisk rig end Claude Code i den berigede event-strøm.
Dashboard-skærmbilledet er en levende driftsflade, ikke et poleret marketingartefakt.

Det sidste punkt er tilsigtet. Vi vil hellere vise det rigtige instrumentbræt end lade som om, agentsystemer magisk forklarer sig selv.

Hvorfor det betyder noget for Maguyva

Maguyva handler om at give agenter bedre kodeintelligens. Men når agenter rent faktisk udfører nyttigt arbejde, dukker der straks et nyt krav op: du skal kunne se, hvordan de opfører sig.

Søgekvalitet, routing-kvalitet, værktøjsvalg og effektiv udnyttelse af konteksten bliver alle sammen observerbare problemer.

Det er derfor, vi mener, det er værd at skrive om. Fremtidens agent-stak er ikke bare prompts og værktøjer. Det er prompts, værktøjer og det instrumenteringslag, der fortæller dig, om det hele fungerer.

Hvis du bygger seriøse agent-arbejdsgange, er observability ikke valgfri infrastruktur. Det er en del af produktet.

Mining-løkken: Sådan bliver ændringer til institutionel hukommelse

Tue, 03 Feb 2026 00:00:00 GMT

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (februar 2026). Se vores team-side for aktuelle tal.

Ethvert engineering-team står over for den samme udfordring: ændringer sker konstant, men hvorfor’et bag de ændringer forsvinder. Seks måneder senere spørger nogen “hvorfor valgte vi DuckDB til pipeline-stadier?”, og svaret lever kun i hovedet på den, der traf det valg — hvis vedkommende stadig er her.

Vi byggede en mining-arbejdsgang, der lukker denne løkke. Ændringer flyder gennem git-commits, bliver behandlet af vores mining-pipeline, bliver til strukturerede changelog-poster og arkitektoniske beslutningsregistreringer, og fødes derefter tilbage til vores AI-agenter gennem CLI-forespørgsler. Resultatet: institutionel hukommelse, som både mennesker og AI kan tilgå.

Problemet: Beslutninger fordamper

Overvej et typisk scenarie. En udvikler committer:

feat(canonical): add DuckDB runtime for pipeline stages

Denne commit repræsenterer et betydeligt arkitektonisk valg. Teamet evaluerede muligheder, overvejede afvejninger og landede på DuckDB af specifikke årsager. Men al den kontekst lever i:

En Slack-tråd (sandsynligvis slettet)
Nogens hukommelse (bestemt falmende)
En kommentar i koden (måske, hvis man er heldig)

Tre måneder senere spørger et nyt teammedlem: “Skal jeg bruge DuckDB eller SQLite til dette nye stadie?” Uden institutionel hukommelse genopfinder de enten den dybe tallerken eller træffer inkonsistente valg.

Løkken: Fra commits til kontekst

Vores mining-arbejdsgang omdanner git-historik til forespørgelig viden:

Git Commits
    │
    ▼
┌─────────────────────┐
│  mine sync          │  ← Build index from git history
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│  mine candidates    │  ← Surface commits for review
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│  Classification     │  ← Human or LLM assessment
│  (changelog or ADR) │
└─────────────────────┘
    │
    ├──────────────────────┐
    ▼                      ▼
┌─────────────┐    ┌───────────────┐
│ Changelog   │    │ Decisions     │
│ Ledger      │    │ Registry      │
│ (JSONL)     │    │ (YAML files)  │
└─────────────┘    └───────────────┘
    │                      │
    ▼                      ▼
┌─────────────┐    ┌───────────────┐
│ CHANGELOG.md│    │ orkestra CLI  │
│ per package │    │ queries       │
└─────────────┘    └───────────────┘
    │                      │
    └──────────────────────┘
              │
              ▼
      ┌───────────────┐
      │ AI Agents     │
      │ (via CLI)     │
      └───────────────┘

Den centrale indsigt: både changelogs og arkitektoniske beslutninger flyder fra den samme git-historik, behandlet gennem en samlet pipeline. Det sikrer, at intet falder mellem to stole.

Sådan fungerer mining

Trin 1: Synkronisér indekset

uv run orkestra mine sync

Denne kommando skanner git-historik og bygger et indeks over alle commits. Den udtrækker strukturerede signaler fra hver commit:

Konventionel commit-type (feat, fix, chore, docs)
Scope (hvilken pakke eller hvilket område)
Breaking-change-markører
Berørte filer og kompleksitetsmetrikker

Trin 2: Tjek dækningsstatus

uv run orkestra mine status

Sådan ser vores nuværende status ud:

Mining Status
=============

Decisions
---------
  Coverage:        100.0%
    Processed:     15637  (of 15637)
    Extracted:       476
    Skipped:       15161

Changelog
---------
  Coverage:        100.0%
    Processed:     15637  (of 15637)
    Released:       6799
    Skipped:        8838

15.637 commits behandlet. 476 blev til arkitektoniske beslutninger. 6.799 blev til changelog-poster. Hver commit klassificeret.

Trin 3: Hent kandidater til gennemgang

uv run orkestra mine candidates --limit 50 --full

Dette fremviser commits, der endnu ikke er blevet behandlet, med fuld kontekst til klassificering:

{
  "sha": "90571786d99166c0039ca2e80e4d9cd96184bd85",
  "date": "2026-01-26",
  "subject": "feat(canonical): add DuckDB runtime for pipeline stages",
  "signals": {
    "commit_type": "feat",
    "scope": "canonical",
    "breaking": false,
    "is_releasable_type": true,
    "domains_affected": ["pipeline", "data-architecture"]
  },
  "body": "Establishes DuckDB as canonical in-process analytical database...",
  "files_changed": ["packages/canonical/pipelines/stages/duckdb_runtime.py", "..."],
  "stats": {"files": 8, "insertions": 450, "deletions": 120}
}

Signalerne hjælper med at guide klassificeringen: is_releasable_type: true antyder, at denne bør fremgå af changelog’en. Det store antal indsættelser og infrastrukturfilerne antyder, at den også kunne være en arkitektonisk beslutning.

Trin 4: Klassificér commits

To stier deler sig her: changelog-poster og arkitektoniske beslutninger.

For changelog-poster:

uv run orkestra mine classify abc123 --changelog added

Dette registrerer, at commit abc123 bør fremgå af changelog’en under kategorien “Added.”

For arkitektoniske beslutninger:

Først, hent et reelt beslutnings-ID:

uv run orkestra registry decisions new --domain pipeline --dry-run
# Returns: DEC-PL-143

Klassificér derefter med beslutnings-ID’et:

uv run orkestra mine classify abc123 --decision DEC-PL-143

Dette knytter commit’en til en beslutningsregistrering, der vil blive oprettet eller opdateret.

For batch-behandling (det, vi rent faktisk gør):

# Generate classifications file with LLM assistance
uv run orkestra mine commit --input classifications.jsonl

JSONL-formatet understøtter begge domæner i én omgang:

{"sha":"abc123","domain":"changelog","action":"release","category":"added","summary":"Add DuckDB runtime for pipeline stages"}
{"sha":"abc123","domain":"decisions","action":"extract","decision_id":"DEC-PL-142"}
{"sha":"def456","domain":"changelog","action":"skip","reason":"Chore: dependency update"}

Trin 5: Render outputs

uv run orkestra registry changelog render --package <pkg>

Dette genererer CHANGELOG.md-filer pr. pakke ud fra ledgeren. Changelogs er afledte artefakter — slet dem, og de genereres perfekt igen fra kilde-ledgeren.

Beslutningsregistreringens struktur

Udtrukne beslutninger bliver til YAML-filer med detaljerede metadata:

id: DEC-PL-142
title: Adopt DuckDB as Canonical Processing Runtime for Pipeline Stages
domain: pipeline
status: active
created: '2026-01-26'
summary: |
  Establishes DuckDB as the canonical in-process analytical database for pipeline
  stage transformations. Provides a shared runtime module that resolves settings
  from pipeline defaults with stage-level overrides.

context: |
  Pipeline stages performing data transformations each independently configured
  DuckDB connections. This led to inconsistent settings, duplicated configuration
  code, and no way to tune DuckDB globally for a pipeline run.

rationale:
  - DuckDB provides efficient in-process OLAP with zero configuration deployment
  - Centralized runtime module eliminates duplicated DuckDB setup across stages
  - Hierarchical settings enable global tuning with stage-level overrides
  - Memory limits and thread counts can be adjusted per-pipeline

impact:
  positive:
    - Consistent DuckDB configuration across all pipeline stages
    - Single point of control for memory/thread tuning
    - Reduced code duplication in conversion and export stages
  negative:
    - Adds dependency on shared runtime module
    - Stages must adopt new configuration pattern

source_commits:
  - sha: 90571786d99166c0039ca2e80e4d9cd96184bd85
    message: 'feat(canonical): add DuckDB runtime for pipeline stages'
    date: '2026-01-26'
    role: primary

files:
  - packages/canonical/pipelines/stages/duckdb_runtime.py
  - packages/canonical/pipelines/runner.py
  - packages/canonical/pipelines/stages/convert_hdx_admin_boundaries_to_geoparquet.py

related:
  - DEC-DA-014  # Data architecture decisions that influenced this

Hver beslutning linker tilbage til sine kilde-commits. Hver beslutning angiver, hvilke filer den påvirker. Relationer mellem beslutninger er eksplicitte.

CLI-integration: Forespørgsel på institutionel hukommelse

Det er her, løkken lukkes. Agenter kan forespørge beslutninger gennem CLI’en:

# Search by topic
uv run orkestra registry decisions search --query "retry"

Returnerer beslutninger om retry-logik, fejlhåndtering, recovery-mønstre.

# Get full details on a specific decision
uv run orkestra registry decisions info DEC-PL-142

Returnerer den komplette beslutningsregistrering med kontekst, begrundelse og konsekvens.

# List recent decisions for context
uv run orkestra registry decisions list --limit 15

Viser hvilke arkitektoniske valg der blev truffet for nylig.

Sådan bruger agenter dette

Vores orkestrators grundlæggende instruktioner inkluderer:

**Essential CLI commands:**
- `orkestra registry decisions search "X"` — Find architectural decisions

Når en agent bliver bedt om at implementere noget relateret til DuckDB, kan den først tjekke:

uv run orkestra registry decisions search --query "DuckDB"

Og opdage DEC-PL-142, og lære:

Hvorfor vi valgte DuckDB (context)
Hvordan man bruger det korrekt (agent_guidance)
Hvilke filer man skal kigge på (files)
Hvilke relaterede beslutninger der findes (related)

Agenten genopfinder ikke den dybe tallerken. Den bygger videre på etablerede mønstre.

Testen med tre spørgsmål

Ikke enhver commit fortjener en beslutningsregistrering. Vi bruger testen med tre spørgsmål til at filtrere:

Var beslutningen svær at træffe? Krævede det betydelig analyse, afvejningsvurdering eller debat?
Er det dyrt at ændre? Ville det kræve betydeligt genarbejde at omgøre denne beslutning?
Har det konsekvenser for hele systemet? Påvirker det flere pakker eller etablerer det mønstre, andre vil følge?

Hvis en commit svarer “ja” på mindst ét af disse spørgsmål, er den kandidat til beslutningsudtræk. Vores typiske rate: 1-4 beslutninger pr. 100 commits (omkring 1-4%).

For changelog-poster er barren lavere: enhver brugervendt ændring (features, fixes, forbedringer) registreres. Interne opgaver, dokumentationsopdateringer og refaktoreringer springes typisk over. Vores typiske rate: 30-50 changelog-poster pr. 100 commits.

Datalagring: Append-only ledgers

Mining-systemet bruger append-only JSONL-ledgers til konfliktfri multi-agent-drift:

packages/orchestration/ai_assets/reference/changelog/
├── commits_processed.jsonl  # Classification ledger (both domains)
├── release_notes.jsonl      # Changelog entries
└── commits_index.yaml       # Derived index (gitignored)

packages/orchestration/ai_assets/reference/decisions/
├── registry.yaml            # Decision index
└── records/
    ├── DEC-AD-001.yaml
    ├── DEC-AD-002.yaml
    └── ...

JSONL-formatet med merge=union i .gitattributes betyder, at flere agenter kan klassificere commits samtidigt uden merge-konflikter. Hver linje er uafhængig.

Valideringsgates

Før enhver mining-session kører vi validering:

uv run orkestra mine validate --quick

Dette tjekker:

Gyldighed af SHA-format
Overholdelse af beslutnings-ID-format
Ingen dubletregistreringer for den samme SHA
At refererede beslutninger rent faktisk findes

Efter klassificering validerer vi igen, før vi committer ændringerne.

Hvorfor det betyder noget

Den feedbackløkke, vi har bygget, løser flere problemer:

For nye teammedlemmer: I stedet for at spørge “hvorfor gjorde vi X?”, kan de søge i beslutningsregistret. Konteksten er bevaret.

For AI-agenter: De opererer ikke i et vakuum. De kan forespørge institutionel viden, før de kommer med anbefalinger. Når de bliver bedt om at tilføje et nyt pipeline-stadie, kan de opdage DuckDB-mønsteret og følge det.

For arkitektonisk konsistens: Beslutninger er eksplicitte og søgbare. Når nogen foreslår en tilgang, der modsiger en eksisterende beslutning, kan systemet fremhæve konflikten.

For changelog-generering: Release notes er ikke noget, der skal skrives i sidste øjeblik. De er et biprodukt af løbende klassificering under udvikling.

For onboarding: Nye agenter arver hele kodebasens kontekst. De ser ikke bare koden — de ser de beslutninger, der formede den.

Nuværende tilstand

Pr. i dag:

15.637 commits behandlet gennem pipelinen
476 arkitektoniske beslutninger udtrukket og dokumenteret
6.799 changelog-poster registreret
100% dækning på tværs af begge domæner

Hver commit siden vi startede, er blevet klassificeret. Den institutionelle hukommelse er komplet og forespørgelig.

Kom i gang

Hvis du vil implementere noget lignende:

Start med konventionelle commits. Mining-pipelinen fungerer bedst, når commits har strukturerede præfikser (feat:, fix:, chore:).
Definér dine domæner. Vi bruger domæner som pipeline, agent-design, observability, data-modeling. Disse organiserer beslutninger efter område.
Byg klassificeringsvanen op. Mining fungerer, når teams regelmæssigt klassificerer commits. Batch-behandling med LLM-assistance hjælper med at skalere.
Gør beslutninger forespørgelige. Værdien vokser yderligere, når agenter kan søge i beslutninger via CLI. Strukturér dit output til maskinel behandling.
Luk løkken. Beslutninger bør påvirke fremtidigt arbejde. Inkludér beslutningsreferencer i agentinstruktioner og code review-tjeklister.

Målet er ikke perfekt dokumentation. Det er at gøre hvorfor’et bag ændringer tilgængeligt for både mennesker og AI, i dag og seks måneder fra nu. Når ændringer bliver institutionel hukommelse, bygger teams videre på etablerede mønstre i stedet for at genopfinde dem.

Mining-arbejdsgangen er en del af vores orkestreringsmotor, specifikt context-motor-modulet i vores orchestration-pakke.

Skill mining: Fra 3.500 kandidater til 466 kapabiliteter

Tue, 27 Jan 2026 00:00:00 GMT

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (januar 2026). Se vores team-side for aktuelle tal.

3.500-skill-problemet

Da vi begyndte at bygge et agent-orkestreringssystem, stod vi over for en interessant udfordring: der findes tusindvis af potentielle skills spredt ud over AI-økosystemet. GitHub-repositorier, leverandørdokumentation, community-projekter, interne mønstre - skills findes overalt. Men hvilke betyder noget? Hvilke virker? Og hvordan vedligeholder man et sammenhængende skill-bibliotek, som agenter rent faktisk kan bruge?

Vores svar: en systematisk mining- og indarbejdelsesløkke.

Tallene i dag

Lidt over tre måneder efter Anthropic lancerede Agent Skills den 16. oktober 2025, så vores status sådan ud, da dette indlæg blev udgivet den 27. januar 2026:

Metrik	Antal
Identificerede kandidater	3.500+
Adopterede skills	466
Leverandør-skills	373
Interne skills	93
Aktive leverandører	25+
Gennemsnitlige tokens pr. skill	2.834
Refererede værktøjer	89
Unikke tags	635

Vi har gennemgået over 3.500 skill-kandidater. Vi har adopteret 466. Det er en adoptionsrate på 13% - og den selektivitet er tilsigtet.

Videnslagssystemet

Ikke alle skills har samme værdi. Vi organiserer dem i fem videnslag (K0-K4), der hver repræsenterer et forskelligt anvendelsesscope:

K0: Foundations (universel)

Skills, enhver agent bør have. Disse repræsenterer “god tænker”-kapabiliteter, der virker overalt.

foundations/
├── test-first-discipline       # TDD: Red-Green-Refactor
├── evidence-based-completion   # Verify before claiming done
├── systematic-debugging        # Root cause methodology
├── structured-planning         # Break work into tasks
└── context-budget-awareness    # Manage token consumption

K0-skills er portable til ethvert projekt, ethvert domæne, enhver stack. De indkoder universelle kognitive mønstre.

K1: Identities (disciplin)

“God ingeniør”- eller “god forsker”-skills, der gælder på tværs af projekter inden for en disciplin.

identities/
├── research-workflows          # Multi-source research
├── web-extraction-playbook     # Content extraction
├── code-review                 # PR review patterns
└── cli-interface-standards     # CLI design patterns

K2: Domains (fagekspertise)

“God databaseekspert”- eller “god sikkerhedsingeniør”-skills, der er portable inden for et felt.

domains/
├── schema-migration-workflow   # Safe migration patterns
├── rpc-validation-checklist    # RPC health checks
├── auth-validation-checklist   # JWT/OAuth patterns
└── secrets-audit-checklist     # Credential scanning

K3: Stacks (teknologi)

“God Supabase-bruger”- eller “god Cloudflare-udvikler”-skills til specifikke teknologistakke.

stacks/
├── maguyva-quickstart          # Our semantic search patterns
├── cloudflare-deployment       # Workers/Pages deployment
└── mcp-tool-best-practices     # MCP tool selection

K4: Project (organisation)

Skills, der er specifikke for vores organisation og arbejdsgange.

project/
├── agent-creation-workflow     # How we build agents
├── skill-authoring-workflow    # How we write skills
├── mining-session-workflow     # This very process
└── vendor-skill-evaluation     # Evaluation rubrics

Mining-løkken

Fase 1: Discovery

Skills kommer fra alle steder:

Leverandørrepositorier: AWS, Anthropic, Cloudflare, Supabase og community-bidragydere udgiver skill-samlinger. Vi følger 25+ leverandørrødder.

Community-projekter: GitHub er fuldt af Claude Code-skabeloner, agentmønstre og arbejdsgangsdefinitioner.

Interne mønstre: Efterhånden som vores team løser problemer, opstår mønstre. Disse formaliseres til skills.

Dokumentationsmining: Teknisk dokumentation indeholder ofte implicitte skills - procedurer, tjeklister, beslutningstræer.

Discovery er kontinuerlig. Vi bruger en skill-backlog til at spore kandidater før formel evaluering.

Fase 2: Evaluering

Enhver kandidat vurderes efter de samme kriterier:

adoption_criteria:
  - fills_real_gap: true      # We lack this capability
  - well_structured: true     # Progressive disclosure
  - actively_maintained: true # Commits in last 6 months
  - portable: true            # Not hyper-specific
  - tested: true              # Evidence of usage

Alle fem produktkriterier skal bestås. Det er derfor, 87% af kandidaterne afvises.

Derefter gennemgår enhver kandidat en separat tillidsgennemgang. Vi behandler ikke et officielt leverandørrepository, en velkendt community-vedligeholder og et tilfældigt GitHub-repository som ligeværdige sandhedskilder.

trust_review:
  vendor_credibility:
    - ownership_verified       # Official vendor, known maintainer, or internal source
    - maintenance_signal       # Recent commits, issue response, release history
    - adoption_signal          # Evidence of real use, stars alone are not enough
    - provenance_clear         # We can trace where the skill came from
  prompt_injection_scan:
    - hidden_instruction_check # Buried "ignore previous instructions" patterns
    - exfiltration_check       # Prompts that try to leak files, secrets, or context
    - authority_check          # Claims of priority over system or developer rules
  script_audit:
    - inspect_scripts          # Read shell/python/js helpers before adoption
    - network_and_exec_review  # curl|bash, remote downloads, subprocess execution
    - file_and_secret_review   # Env vars, credential access, broad file writes
    - destructive_action_check # rm, reset, overwrite, or unsafe automation

Betroede leverandører får en lettere proveniensgennemgang, men ikke fribillet. Ikke-betroede eller ukendte kilder får et dybere manuelt tjek, og vi kører ikke medfølgende scripts, før de er blevet læst, afgrænset og klassificeret som sikre.

Gap-analyse: Før vi adopterer, søger vi i vores register:

uv run orkestra skills search "<capability>"

Hvis vi allerede har det, har vi ikke brug for det. Hvis vi har noget tæt på, kan vi vælge at fusionere i stedet for at adoptere.

Dybde- og standardscoring: Vi scorer også, hvor fuldt en kandidat udnytter agent-skill-modellen. Et enligt SKILL.md kan stadig være nyttigt, men dybere skills er mere værdifulde, når de adskiller instruktioner fra referencer, scripts og assets på den måde, agentskills.io opfordrer til.

skill_depth:
  - level_1: SKILL.md only                     # Single instruction file
  - level_2: SKILL.md + strong description     # Clear triggers and scope
  - level_3: adds references/                  # Load docs only when needed
  - level_4: adds atomic scripts/              # Small, reviewable helpers
  - level_5: adds assets/examples/templates    # Full progressive disclosure
depth_signals:
  - standards_adherence        # Structure aligns with agentskills.io conventions
  - reference_quality          # Curated references, not giant context dumps
  - script_atomicity           # Focused helpers, not opaque monoliths
  - tool_boundary_clarity      # Clear limits on what the skill can execute
  - community_signal           # Stars/forks/users help, but only as a weak boost

GitHub-stjerner kan løfte en troværdighedsscore en smule, men de redder aldrig en overfladisk eller usikker skill. Et repository med mange stjerner og én vag SKILL.md og uigennemsigtige scripts scorer lavere end et mindre repository med en præcis beskrivelse, kurateret references/ og atomare hjælpefunktioner, der rent faktisk udnytter den fulde skill-kapabilitet.

Strukturel analyse: Vi tjekker skill-kvalitet:

wc -l vendor/<repo>/<skill>/SKILL.md  # Size check
ls vendor/<repo>/<skill>/scripts/     # Supporting files
ls vendor/<repo>/<skill>/references/  # Bundled docs

Hvis en kandidat inkluderer scripts, bliver den gennemgang mere striks. En god skill er ikke bare nyttig; den skal være læselig, afgrænset og sikker at overlade til en agent. Det sikkerhedsfilter alene diskvalificerer en betydelig andel af ellers interessante kandidater.

Fase 3: Indarbejdelse

Når en skill består evalueringen, kommer den ind i registret. Men skills adopteres aldrig uændrede. De modificeres, så de passer til vores system.

Modifikationer ved adoption:

Metadata-normalisering: Enhver skill får vores frontmatter-skema
K-lags-tildeling: Skills placeres i det passende videnslag
Tag-berigelse: Tags tilføjes til discovery
Værktøjsdeklaration: Tilladte værktøjer erklæres eksplicit
Sektionsjustering: Indhold omstruktureres, så det matcher vores template

En typisk skill-YAML efter indarbejdelse:

metadata:
  identifier: vendor-skill-evaluation
  name: vendor-skill-evaluation
  description: Systematic evaluation of vendor skills for adoption.
  type: workflow
  layer: K4
  semantic_folder: project
  source: core
  last_updated: '2026-01-17'

frontmatter:
  tags:
    - agents
    - meta
    - skill-adoption
    - vendor
  allowed_tools:
    - Bash
    - Read
    - Write
    - Edit
    - Grep
    - Glob
    - Task

Fase 4: Scope-tildeling

Skills tildeles scopes - kategorier, der afgør, hvilke agenter der indlæser hvilke skills:

scopes:
  database:
    primary_skills:
      - domains/schema-migration-workflow
      - domains/rpc-validation-checklist
      - vendor/supabase/supabase-database
      - vendor/supabase/supabase-auth

  research:
    primary_skills:
      - identities/research-workflows
      - identities/web-extraction-playbook
      - identities/dataset-discovery-quickstart

Agenter erklærer deres scopes, og skills tildeles automatisk:

# Agent definition
scopes: [database, research]
# Gets: all database skills + all research skills + universal skills

Fase 5: Materialisering

Skills lever ikke som YAML i produktion. De renderes til SKILL.md-filer, som Claude Code kan indlæse:

uv run orkestra sync

Denne kommando:

Læser alle skill-YAML-definitioner
Renderer dem gennem Jinja-templates
Skriver SKILL.md-filer til .claude/skills/
Organiserer efter K-lag (foundations/, identities/, domains/, stacks/, project/)

Den endelige outputstruktur:

.claude/skills/
├── foundations/     # K0: Universal
├── identities/      # K1: Discipline
├── domains/         # K2: Subject
├── stacks/          # K3: Technology
├── project/         # K4: Organization
└── vendor/          # External skills

Det dvalende scope-mønster

Et af vores mest kraftfulde mønstre er “adopteret-men-ikke-indlæst”-skills. Vi kalder disse dvalende scopes.

Overvej scientific computing-skills fra k-dense-scientific-repositoriet. Vi har adopteret 120+ skills, der dækker bioinformatik, kemi, kvantecomputing og klinisk informatik. Men de fleste af vores agenter har ikke brug for molekylær docking eller genekspressionsanalyse.

I stedet for at indlæse alle 120 skills i hver agent (hvilket oppuster kontekstvinduer), gør vi følgende:

Vi adopterer skills med et specifikt scope (f.eks. bioinformatics)
Vi holder dem dvalende - registreret, men ikke indlæst
Vi aktiverer dem kun, når en agent erklærer det scope

# In scopes.yaml - dormant scope
bioinformatics:
  description: "Bioinformatics and genomics"
  primary_skills: []  # Empty - skills exist but aren't loaded

# When an agent needs bioinformatics:
# Agent YAML
scopes: [research, bioinformatics]  # Now loads bioinformatics skills

Dette mønster lader os have 466 skills i registret, mens typiske agenter kun indlæser 40-60 relevante.

Skill-typer

Skills kommer i tre kognitive mønstre:

Workflow

Ordnede procedurelle trin: “1. Gør X, 2. Så Y, 3. Til sidst Z”

type: workflow
# Examples: schema-migration-workflow, mining-session-workflow

Discipline

Regler for adfærd: “Altid X”, “Aldrig Y”, “Foretræk Z”

type: discipline
# Examples: test-first-discipline, evidence-based-completion

Checklist

Verificeringskriterier: “Bekræft X”, “Verificér Y”, “Tjek Z”

type: checklist
# Examples: auth-validation-checklist, secrets-audit-checklist

Kvalitetsgates

Enhver skill skal bestå validering, før den shippes:

validation:
  file_exists: true           # Skill file at declared path
  frontmatter_valid: true     # Frontmatter parses correctly
  sections_complete: true     # Expected sections present
  tools_registered: true      # Declared tools exist in registry

Beskrivelser skal være 50-400 tegn med udløsningsfraser (“Use when…”, “When you need…”), så Claude Code ved, hvornår den skal foreslå dem.

Vi validerer løbende:

uv run orkestra validate --show-warnings

Leverandørøkosystemet

Vores 373 leverandør-skills kommer fra:

Leverandør	Skills	Domæne
AWS Agent	19	Cloud-tjenester
Anthropic	12	Dokumentgenerering
Cloudflare	8	Edge computing
Supabase	5	Database
k-dense	100+	Scientific computing
silvainfm	4	Data science
Java Developer Kit	45+	Spring/Java
Vercel	1	Browserautomatisering

Hver leverandørrod erklæres i metadata.yaml:

vendor_roots:
  - path: vendor/aws-agent-skills
    provider: aws
  - path: vendor/k-dense-scientific/scientific-skills
    provider: k-dense
  - path: vendor/supabase-skills
    provider: supabase

Når orkestra sync kører, symlinkes leverandør-skills ind i .claude/skills/vendor/ med deres leverandørnavnerum.

Hvad vi har lært

Selektivitet betaler sig. Det er fristende at adoptere alt, der ser nyttigt ud. Men hver skill koster tokens. Med 2.834 gennemsnitlige tokens pr. skill går bloat hurtigt ud over ydeevnen. Vores adoptionsrate på 13% holder agenter slanke.

Struktur muliggør discovery. K-lagsystemet er ikke bare organisering - det handler om portabilitet. K0-skills kan genbruges hvor som helst. K4-skills er bevidst projektspecifikke. Denne klarhed hjælper både mennesker og agenter med at finde det, de har brug for.

Dvalende scopes skalerer. Man kan adoptere hundredvis af skills uden at indlæse dem alle. Scopes lader dig bygge et omfattende register, samtidig med at individuelle agenters kontekstvinduer forbliver håndterbare.

Modifikation ved adoption er essentiel. Rå leverandør-skills passer sjældent til ens system. Indarbejdelsesprocessen - tilføjelse af metadata, tildeling af lag, berigelse af tags - får eksterne skills til at fungere internt.

Mining er kontinuerlig. Tallet 3.500 bliver ved med at vokse. Nye leverandørrepositorier dukker op. Community-mønstre opstår. Interne arbejdsgange tager form. Løkken stopper aldrig.

Hvad er det næste?

Vi arbejder på flere forbedringer:

Automatiseret gap-detektion: Advarsel når almindelige agentfejl kunne løses af en ikke-adopteret skill
Skill-udfasningsarbejdsgange: Formel proces til at pensionere skills, der er overflødiggjort eller ubrugte
Cross-skill-afhængigheder: Eksplicit erklæring af skill-forudsætninger
Brugsanalyser: Spor hvilke skills agenter rent faktisk påkalder vs. bare indlæser

Skill-mining-løkken er infrastruktur. Det er ikke glamourøst. Men det er det, der får 41 agenter til at fungere sammenhængende med 466 kapabiliteter, samtidig med at de holder sig inden for kontekstgrænserne.

Det er historien om, hvordan 3.500 bliver til 466. Ikke ved at ignorere 3.000 - men ved at evaluere dem systematisk og kun adoptere det, der virker.

Vil du se skill-systemet i aktion? Tjek uv run orkestra skills list ud for at udforske vores nuværende register.

Gradvis visning: CLI-vinduer ind i agentsystemer

Tue, 20 Jan 2026 00:00:00 GMT

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (januar 2026). Se vores team-side for aktuelle tal.

Agentsystemer er uigennemsigtige af design. De træffer beslutninger, kalder værktøjer og koordinerer arbejde på tværs af snesevis af specialister. Men når noget går galt — eller når du blot vil forstå, hvad der sker — hvor kigger du så?

Svaret er gradvis visning: en lagdelt grænseflade, der afslører præcis så meget kompleksitet, som du har brug for, præcis når du har brug for det.

Uigennemsigtighedsproblemet

Et moderne agent-orkestreringssystem kan have:

40+ specialiserede agenter, hver med distinkte kapabiliteter
700+ skills, der spænder over intern automatisering og leverandørintegrationer
470+ arkitektoniske beslutninger, der former adfærd
Snesevis af MCP-værktøjsservere, der leverer eksterne kapabiliteter

Denne kompleksitet er tilsigtet. Agenter har brug for adgang til rig kontekst — domæneviden, kodeintelligens, databaseskemaer — for at træffe gode beslutninger. Men den samme rigdom skaber et synlighedsproblem.

Hvordan ved du, hvilken agent der håndterer databasemigreringer? Hvilke beslutninger formede søgesystemets rangeringsadfærd? Hvilke værktøjer har arkitekturrådgiveren adgang til?

Uden struktureret adgang er du henvist til at læse kildekode eller håbe, at dokumentationen er ajour.

Gradvis visning som arkitektur

Gradvis visning er ikke bare et UI-mønster. Det er et arkitektonisk princip: organisér information i lag, hvert dybere end det sidste, så brugere kan stoppe på det niveau, der besvarer deres spørgsmål.

For agentsystemer oversættes det til CLI-kommandoer i stigende dybder:

Niveau	Kommando	Spørgsmål, der besvares
1	`orkestra system status`	Er alt sundt?
2	`orkestra agents list`	Hvilke agenter findes der?
3	`orkestra agents info <name>`	Hvad gør denne agent?
4	`orkestra decisions search`	Hvorfor fungerer det på denne måde?
5	Maguyva MCP-værktøjer	Vis mig koden.

Hvert niveau besvarer et naturligt opfølgende spørgsmål. Du behøver sjældent at springe direkte til niveau 5.

Niveau 1: Systemsundhed

Det første spørgsmål er altid: virker alt?

$ orkestra system status

{
  "agents": 40,
  "skills_internal": 466,
  "skills_vendor": 240,
  "skills_total": 706,
  "commands": 17
}

Én kommando. Fire tal. Nok til at vide, at systemet er konfigureret, og at registrene indeholder data.

Hvis et agentantal falder uventet, eller skills ikke kan indlæses, ser du det her først. Ingen log-dykning nødvendig.

Niveau 2: Agentoversigt

Når du ved, at systemet er sundt, er det næste spørgsmål: hvad er tilgængeligt?

$ orkestra agents list

Dette returnerer strukturerede data — agentnavne, beskrivelser, modelpræferencer, domænedækning. Outputtet er JSON som standard, hvilket gør det nemt at pipe ind i jq til filtrering:

$ orkestra agents list | jq '.agents[] | select(.model == "opus") | .name'

Vil du have agenter, der håndterer databasearbejde? Søgekommandoen indsnævrer det:

$ orkestra agents search "database"

Dette skanner navne, beskrivelser og kapabiliteter. Du finder den rette specialist uden at læse 40 agentdefinitioner.

Niveau 3: Agenten i detaljer

Fandt du en agent, der ser relevant ud? info-kommandoen afslører alt:

$ orkestra agents info architecture-advisor

Outputtet inkluderer:

Metadata: Navn, kategori, modelpræference, beskrivelse
Domæner: Hvilke videnområder denne agent dækker
Identitet: Karaktertræk (architect, strategist, knowledge-architect)
Værktøjsguider: Hvilken værktøjsdokumentation der injiceres i konteksten
Værktøjer: Den fulde liste af MCP-værktøjer, denne agent har adgang til

Her er et udpluk af, hvad du ser:

{
  "metadata": {
    "name": "architecture-advisor",
    "model": "opus",
    "description": "Strategic decision-making and architectural guidance..."
  },
  "domains": [
    "product",
    "development/architecture",
    "meta/strategy"
  ],
  "tools": {
    "mcp_tools": [
      "mcp__maguyva__intelligent_search",
      "mcp__maguyva__analyze_dependencies",
      "mcp__supabase__execute_sql",
      ...
    ]
  }
}

Dette fortæller dig præcis, hvad agenten kan gøre. Ingen kildekode nødvendig.

Niveau 4: Beslutningsarkæologi

Agenter opfører sig i henhold til dokumenterede beslutninger. Når du har brug for at forstå hvorfor noget fungerer på en bestemt måde, er beslutningsregistret den autoritative kilde.

$ orkestra decisions search "agent"

Dette returnerer matchende arkitektoniske beslutninger:

{
  "results": [
    {
      "id": "DEC-SR-049",
      "title": "AI-Agent-First Defaults with Graph Intelligence",
      "domain": "search",
      "status": "active"
    }
  ]
}

Hver beslutning har fuld proveniens — hvornår den blev truffet, hvorfor, hvilke afvejninger der blev overvejet, hvilke commits der implementerede den:

$ orkestra decisions info DEC-SR-049

{
  "id": "DEC-SR-049",
  "title": "AI-Agent-First Defaults with Graph Intelligence",
  "summary": "Changes default values for search tools to AI-agent-optimal behavior...",
  "rationale": [
    "AI agents work better with pre-ranked, importance-weighted results",
    "Graph metrics already computed by pipeline - leverage them",
    "Community context helps agents understand feature scope in single query"
  ],
  "source_commits": [
    {
      "sha": "156a880d05eae295669ef7c194b039023f245511",
      "message": "feat(maguyva): enable boost_by_importance..."
    }
  ]
}

Dette er arkitektonisk dokumentation, der forbliver ajour, fordi den er minet fra commits, ikke manuelt vedligeholdt.

Niveau 5: Direkte kodeintelligens

Når du har brug for at se den faktiske implementering — ikke metadata om den — giver Maguyvas MCP-værktøjer direkte adgang.

Indefra en agentsession:

mcp__maguyva__intelligent_search
  query: "agent context loading"

Dette auto-router på tværs af semantisk, tekst- og AST-søgning for at finde relevant kode. For specifikke symboler:

mcp__maguyva__find_symbol
  symbol_name: "load_agent_context"

For afhængighedsanalyse:

mcp__maguyva__analyze_dependencies
  target: "packages/orchestration/core/agents.py"

Det her er ikke bare grep-erstatninger. De er baseret på grafen, semantisk indekserede og integrerede med den samme kodeintelligens, der driver agenterne selv.

Samlet søgning på tværs af registre

Nogle gange ved du ikke, hvilket register der har svaret. Den samlede søgning spænder over alt:

$ orkestra search "database" --summary

{
  "query": "database",
  "total": 254,
  "counts": {
    "agents": 40,
    "skills": 59,
    "decisions": 476,
    "truths": 2,
    "packages": 1
  }
}

254 træffere på tværs af fem registre. Sammendraget fortæller dig, hvor du skal dykke ned. Fjern --summary for detaljerede resultater, eller tilføj --limit 5 for at holde outputtet håndterbart.

Hvorfor det betyder noget

Gradvis visning handler ikke kun om bekvemmelighed. Det ændrer, hvordan du interagerer med komplekse systemer.

Fejlfinding bliver håndterbar. Når en agent træffer en uventet beslutning, grepper du ikke gennem logs. Du tjekker, hvilke værktøjer den har adgang til (agents info), hvilke beslutninger der former dens adfærd (decisions search), og sporer implementeringen, hvis nødvendigt (intelligent_search).

Onboarding accelererer. Nye teammedlemmer behøver ikke at læse hele kodebasen. De starter med system status, udforsker med agents list, og går kun dybere, når de støder på noget, de ikke forstår.

Dokumentation forbliver ajour. Fordi CLI’en læser fra de samme registre, der konfigurerer agenterne, er outputtet altid præcist. Der er ingen uoverensstemmelse mellem, hvad dokumentationen siger, og hvad systemet gør.

CLI’en som grænseflade

Vi kunne have bygget et webdashboard. Vi kunne have skrevet omfattende dokumentation. I stedet byggede vi en CLI, der læser fra den autoritative kilde.

CLI’en har fordele:

Sammensætbar: Pipe output gennem jq, integrér med scripts
Scriptbar: Automatisér tjek, generér rapporter
Hurtig: Ingen sideindlæsninger, ingen godkendelsesflows
Præcis: Læser den faktiske konfiguration, ikke en cachet repræsentation

For systemer, hvor korrekthed betyder mere end æstetik, vinder CLI’en.

Byg din egen gradvise visning

Hvis du bygger agentsystemer, så overvej, hvordan brugere vil inspicere dem:

Start med sundhedstjek. Én kommando, der fortæller dig, om tingene fungerer.
Tilbyd oversigter. List hvad der findes, før du forklarer, hvad det gør.
Muliggør målrettede forespørgsler. Søgning slår gennemgang i stor skala.
Eksponér proveniens. Lad brugere spore beslutninger til deres oprindelse.
Forbind til kodeintelligens. I sidste ende har brugere brug for at se implementeringen.

Hvert lag besvarer et opfølgende spørgsmål. Byg dem i frekvensrækkefølge — de fleste brugere stopper ved lag 2 eller 3. Kun avancerede brugere når lag 5.

Målet er ikke at eksponere alt. Det er at eksponere præcis det, der er nødvendigt, præcis når det er nødvendigt. Det er gradvis visning anvendt på agentarkitektur.

Ground Truths: Forankring af AI-agenter i virkeligheden

Tue, 13 Jan 2026 00:00:00 GMT

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (januar 2026). Se vores team-side for aktuelle tal.

AI-agenter er bemærkelsesværdigt dygtige. De kan ræsonnere, syntetisere og generere. Men de har en fundamental svaghed: de finder på ting. Ikke ondsindet, men selvsikkert. En agent kan finde på API-parametre, der ikke findes, referere til konfigurationer, der aldrig blev defineret, eller anvende mønstre fra sine træningsdata, der modsiger din faktiske arkitektur.

Den sædvanlige løsning er “giv agenten mere kontekst.” Men kontekst kan være modstridende. Dokumentationen kommer ud af trit med implementeringen. Kommentarer lyver. Selv kode kan vildlede, når den læses uden forståelse af hensigten.

Vi havde brug for noget mere eksplicit. Noget, der ikke kunne ignoreres eller fejlfortolkes. Noget, der ville forankre agenter i en verificerbar virkelighed.

Vi kalder dem Ground Truths.

Hvad er en Ground Truth?

En Ground Truth er en eksplicit, versioneret faktapåstand, som agenter skal respektere. Det er ikke dokumentation. Det er ikke en kommentar. Det er en førsteklasses entitet i systemet med:

En unik identifikator (som GT-MAG-015 eller GT-MAG-036)
En livscyklusstatus (current, tentative eller deprecated)
Et scope (platformbredt, pakkespecifikt eller domænebundet)
Evidens (filstier, URL’er eller referencer, der beviser påstanden)
Agentvejledning (eksplicitte gør/undgå-instruktioner)

Her er et eksempel fra vores Maguyva kodeintelligensplatform:

- id: GT-MAG-015
  status: current
  scope: package
  statement: |
    Fuzzy symbol matching is opt-in via `find_similar=true`.
    Default behavior returns empty results for non-existent symbols;
    `exact_match=true` enforces strict matching and disables all fuzzy fallbacks.
  rationale: |
    Deterministic defaults prevent agents from receiving misleading results.
    Typos should fail explicitly rather than silently returning unrelated symbols.
  evidence:
    - "packages/maguyva/server/src/maguyva/services/code_analysis_service.py"
    - "packages/maguyva/server/docs/quick_reference/parameters.md"
  last_verified: "2026-01-25"
  tags:
    - product
    - ai_first
    - principle

Dette er ikke prosa. Det er en kontrakt. Når en agent støder på denne Ground Truth, ved den:

Standarden er deterministisk (tomme resultater, ikke gæt baseret på omtrentlige match)
Der findes specifikke parametre (find_similar, exact_match) med veldefineret adfærd
Evidens findes i specifikke filer, der kan verificeres
Påstanden blev verificeret på en specifik dato

Anatomien af et Ground Truth Registry

Ground Truths lever i YAML-registre under ai_assets/reference/ground_truths.yaml. Hver pakke eller hvert domæne kan have sit eget register. Strukturen er:

metadata:
  title: "Maguyva Ground Truths"
  summary: "Foundational constraints and principles that guide Maguyva."
  last_updated: "2026-01-26"
  owner: "maguyva"
  render:
    include_statuses: [current, tentative]
    show_deprecated: true
    groups:
      - title: "Product Principles"
        tags: [product, principle, brand]
      - title: "Architecture & Boundaries"
        tags: [architecture, boundaries, cqrs]

statements:
  - id: GT-MAG-001
    status: current
    scope: package
    statement: "Maguyva is read-only with respect to user repositories..."
    ...

Registret inkluderer metadata om selve samlingen, render-konfiguration til dokumentationsgenerering og selve påstandene. Hver påstand følger et strengt skema valideret af Pydantic-modeller:

class GroundTruthStatement(BaseModel):
    id: str
    status: GTStatus  # current, tentative, deprecated
    source: GTSource | None  # claude-code, orkestra, discipline
    scope: GTScope  # platform, package, domain
    statement: str
    rationale: str | None
    evidence: list[str]
    last_verified: str | None
    tags: list[str]
    agent_guidance: AgentGuidance | None

Sådan tilgår agenter Ground Truths

Ground Truths eksponeres gennem flere kanaler:

1. Renderet dokumentation

orkestra sync-kommandoen omdanner YAML-registre til læsbar markdown:

uv run orkestra sync

Dette genererer GROUND_TRUTHS.md-filer, der inkluderes i agentkonteksten. Det renderede output grupperer påstande efter status og kategori:

## Current
### Product Principles
- Maguyva is read-only with respect to user repositories... (GT-MAG-001)
- Design tool responses for AI agents first... (GT-MAG-009)

### Architecture & Boundaries
- Pipeline and Maguyva boundaries are intentional... (GT-MAG-006)

2. CLI-søgning

Agenter med shell-adgang kan søge i Ground Truths programmatisk:

uv run orkestra registry truths search "embedding"
uv run orkestra registry truths search --tag security
uv run orkestra registry truths list --status current

Søgefunktionen scorer træffere på tværs af flere felter med vægtet relevans:

def truth_fields(gt: GroundTruthStatement) -> list[FieldSpec]:
    return [
        FieldSpec(name="id", weight=6, values=[gt.id]),
        FieldSpec(name="statement", weight=5, values=[gt.statement]),
        FieldSpec(name="rationale", weight=4, values=[gt.rationale] if gt.rationale else []),
        FieldSpec(name="tags", weight=3, values=gt.tags or []),
        FieldSpec(name="evidence", weight=2, values=gt.evidence or []),
    ]

3. Kontekstkomposition

Når agenter renderes fra YAML-definitioner, kan deres kontekst referere til Ground Truth-registre:

context_composition:
  domain_knowledge:
    - packages/maguyva/ai_assets/reference/ground_truths.yaml

Dette sikrer, at relevante Ground Truths indlæses, før agenten begynder arbejdet.

Kategorier af Ground Truths

Ser man på tværs af vores registre, klynger Ground Truths sig i flere mønstre:

Produktprincipper

Begrænsninger for, hvad produktet er, og hvad det ikke er:

“Maguyva har kun læseadgang til brugernes repositorier; det eneste aktiv, der ikke kan genskabes, er cachen med betalte embeddings.” (GT-MAG-001)

Arkitekturgrænser

Hvor ansvaret ligger, og hvorfor:

“Grænserne mellem Pipeline og Maguyva er tilsigtede: pipeline kan genbruges, Maguyva indeholder kodespecifik logik, og CQRS adskiller pipeline-stadiernes skrivninger fra serverens læsninger.” (GT-MAG-006)

Anti-hallucinationsregler

Eksplicitte mandater, der holder værktøjskontrakter deterministiske i stedet for udledte:

“Omtrentlig symbolmatching skal vælges eksplicit via find_similar=true. Standardadfærden returnerer tomme resultater for symboler, der ikke findes; exact_match=true håndhæver eksakt matching og deaktiverer alle alternativer med omtrentlige match.” (GT-MAG-015)

Kvalitetsgates

Standarder, der skal opretholdes:

“Ændringer i fælles infrastruktur (post_filters.py, relationsudtrækkere, fælles handlere) SKAL valideres mod ALLE understøttede sprog ved at generere hele manifestet før commit. Validering af ét sprog er utilstrækkelig for fælles kode.” (GT-MAG-036)

Kodemønstre

Implementeringskrav:

“Brug asyncio.to_thread() til CPU-bundet arbejde i asynkrone kontekster; det udfasede loop.run_in_executor()-mønster bør ikke bruges i ny kode.” (GT-MAG-018)

Livscyklussen for en Ground Truth

Ground Truths er ikke statiske. De udvikler sig gennem en defineret livscyklus:

Tentative

En foreslået sandhed under evaluering. Påstanden registreres, men kan ændre sig:

- id: GT-MAG-044
  status: tentative
  statement: |
    get_file with include_metadata=false may still return metadata in the
    response because middleware may re-inject it for AI agent disambiguation.

Current

En verificeret sandhed, som agenter skal respektere. Evidens er blevet valideret:

- id: GT-MAG-017
  status: current
  last_verified: "2026-01-26"
  evidence:
    - "packages/maguyva/server/src/maguyva/services/supabase.py"

Deprecated

En sandhed, der ikke længere gælder. Bevaret som historisk reference med en henvisning til, hvad der erstattede den:

- id: GT-MAG-099
  status: deprecated
  superseded_by: GT-MAG-015
  notes: "Replaced when we moved to explicit matching behavior"

Hvorfor ikke bare dokumentation?

Dokumentation tjener et andet formål. Den forklarer. Den underviser. Den kan være vag, kan bruge kvalifikatorer som “generelt” eller “typisk.”

Ground Truths kan ikke være vage. De er påstande. De gælder enten, eller også gør de ikke.

Overvej forskellen:

Dokumentation: “API’en returnerer generelt tomme resultater, når et symbol ikke findes, selvom fuzzy matching kan være aktiveret i nogle konfigurationer.”

Ground Truth: “Standardadfærden returnerer tomme resultater for symboler, der ikke findes; exact_match=true håndhæver eksakt matching og deaktiverer alle alternativer med omtrentlige match.”

Den første er nyttig for mennesker, der lærer systemet at kende. Den anden er handlingsorienteret for agenter, der træffer beslutninger.

Agentvejledning: Gør og undgå

Nogle Ground Truths inkluderer eksplicit agentvejledning:

- id: GT-MAG-022
  statement: |
    Accuracy fixes must happen at extraction time via production code,
    never via validator filters.
  agent_guidance:
    do:
      - "Fix extraction bugs in YAML config, handlers, or tree-sitter queries"
      - "Add test cases at the layer where the fix lives"
    avoid:
      - "Adding validator filters to mask production bugs"
      - "Creating test-only workarounds for extraction issues"

Dette fjerner tvetydighed. En agent, der læser dette, ved ikke kun, hvad der er sandt, men også hvilke handlinger den sandhed medfører.

Verificering og vedligeholdelse

Ground Truths kræver vedligeholdelse. Vi sporer:

last_verified: Hvornår nogen bekræftede, at påstanden stadig holder
evidence: Filer, der beviser påstanden (kan tjekkes for eksistens)
source: Hvor sandheden stammer fra (CLI-inspektion, arkitekturgennemgang, læring efter hændelser)

En Ground Truth med forældede verificeringsdatoer eller ødelagte evidenslinks er et signal om at undersøge sagen. Enten er sandheden stadig gyldig og trænger til genverificering, eller også har virkeligheden ændret sig, og sandheden trænger til opdatering.

Reelle eksempler fra produktion

Sikkerhedsgrænse

- id: GT-MAG-014
  statement: |
    Maguyva queries are search patterns, not executable code.
    SQL injection prevention is handled by PostgREST parameterization;
    application-layer SQL keyword blocking must never be added.
  rationale: |
    Blocking SQL keywords breaks legitimate code search. Users search FOR
    code containing patterns like 'DROP TABLE', they don't execute them.

Denne Ground Truth forhindrer en klasse af misforståede “sikkerhedsforbedringer”, der ville ødelægge produktet.

Nøjagtighed ved udtrækningstidspunktet

- id: GT-MAG-022
  statement: |
    Accuracy fixes must happen at extraction time via production code
    (YAML config, handlers, queries), never via validator filters.
  rationale: |
    Validator filters only run during tests. They can hide extractor bugs
    while production responses remain wrong.

Dette kom fra en smertefuld erfaring. Agenter plejede at lappe fejlende sprogpakker ved at tilføje filtre, som kun virkede i validatoren og fik testresultaterne til at se bedre ud, mens den live Maguyva-udtrækker stadig udsendte de forkerte kanter. Reglen tvinger rettelser tilbage ind på den rigtige sti: YAML-config, forespørgsler eller handlere.

Multi-lags filtrering

- id: GT-MAG-023
  statement: |
    Language engine uses three-tier filtering: external_method_patterns
    (builtins/stdlib), allowlists (legitimate idioms), and expected_call_targets
    (validation-time deduplication). Each tier serves a distinct purpose.
  rationale: |
    Conflating filter purposes leads to either over-filtering (missing real
    relationships) or under-filtering (noise).

Dette forhindrer agenter i at tilføje filtre det forkerte sted, en almindelig fejl, der forårsagede nøjagtighedsregressioner.

Integration med orkestreringssystemet

Ground Truths er ét lag i et bredere kontekstsystem:

Arkitektoniske beslutninger (ADR’er) - Registrerer hvorfor vi valgte tilgang A frem for B
Ground Truths - Angiver hvad der definitivt er sandt lige nu
Domænemønstre - Beskriver hvordan man gør tingene korrekt
Antimønstre - Beskriver hvad man skal undgå, og hvorfor

En agent, der arbejder i systemet, har adgang til alle fire. Ground Truths giver det faktuelle anker, mens beslutninger forklarer historien, mønstre guider implementeringen, og antimønstre advarer om faldgruber.

Måling af effekten

Siden vi introducerede Ground Truths, har vi observeret:

Færre “ret den hallucinerede rettelse”-cyklusser
Mere selvsikker agentbeslutningstagning, når fakta er klare
Bedre PR-gennemgange, fordi forventninger er eksplicitte
Kortere onboarding-tid for nye agenter (og mennesker)

Investeringen i at vedligeholde Ground Truths betaler sig i form af mindre debugging og klarere systemgrænser.

Kom i gang

For at tilføje en Ground Truth til dit system:

Opret en ground_truths.yaml i din pakkes ai_assets/reference/-mappe
Definér metadata og render-konfiguration
Tilføj påstande, der følger skemaet
Kør uv run orkestra sync for at generere dokumentation
Inkludér registret i agentens kontekstkomposition

Start med de fakta, der skaber mest forvirring, eller de begrænsninger, der overtrædes oftest. Det er dine mest værdifulde Ground Truths.

Konklusion

AI-agenter vil hallucinere. Det er deres natur. Men vi kan skabe miljøer, hvor hallucination er begrænset, hvor visse fakta er ikke-forhandlelige, hvor agenter kan tjekke deres antagelser mod verificeret virkelighed.

Ground Truths er ikke en komplet løsning. De kræver vedligeholdelse. De kan blive forældede. De tilføjer overhead til udviklingsprocessen.

Men de giver noget værdifuldt: et delt ordforråd af fakta, som både mennesker og agenter kan stole på. I en verden, hvor agenter i stigende grad deltager i softwareudvikling, bliver det delte fundament essentielt.

Alternativet er endeløse cyklusser af agenter, der begår selvsikre fejl, og mennesker, der retter dem. Ground Truths bryder den cyklus ved at gøre rettelserne eksplicitte og holdbare.

Dine agenter fortjener at vide, hvad der er sandt. Fortæl dem det.

Orkestra: Orkestrering af AI-agenter i stor skala

Tue, 06 Jan 2026 00:00:00 GMT

Tallene i dette indlæg afspejler systemet på udgivelsestidspunktet (januar 2026). Se vores team-side for aktuelle tal.

Da vi begyndte at bygge med Claude Code, stødte vi på et problem, som ethvert team, der bruger AI-kodeassistenter, før eller siden møder: én enkelt agent kan ikke gøre alt godt.

Man kan prompte en agent til at være databasespecialist. Eller sikkerhedsrevisor. Eller frontend-ingeniør. Men i det øjeblik man beder den om at være alle tre på én gang, lider kvaliteten. Konteksten udvandes. Instruktioner kolliderer. Agenten bliver en generalist, der er middelmådig til alt.

Så vi byggede Orkestra.

Hvad er Orkestra?

Orkestra er et agent-orkestreringssystem til Claude Code og lignende AI-kodeværktøjer. Det koordinerer flere specialiserede agenter, hver med særskilt ekspertise, under én orkestrator, der dirigerer arbejde til den rette specialist.

Tænk på det som et vikarbureau for AI-agenter. Orkestratoren modtager en opgave, identificerer hvilken specialist der bør håndtere den, og delegerer med den rette kontekst. Når arbejdet er udført, flyder resultaterne tilbage til orkestratoren til syntese.

Tallene fortæller historien:

Komponent	Antal
Specialistagenter	46
Genanvendelige skills	466
Identitetsarketyper	27
Mindsets	11
Kommunikationsstile	10
Vidensdomæner	21

Karaktersystemet: D&D for agenter

Den centrale indsigt bag Orkestra er, at agentadfærd opstår fra tre kombinerbare primitiver:

Identitet definerer hvad agenten er. En architect designer systemstrukturer. En debugger sporer fejl tilbage til rodårsager. En guardian håndhæver compliance og sikkerhedsgrænser. Vi har 27 identitetsarketyper, der kan blandes.

Mindset definerer hvordan agenten tænker. Et analytical mindset forankrer påstande i evidens og kvantificerer usikkerhed. Et skeptical mindset udfordrer antagelser og søger modbevisende evidens. Et exploratory mindset omfavner tvetydighed og prøver flere tilgange.

Style definerer hvordan agenten kommunikerer. En technical style inkluderer eksakte værdier og henviser til specifikke filer. En concise style skærer fyld væk og lægger ud med svaret. En diplomatic style balancerer ærlighed med takt.

En agent kombinerer disse primitiver:

# architecture-advisor.yaml
identity:
  - knowledge-architect
  - architect
  - strategist
mindset: analytical
style: concise

Denne komposition skaber en agent, der designer systemer (architect), forbinder viden på tværs af domæner (knowledge-architect), sætter strategisk retning (strategist), tænker i evidens og data (analytical) og kommunikerer uden fyld (concise).

Styrken ligger i den kombinatoriske eksplosion. 27 identiteter gange 11 mindsets gange 10 stile giver næsten 3.000 mulige agentpersonligheder. Men man definerer kun de kombinationer, der betyder noget for ens arbejde.

Skills: Genanvendelige kapabilitetsmoduler

Skills er den viden og de arbejdsgange, agenter kan påkalde. De følger et lagdelt system baseret på scope:

Lag	Navn	Scope	Eksempel
K0	Foundations	Universel metodologi	Test-first-disciplin, evidensbaseret færdiggørelse
K1	Identities	Rollebaserede arbejdsgange	CLI-grænsefladestandarder, performance playbook
K2	Domains	Domænespecifik viden	Databasemigreringsmønstre, autentificeringsvalidering
K3	Stacks	Teknologispecifik	Cloudflare-deployment, Supabase-drift
K4	Project	Kun denne kodebase	Projektspecifikke arbejdsgange og konventioner

Skills er lazy-loaded. En agent ser skill-navne og -beskrivelser ved opstart, men fuldt skill-indhold indlæses først, når det udløses. Det holder konteksten slank, samtidig med at det gør hundredvis af skills opdagelige.

Hver skill inkluderer:

Klare udløsningsbetingelser (“Use when migrating database schemas”)
Trin-for-trin-vejledning
Tilladte værktøjer til arbejdsgangen
Succeskriterier og fejlgenopretningsstier

De 466 skills i vores register dækker alt fra git worktree-isolation til web research-arbejdsgange til deployment health-validering.

Hvorfor orkestrering betyder noget

Enkelt-agent-arkitekturer rammer hurtigt en mur:

Kontekstudvanding. Et 200k-token kontekstvindue lyder stort, indtil man indlæser databaseskemaer, API-dokumentation, testfixtures og domæneviden. Specialister kan arbejde med målrettet kontekst.

Instruktionskonflikter. At bede en agent om at være “grundig, men hurtig” og “verificere alt, men ikke overengineere” skaber spænding. Specialister løser dette ved at have klart scope.

Ekspertisedybde. En generalist-agent ved lidt om alt. En specialistagent, sammensat med den rette identitet og de rette skills, kender sit domæne dybt.

Orkestra implementerer flad orkestrering: én orkestrator koordinerer flere specialister. Specialister kan ikke spawne sub-specialister. Det forhindrer kompleksitetseksplosion, samtidig med at det muliggør parallelt arbejde.

Orkestratoren har adgang til 2,2 millioner tokens effektiv kapacitet: sit eget 200k-vindue plus 10 samtidige subagenter med 200k hver. Arbejde, der ville udtømme én enkelt agent, kører komfortabelt på tværs af flåden.

Rendering-pipelinen

Agentdefinitioner lever i YAML. Claude Code læser Markdown. Orkestra bygger bro over dette hul med en deterministisk rendering-pipeline:

YAML Registries → Jinja Templates → .claude/agents/*.md

Operatører redigerer YAML-kilden. Kør orkestra sync. Det renderede Markdown gemmes i .claude/agents/. Claude Code opfanger ændringerne.

Denne adskillelse betjener forskellige målgrupper:

YAML-kilden inkluderer livscyklusmetadata, tags, valideringsregler og udfasningsnoter til værktøjerne
Renderet Markdown inkluderer kun det, modellen har brug for: beskrivelse, værktøjer, skills og adfærdsvejledning

Pipelinen komponerer identiteter, mindsets, stile og skills til én sammenhængende prompt. En architect-analytical-concise-agent får en meget anderledes system prompt end en debugger-skeptical-technical-agent, selv hvis de deler nogle underliggende skills.

Domæneviden: Fire-fil-mønsteret

Ethvert vidensdomæne følger en konsistent struktur:

domain-name/
  decisions.md      # Key choices, rationale, consequences
  patterns.md       # Step-by-step guidance and examples
  anti-patterns.md  # Failure modes and remediation
  evolution.md      # Dated log of changes

Denne struktur betjener agentens kontekstindlæsning. En agent, der arbejder med autentificering, indlæser authentication/patterns.md til vejledning og authentication/anti-patterns.md for at undgå kendte faldgruber. Filerne er dimensioneret til effektiv kontekstindlæsning: fokuserede nok til at være nyttige, omfattende nok til at være autoritative.

Vi vedligeholder 21 domæner på øverste niveau, herunder analytics, autentificering, data science, infrastruktur, machine learning, performance, sikkerhed og mere. Hvert domæne kan have underdomæner for finere granularitet.

Værdier: Operativsystemet

Alle agenter deler et grundlæggende lag af værdier, der definerer, hvordan de opererer:

Enkelhed først. Brug den simpleste løsning, der virker. Tilføj kun kompleksitet, når det er berettiget.

Ret rodårsager. Nøjes aldrig med at skjule fejl. Hvis en pipeline fejler, debug pipelinen. Hvis en test fejler, ret koden eller testen.

Evidensbaseret. Mærk påstande som “verificeret” (med benchmarks) eller “estimeret” (med antagelser). Et opdaget mønster er ikke det samme som et bekræftet problem.

Kontekstøkonomi. MCP-værktøjer koster 0,1% af konteksten. Fillæsninger koster 2% hver. Anvend domæneekspertise, før koden udforskes.

Disse værdier forplanter sig til enhver specialist gennem rendering-pipelinen. En agent kan ikke omgå dem gennem komposition.

CLI: Kontrolplanet

Orkestra leveres med en CLI til at administrere agentøkosystemet:

# Discovery
orkestra agents search "database"
orkestra agents info database-architect

# Validation
orkestra validate --show-warnings

# Rendering
orkestra sync --dry-run
orkestra sync

# Skills
orkestra skills list
orkestra skills info schema-migration-workflow

# Decisions
orkestra decisions search "authentication"

CLI’en er den autoritative kilde til, hvilke agenter der findes, hvilke skills de har, og om systemet er sundt. Den kører validering før synkronisering for at fange problemer tidligt.

Overvejelser om open source

Vi byggede Orkestra for at løse vores eget problem: at koordinere AI-agenter i stor skala for en kompleks kodebase. De mønstre, vi opdagede, er ikke specifikke for vores domæne.

Karakterkompositionssystemet (identitet + mindset + style) gælder for ethvert team, der definerer agentpersonligheder.

Skill-lagsystemet (K0-K4) giver en mental model til at organisere genanvendelige kapabiliteter efter scope.

Rendering-pipeline-mønsteret (YAML-kilde + templates + genererede artefakter) adskiller værktøjernes behov fra modellens brug af indholdet.

Den flade orkestreringsmodel (én koordinator, mange specialister) undgår kompleksitet, samtidig med at den muliggør parallelitet.

Hvorvidt Orkestra bliver open source, afhænger af, om disse mønstre har værdi for andre, der bygger med Claude Code. Hvis du rammer de mure, vi har beskrevet, kan arkitekturen måske hjælpe.

Hvad vi lærte

At bygge Orkestra lærte os, at orkestrering ikke handler om at gøre agenter klogere. Det handler om at gøre dem mere fokuserede.

En enkelt agent med perfekte instruktioner løber stadig tør for kontekst. En enkelt agent med alle skills bliver stadig forvirret over, hvilken der skal anvendes. En enkelt agent, der forsøger at være alt, producerer middelmådige resultater overalt.

Fyrre specialister, hver fremragende i sit domæne, koordineret af en orkestrator, der ved, hvornår den skal delegere: sådan shipper vi.

Tallene betyder mindre end arkitekturen. Man har måske brug for fem agenter eller halvtreds. Princippet forbliver: komposition frem for kapacitet, specialisering frem for generalisering, koordinering frem for individuelle heltegerninger.

Orkestra driver agentøkosystemet bag Maguyva, vores kodeintelligensplatform. Vil du vide mere? Kontakt teamet.