How do AI agents get Norwegian company facts without hallucinating?

Why do language models hallucinate company facts?

Because parametric memory is a snapshot, and answering from it is generation rather than retrieval. When a model states a board composition or an organisation number from training data, it is continuing a statistical pattern, not consulting a record. The output is shaped like a fact and delivered with the same fluency whether the underlying value was memorised correctly, memorised from an outdated page, or assembled from fragments of several companies. Nothing in the mechanism distinguishes those cases.

Even a value that was correct at training time decays. Boards change, companies enter liquidation, deadlines shift when a statutory date lands on a weekend or holiday. The register moves daily; the snapshot does not. So the failure is not that the model is careless: it is that recall of registry data has a shelf life, and the model has no way to know how stale its copy is.

Scraping at answer time narrows the gap without closing it. A fetched page may be cached, translated, or simply old, and the agent receives unstructured text it must interpret before it can act. Interpretation is the same generative step in a new place, and a parsing mistake reads exactly like a fact.

What does grounding actually require?

First, a deterministic tool that queries the authoritative register when the question is asked, not before. Determinism is a published property of this API: the same input evaluated under the same rulebook version returns the same output, so an answer can be reproduced later during review.

Second, schemas on both sides of the call. Inputs are validated at the boundary: an org number is nine digits with a MOD-11 control digit, and a string that fails the checksum is rejected as a typo rather than reinterpreted into something the model probably meant. Outputs are typed JSON, so the agent reads fields instead of paraphrasing prose, and a missing field is visibly missing rather than silently smoothed over.

Third, provenance on every answer. Responses carry a _meta block naming the data source, the data freshness and the rulebook version the evaluation ran under, and MCP tool results add a justification listing the rules applied and the source data behind the verdict. That is what lets an agent cite its reasoning to a user, and what lets the user check it.

Retrieval or guessing: why is an unknown verdict a feature?

A grounded answer says unknown when the register is silent, and that verdict is load-bearing. The open registry data does not cover everything: who holds signaturrett or prokura, for example, is Foretaksregisteret information that the open roles vocabulary simply does not contain, so the honest open-tier answer is unknown, never an empty list dressed up as a finding. An agent built on this kind of register-backed workflow can branch on that verdict: escalate, ask, or stop.

The model's fluent guess is the bug in this contrast, not the fallback. Fluency is uncorrelated with truth: a wrong organisation number reads exactly like a right one, and a fabricated board member is grammatically indistinguishable from a real one. A system that can say unknown converts missing data into a visible state the caller handles; a system that cannot will fill the silence with its best continuation, which is precisely the behaviour the word hallucination names.

How does MCP wire the model to the register?

Through a hosted tool server the model discovers rather than memorises. The endpoint is https://www.apier.no/api/mcp, discovery is keyless, and the tools appear in the model's tool list with their input schemas attached, so the model knows the exact shape of a valid question before it asks one. Client setup, the per-client configuration matrix and the full tool reference are owned by the MCP server guide.

The key boundary follows the data, not the transport. Six public tools execute without any credential, including the obligation templates, the filing calendar and the error explainer; every tool that answers about a named company requires an API key. The model itself never holds a government credential in either mode: the agent's key grants scoped reads against Apier, and everything on the government side stays behind the API, a separation the safe-access guide covers in full.

This wiring deliberately includes no write path: the tools read, resolve and validate, and nothing here files anything to a government system. Every call is a question, and every answer arrives with the evidence attached.

Make the first call

The config block connects Claude Desktop to the hosted server through the published stdio proxy. The curl below needs no key: it executes one of the six keyless tools and returns the 2026 filing calendar with its provenance attached, the whole argument of this page in one response.

{
  "mcpServers": {
    "apier": {
      "command": "npx",
      "args": ["-y", "@apier-no/mcp"],
      "env": { "APIER_API_KEY": "apr_live_<your_key_here>" }
    }
  }
}

# Keyless tools/call: the 2026 Norwegian filing calendar, evaluated
# from the rulebook at answer time, no credential required.
curl -s https://www.apier.no/api/mcp \
  -H "content-type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"get_public_deadlines","arguments":{"year":2026}}}'

Frequently asked questions

Why does an LLM invent an organisation number?

Because generating one is recall-shaped, not lookup-shaped. A Norwegian org number is nine digits with a MOD-11 control digit, and a model that has seen millions of them can produce strings that look right and sometimes even pass the checksum. Nothing in that process consults a register, so the number is plausible rather than true. The fix is structural: validate the format at the boundary, then resolve the number against Brønnøysund-backed data before any downstream step treats it as a fact.

What makes a tool answer trustworthy?

Three properties together: schema, source and freshness. The input is validated before anything runs, so a malformed org number is rejected rather than reinterpreted. The output is structured JSON the agent parses field by field instead of prose it paraphrases. And the answer carries provenance: which source it came from, how fresh the data is, and which rulebook version evaluated it. An answer with those attachments can be checked; a fluent sentence cannot.

What should an agent do when the data is missing?

Report unknown and stop. The open Norwegian registry data genuinely does not cover everything: signaturrett and prokura texts, for example, live in Foretaksregisteret and are absent from the open roles vocabulary, so the honest open-tier answer about them is unknown rather than an empty list. An agent that passes that verdict through gives its user a true picture. An agent that fills the silence with a guess converts a data boundary into a fabrication.

Can an agent verify a company without an API key?

It can rehearse the whole shape without one. Discovery at the MCP endpoint is keyless, six public tools execute keylessly, and the zero-auth sandbox mirrors the verify call on simulated data, so an agent can learn the request and response shapes end to end. Live answers about a real, named company are the keyed surface: company-data tools return 401 without a key, deliberately, because that data is personal-adjacent.

Does grounding remove the need for human review?

No, and it is not meant to. Grounding fixes the factual layer: the agent stops asserting stale or invented register data and starts citing sourced, dated answers. Decisions built on those facts are a separate layer, and for anything binding, a filing, a contract, a representation to an authority, a human still reviews before anything is committed. What grounding changes is the quality of what the human reviews: verifiable inputs instead of confident prose.