Hvilke verktøy kaller en agent for å verifisere et selskap?

Tre dekker kjernen: search_companies løser et selskapsnavn opp til det 9-sifrede organisasjonsnummeret, get_company_verification returnerer vurderingen pass, warn, fail eller unknown med registersignalene bak, og get_company_authority svarer på hvem som er registrert med rett til å signere. Hvert svar navngir kildene sine og oppgir hvor ferske dataene er, så agenten kan sitere hvor hvert faktum kom fra.

Trenger agenten en API-nøkkel?

Ikke for oppdagelse; ja for selskapsdata. En MCP-klient kan liste de tilgjengelige verktøyene uten legitimasjon, og slik finner en agent ut hva serveren tilbyr. Verktøyene som besvarer spørsmål om et bestemt navngitt selskap, krever en API-nøkkel, og nøkkelens scopes avgrenser hva agenten når. Skillet er bevisst: oppdagelse er fritt, data om reelle selskaper er sporbart.

Kan agenten handle på vurderingen automatisk?

På lesesiden, ja: den kan registrere vurderingen, flagge en leverandør eller stoppe en onboarding, for det er beslutninger i ditt eget system basert på registrerte fakta. Det den ikke kan, er å utføre bindende handlinger mot det offentlige: ingen innsending leveres, og ingenting skrives til noe offentlig register. Alt med rettsvirkning blir hos et menneske, og agentens jobb er å komme dit med dokumentasjonen ferdig samlet.

Hvordan unngår agenten å hallusinere selskapsfakta?

Ved aldri å bli bedt om å huske dem. Verifiseringsflyten ruter hvert faktaspørsmål gjennom et verktøykall som leser de autoritative registrene i det øyeblikket, og verktøyets svar er skjemavaliderte data med kilde og ferskhet oppgitt. Modellens rolle er å styre: velge hvilket verktøy som kalles og hva som gjøres med resultatet. Et faktum som ikke kom tilbake fra et verktøy, kommer ikke inn i vurderingen.

Kan en agent verifisere hvem som kan signere for selskapet?

Ja, med en ærlig grense. Fullmaktsverktøyet returnerer den registrerte signaturklassifiseringen, fra alene-signatur til felles ordninger, og det svarer unknown når de åpne dataene ikke kan avgjøre spørsmålet. En agent som behandler unknown som et stopp-og-spør-signal, i stedet for å runde det av til ja eller nei, gjør nøyaktig det sjekken er laget for.

Hvordan verifiserer en AI-agent et norsk selskap?

Av Antony Richard Grov, gründer av Apier

Ved å kalle deterministiske verktøy i stedet for å huske. Agenten får en oppgave i naturlig språk, for eksempel sjekk denne leverandøren før vi betaler. Den løser selskapet opp til det 9-sifrede organisasjonsnummeret, kaller verifiseringsverktøy som leser de norske registrene i det øyeblikket, og mottar en skjemavalidert vurdering: pass, warn, fail eller unknown, med hvert signal navngitt og hvert ukjent svar oppgitt i stedet for dekket over. Så handler den på fakta med kilde: registrerer vurderingen, flagger motparten, eller overlater til et menneske når svaret er unknown eller neste steg er bindende. Modellen styrer flyten, men faktaene kommer fra registrene gjennom verktøyene, aldri fra modellens hukommelse, og ingenting i flyten leverer eller skriver noe til et offentlig system.

Arbeidsdelingen som gjør agentverifisering til å stole på. Modellen eier de to ytterste boksene, å forstå oppgaven og velge hva som gjøres; den uthevede midten tilhører deterministiske verktøy som leser registrene.

Hva betyr verifisering for en agent?

Akkurat det samme som for et menneske som kjører KYB: fastslå at selskapet finnes, er aktivt, ikke er konkurs eller slettet, sjekk MVA-registreringen, og finn ut hvem som er registrert med rett til å signere. Spørsmålene endrer seg ikke fordi det er en agent som spør. Det som endrer seg, er mekanismen. Et menneske kan se på en registerside og bruke skjønn på det de ser; en agent trenger hvert av svarene som strukturerte data den kan forgrene på, fra en kilde den kan sitere.

Det kravet utelukker modellens egne treningsdata fra start. Det en modell har plukket opp om et selskap, er måneder til år gammelt og kan ikke siteres som grunnlag for en betalingsbeslutning. Verifisering er nettopp arbeidsflyten der et plausibelt svar er verre enn intet svar, så faktaene må hentes ferskt, fra registrene, i det øyeblikket spørsmålet stilles.

Én verifiseringskjøring, steg for steg

Ta det konkrete tilfellet diagrammet viser: en agent for leverandørgjeld blir bedt om å sjekke en leverandør før en faktura betales. Leverandøren er kjent ved navn, så kjøringen starter med å løse identiteten: search_companies gjør navnet om til kandidater med organisasjonsnummer, og agenten bekrefter treffet på adresse eller organisasjonsform i stedet for å anta det første. Med nummeret fastlagt returnerer get_company_verification vurderingen og signalene, og fordi en faktura skal betales, legger get_company_authority til hvem som er registrert med rett til å forplikte selskapet.

Hvert svar kommer som skjemavaliderte data med kilde og ferskhet oppgitt, så agentens sluttrapport kan si ikke bare godkjent, men godkjent fordi registeret sa aktivt, ingen krisemarkører, MVA-registrert, sjekket på dette tidspunktet. Hele kjøringen kan rekonstrueres i etterkant, og det er det som skiller et revisjonsspor fra en chatlogg.

Én leverandørsjekk, steg for steg: hva agenten gjør, verktøyet den kaller, og hva som kommer tilbake.
Steg	Verktøykall	Hva som kommer tilbake
Løs opp selskapet	search_companies med leverandørens navn	Kandidater med orgnummer, navn, form og adresse til å bekrefte treffet.
Verifiser status	get_company_verification med orgnummeret	En vurdering pass, warn, fail eller unknown, med hvert registersignal listet.
Sjekk signaturrett	get_company_authority med orgnummeret	Den registrerte signaturklassifiseringen, unknown oppgitt når åpne data ikke kan avgjøre.
Konkluder	Intet verktøy: agentens egen logikk	Godkjenn, flagg eller eskaler, med kildene og tidspunktene den samlet.

Hvorfor deterministiske verktøy i stedet for modellkunnskap?

Fordi samme spørsmål må gi samme svar så lenge registeret ikke har endret seg, og fordi hvert svar må kunne spores til en kilde. Verktøykall gir agenten begge egenskapene gratis: verktøyet leser registeret, svaret bærer kilde og ferskhet, og ingenting avhenger av hva modellen tilfeldigvis husker. Resonnementet bak dette skillet er et eget tema, og veiledningen om agenter som får norske fakta uten å hallusinere eier det; denne siden er arbeidsflyten det resonnementet gjør trygg.

Den praktiske koblingen er MCP, den åpne protokollen som lar Claude, Cursor og andre klienter oppdage og kalle disse verktøyene. Veiledningen om å koble en klient til norske selskapsdata over MCP dekker oppsettet, den nøkkelløse oppdagelsesflaten og nøkkelhåndteringen; her holder det at verktøyene dukker opp i agentens verktøyliste og svarer deterministisk.

Hva skjer ved unknown eller feil?

Flyten forgrener seg i stedet for å gjette. En unknown, for eksempel på signaturrett der de åpne dataene ikke kan avgjøre spørsmålet, er et fullverdig utfall agenten forventes å håndtere: flagge det, spørre et menneske, eller gå videre under en policy som uttrykkelig aksepterer hullet. Det agenten aldri må gjøre, er å runde unknown av til godkjent, for en sjekk med usynlige hull slutter å være en sjekk.

Feil er strukturert på samme måte. Et feilsvar bærer en maskinlesbar kode, en forklaring og konkrete utbedringssteg, så agenten kan skille en tastefeil i organisasjonsnummeret fra en manglende nøkkel og reagere riktig. En mislykket kjøring vises som en mislykket kjøring, aldri som en oppdiktet vurdering.

Hva kan agenten ikke gjøre?

Noe som helst bindende mot det offentlige. Flaten denne arbeidsflyten kjører på, er lese-og-validere: agenten leser registre, evaluerer regler og validerer nyttelaster, og ingen innsending leveres til Altinn eller noe annet offentlig system. Der en reell innsending ville vært neste steg, ender flyten i en overlevering som navngir hva et menneske må gjøre og hvor. At grensen er uttalt, er det som lar lesesiden kjøre autonomt med god samvittighet: agenten samler og forankrer dokumentasjonen, og beslutningene med rettsvirkning blir hos mennesker.

Gjør det første kallet

Oppdagelseskallet under trenger ingen nøkkel og returnerer den gjeldende verktøylisten, inkludert de tre verktøyene denne siden gikk gjennom. Pek en MCP-klient mot det samme endepunktet, så dukker verktøyene opp i modellens verktøyliste av seg selv.

# Nøkkelløs oppdagelse: samme kall som en MCP-klient gjør ved oppstart.
curl -s -X POST https://www.apier.no/api/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'

Ofte stilte spørsmål

Hvilke verktøy kaller en agent for å verifisere et selskap?: Tre dekker kjernen: search_companies løser et selskapsnavn opp til det 9-sifrede organisasjonsnummeret, get_company_verification returnerer vurderingen pass, warn, fail eller unknown med registersignalene bak, og get_company_authority svarer på hvem som er registrert med rett til å signere. Hvert svar navngir kildene sine og oppgir hvor ferske dataene er, så agenten kan sitere hvor hvert faktum kom fra.
Trenger agenten en API-nøkkel?: Ikke for oppdagelse; ja for selskapsdata. En MCP-klient kan liste de tilgjengelige verktøyene uten legitimasjon, og slik finner en agent ut hva serveren tilbyr. Verktøyene som besvarer spørsmål om et bestemt navngitt selskap, krever en API-nøkkel, og nøkkelens scopes avgrenser hva agenten når. Skillet er bevisst: oppdagelse er fritt, data om reelle selskaper er sporbart.
Kan agenten handle på vurderingen automatisk?: På lesesiden, ja: den kan registrere vurderingen, flagge en leverandør eller stoppe en onboarding, for det er beslutninger i ditt eget system basert på registrerte fakta. Det den ikke kan, er å utføre bindende handlinger mot det offentlige: ingen innsending leveres, og ingenting skrives til noe offentlig register. Alt med rettsvirkning blir hos et menneske, og agentens jobb er å komme dit med dokumentasjonen ferdig samlet.
Hvordan unngår agenten å hallusinere selskapsfakta?: Ved aldri å bli bedt om å huske dem. Verifiseringsflyten ruter hvert faktaspørsmål gjennom et verktøykall som leser de autoritative registrene i det øyeblikket, og verktøyets svar er skjemavaliderte data med kilde og ferskhet oppgitt. Modellens rolle er å styre: velge hvilket verktøy som kalles og hva som gjøres med resultatet. Et faktum som ikke kom tilbake fra et verktøy, kommer ikke inn i vurderingen.
Kan en agent verifisere hvem som kan signere for selskapet?: Ja, med en ærlig grense. Fullmaktsverktøyet returnerer den registrerte signaturklassifiseringen, fra alene-signatur til felles ordninger, og det svarer unknown når de åpne dataene ikke kan avgjøre spørsmålet. En agent som behandler unknown som et stopp-og-spør-signal, i stedet for å runde det av til ja eller nei, gjør nøyaktig det sjekken er laget for.