ARD (Agentic Resource Discovery)

Sådan fungerer ARD teknisk

ARD er ikke en ny transportprotokol, og den erstatter ikke de standarder, agenter allerede bruger til at tale med værktøjer og med hinanden. Den lægger sig som et opdagelseslag ovenpå dem. Under ARD ligger stadig MCP til forbindelsen mellem agent og værktøj, A2A mellem agent og agent, samt OpenAPI-værktøjer og andre kataloger. ARD besvarer tre spørgsmål, som ingen af dem løser: hvor findes den rette kapabilitet, hvilken af dem bør agenten vælge, og hvordan verificerer den, at den er sikker at forbinde til.

Kataloger er det første byggeelement. En udbyder beskriver sine kapabiliteter i en fil ved navn ai-catalog.json og lægger den på et fast, forudsigeligt sted på sit eget domæne. Filen kan pege på MCP-servere, A2A-agenter, OpenAPI-værktøjer eller endda andre, indlejrede kataloger. Pointen med at forankre den i domænet er tillid: ejerskabet over domænet er det kryptografiske fundament for udbyderens identitet. Kan du bevise, at du kontrollerer eksempel.dk, kan en agent stole på, at kataloget på eksempel.dk faktisk kommer fra jer.

Registries er det andet. En registry er reelt en søgemaskine for det agentiske web. Den crawler og indekserer katalogerne på tværs af domæner, på samme måde som en almindelig søgemaskine indekserer websider. Hvor et katalog er den enkelte udbyders selvbeskrivelse, er en registry det sted, en agent kan spørge bredt: hvem derude kan løse den her opgave. Google, Hugging Face og andre kan hver køre deres egen registry, og en virksomhed kan køre sin egen private af slagsen.

Selve opslaget kombinerer et statisk manifest med et dynamisk API. Det statiske manifest er ai-catalog.json. Det dynamiske lag er et søge-endpoint, hvor agenten sender en forespørgsel i naturligt sprog med en POST-anmodning og får en rangeret liste tilbage. Resultaterne kommer med mere end et navn og en adresse. De bærer rigere signaler: udbyderens identitet, repræsentative eksempler på forespørgsler kapabiliteten kan håndtere, compliance-attestationer og tags. Det er de signaler, agenten bruger til at vælge den rette kandidat frem for bare den første.

Verifikation sker før forbindelsen, ikke efter. ARD lægger vægt på, at opdagelse uden verifikation blot sætter det i system at stole på fremmede. Derfor kan en udbyder vedhæfte verificerbar tillidsmetadata, som en agent eller registry kan tjekke, før den forbinder. Datapunkterne kan signeres med Ed25519 og kontrolleres mod udbyderens offentlige nøgle, og et såkaldt trust manifest er det kryptografiske lag, der beviser ægthed og kan leve op til krav som HIPAA. Rækkefølgen er det vigtige: identiteten bekræftes, før der etableres forbindelse.

Hvorfor et lag ovenpå og ikke en erstatning. En agent, der har fundet et værktøj via ARD, bruger stadig tool calling og MCP til at kalde det. ARD blander sig ikke i, hvordan kaldet foregår. Den løser kun det skridt, der ligger før første kald, det Google kalder federated pre-invocation search: en fordelt søgning efter den rette ressource, inden den overhovedet aktiveres. Den arbejdsdeling er bevidst, for den lader ARD fungere sammen med det økosystem, virksomhederne allerede har investeret i.

Problemet, ARD er født til at løse, er dobbelt. Den ene halvdel er hårdkodningen: dagens model med at skrive en MCP-servers adresse ind i en konfigurationsfil og installere værktøjer, før de bruges, knækker, når en agent skal kunne nå tusindvis af kapabiliteter ad hoc. Den anden halvdel er kontekstvinduet. Alternativet, at proppe alle værktøjsbeskrivelser ind i modellens kontekst, er begrænset af token-budgettet og giver dårlig præcision, når agenten skal vælge mellem mange lignende værktøjer. GitHubs agent finder til Copilot markedsføres netop på, at den henter de rette MCP-servere, skills, værktøjer og agenter ved kørsel og dermed undgår, at unødige ressourcer fylder konteksten op.

ARD har konkrete begrænsninger. Specifikationen blev offentliggjort som et v0.9-udkast, altså ikke en færdig standard, og formatet kan nå at ændre sig. Googles egen søgetalsmand John Mueller har offentligt sået tvivl om, hvorvidt sprogmodeller reelt kan bruge den slags selvpublicerede filer til at skelne den ene udbyder fra den anden. Og selv fortalerne indrømmer et åbent hul: at finde en agent eller et værktøj, du ikke på forhånd kender, blandt tusindvis af muligheder er stadig svært at gøre præcist. ARD er et bud på en løsning, ikke et bevis for, at problemet er løst.

Overvejer I at lade jeres AI-agenter opdage og bruge værktøjer på egen hånd, hjælper vi jer med at gøre det uden at miste kontrollen. Vi kortlægger, hvilke interne systemer og API'er der giver mening at gøre synlige for agenterne, opsætter verifikation og en privat registry, så kun godkendte ressourcer kan findes, og vi bygger den governance, der holder opdagelsen inden for jeres rammer. Vil du vide, hvor ARD og de tilstødende agentstandarder passer ind i jeres opsætning, kan du starte på vores AI-overblik eller tage en uforpligtende snak med os.

Hvad ARD gør muligt i praksis

ARD er stadig ungt, men de tidlige implementeringer fra GitHub, Hugging Face og Google viser konkret, hvad standarden åbner for i en dansk virksomhed.

Opdagelse ved kørsel (runtime discovery)
Agenten finder værktøjer i det øjeblik, den har brug for dem, i stedet for at være afhængig af, at nogen har koblet dem på i forvejen. En intern automatiseringsagent, der skal hente en kreditvurdering, kan slå op i jeres registry, finde det interne kreditværktøj og bruge det, uden at en udvikler først har hårdkodet forbindelsen. For virksomheder med snesevis af interne API'er fjerner det en stor del af den manuelle opsætning.

Søgning i naturligt sprog
Agenten beskriver, hvad den skal bruge, med almindelig tekst og får en rangeret liste tilbage. I stedet for at kende det præcise navn på et værktøj kan den spørge efter noget, der kan validere en dansk IBAN og returnere bankens navn. Det gør det muligt at bygge agenter, der ikke skal genprogrammeres, hver gang værktøjsporteføljen ændrer sig.

Samlet visning af private, leverandør- og offentlige ressourcer
Fordi den, der driver opdagelsestjenesten, styrer, hvad der kommer med i svaret, kan en virksomhed samle sit eget billede: interne ressourcer, udvalgte leverandørers ressourcer og udvalgte offentlige ressourcer i en enkelt registry. En dansk koncern kan lade sine agenter se koncernens egne værktøjer plus en håndfuld godkendte leverandører, men ikke det åbne internet. Kontrollen ligger hos den, der kører registryen.

Verifikation som en del af opslaget
Resultatet fra en registry indeholder den metadata, agenten skal bruge for at bekræfte udbyderen, før den forbinder. En indkøbsagent kan afvise enhver kandidat, der ikke kan fremvise en gyldig, domæneforankret identitet. Det er en forudsætning for overhovedet at turde lade agenter opdage ressourcer uden for jeres egen kontrol.

Compliance-signaler i resultatet
Kataloger kan bære attestationer og tags, for eksempel om et værktøj lever op til en bestemt standard. En agent i sundhedssektoren kan filtrere til kun de kapabiliteter, der er mærket HIPAA-konforme, allerede i opslaget, i stedet for at opdage det for sent. For danske virksomheder er den samme mekanisme oplagt at bruge til at markere, hvad der er GDPR-egnet.

Lavere kontekstforbrug og dermed lavere omkostning
Ved kun at hente de få relevante værktøjer ind i modellens kontekst frem for alle sammen sparer agenten tokens. Det gør hvert kald både hurtigere og billigere, og det forbedrer træfsikkerheden, når agenten skal vælge. GitHubs agent finder til Copilot bygger direkte på den pointe.

En styret indgang via Agent Registry
Google Cloud tilbyder en hostet Agent Registry som en del af sin Gemini Enterprise Agent Platform, hvor discovery kombineres med styring: globalt unikke navne, egress-politikker og fastlåsning af hvilke værktøjer og specifikationer der må bruges. For en virksomhed, der ikke selv vil bygge og drifte en registry, bliver det en færdig, styret indgang til det agentiske web.

ARD i forhold til MCP, A2A og de andre standarder

ARD er ikke det eneste forsøg på at få styr på det agentiske web, og for at forstå, hvor den passer ind, er man nødt til at se den ved siden af de standarder, den bygger ovenpå og konkurrerer med i kanten.

MCP (Model Context Protocol)
Anthropics protokol forbinder en agent med et enkelt værktøj eller en datakilde og er blevet de facto-standard for det lag, med over 18.000 offentlige MCP-servere indekseret i marts 2026. MCP overgik til Linux Foundations Agentic AI Foundation i december 2025. Men MCP løser forbindelsen, ikke opdagelsen: den fortæller en agent, hvordan den taler med en server, den allerede kender adressen på. ARD er laget, der finder den server i første omgang. De to er komplementære.

A2A (Agent-to-Agent)
Googles egen A2A-protokol lader agenter tale sammen og publicerer såkaldte Agent Cards på en fast sti, /.well-known/agent.json. Det ligner ARD på overfladen, men et Agent Card fortæller dig, hvordan du taler med en agent, du allerede kender. Det hjælper dig ikke med at finde den rette agent til en opgave blandt tusindvis. Præcis det hul er ARD bygget til at lukke.

ACP (Agent Communication Protocol)
Udviklet i AGNTCY-samarbejdet omkring Cisco og doneret til Linux Foundation i juli 2025, er ACP et REST-native alternativ til A2A til kommunikation mellem agenter. Cisco har koblet ARD sammen med sit eget AGNTCY Agent Directory, så de to lag spiller sammen. Igen ligger ACP på kommunikationslaget, mens ARD ligger på opdagelseslaget ovenover.

MCP Registry og lignende kataloger
Anthropics MCP Registry gik i preview i september 2025 og indekserer de mange tusinde MCP-servere. Forskellen på den og ARD er bredden: MCP Registry er et katalog over MCP-servere, mens ARD er tænkt fødereret og protokol-agnostisk, så det samme opslag kan finde MCP-servere, A2A-agenter og OpenAPI-værktøjer på tværs. ARD forsøger at være standarden for, hvordan alle den slags kataloger og registries taler sammen.

Agent Name Service, AGENTS.md og NANDA
Flere mindre initiativer angriber det samme problem fra hver sin vinkel. Agent Name Service er et forslag om en DNS-lignende opslagstjeneste for agenter, stadig på prototypestadiet. AGENTS.md er en enkel markdown-konvention, som Agentic AI Foundation har blåstemplet, i familie med robots.txt. Og MIT Media Labs NANDA-projekt arbejder på en indeksarkitektur for det, de kalder internettet af AI-agenter. ARD adskiller sig ved at have tung industriopbakning fra elleve store aktører fra første dag og ved eksplicit at bygge verifikation ind fra starten.

Hvor ARD er stærk, og hvor den ikke er. ARDs styrke er bredden i opbakningen og verifikationen: elleve konkurrenter, blandt andre Google, Microsoft, GitHub og Hugging Face, står bag det samme udkast, og tillid er tænkt ind fra begyndelsen frem for boltet på bagefter. Svaghederne er lige så konkrete. Det er et v0.9-udkast, ikke en ratificeret standard. Googles hostede Agent Registry var ved lanceringen fortsat måneder fra at være klar. Og den grundlæggende kritik står ved magt: det er endnu uvist, om agenter i praksis kan bruge selvpublicerede kataloger til pålideligt at skelne gode udbydere fra dårlige. ARD er det mest samlede bud indtil videre, men det er stadig et bud.