Cite this as: Apier.no — Why REST APIs Fail for AI Agents v1.0

Why REST APIs Fail for AI Agents

By Antony Richard Grov, founder of Apier

Traditional REST APIs fail for AI agents because they assume a human will read the docs, reason through the edge cases, and recover from errors by hand. An autonomous agent does none of those things, so it hallucinates parameters, misreads constraints, and cannot prove what it did. On a cosmetic app that is an annoyance. On a regulated action against Altinn or Skatteetaten (a hallucinated organisation number, a malformed tax submission), it is a legal liability.

Estimated read time: 7 minutes.

Why REST APIs assume a human reader

A REST API is a contract written for two readers: the program that makes the call, and the developer who wrote that program. The machine half of the contract is narrow — a URL, a verb, a JSON body, a status code. Everything that makes the API usable lives in the other half: the documentation a developer reads, the examples they copy, the Stack Overflow answer that explains why the obvious request returns a 400, and the accumulated judgement in the developer's head about which fields are really required and what the error text actually means.

That division worked for thirty years because there was always a developer in the loop. They read the prose, held the edge cases in mind, and retried by hand when something failed. An AI agent removes that human from the loop and inherits only the machine half of the contract. The half that carried the meaning never transfers.

Where agents break: discovery, reasoning, recovery, proof

An agent calling a conventional REST API breaks in four predictable places. Each maps to something the API silently delegated to the absent developer.

Discovery. The agent has to know which endpoint and which parameters to use. When that knowledge lives in prose docs rather than a machine-readable manifest, the agent guesses — and a guessed parameter is a hallucinated parameter.
Reasoning. The constraints that matter (which field is mandatory for this entity type, which legal precondition must hold before a submission is valid) are encoded in documentation and in the developer's judgement, not in anything the agent can evaluate. So the agent misreads the constraint and builds an invalid request that looks valid.
Recovery. A REST error is written for a human: 400 Bad Request, invalid input. There is nothing structured for the agent to act on, so it cannot self-correct. It retries the same broken call, or gives up.
Proof. A successful REST call returns a 200 and a body, and nothing else. There is no signed receipt and no tamper-evident record, so the agent cannot later prove to a third party (an auditor, a tax office, the company it acted for) exactly what it submitted and when.

For a chatbot summarising the weather, none of this is fatal. For an agent acting on a company's behalf against Brønnøysundregistrene or filing through Altinn, every one of the four is a liability, and a wrong answer is not a typo.

Developer APIs vs agent-native APIs

The difference lies in the assumptions about who, or what, is on the other end of the call, not in the SDK.

Developer APIs compared with agent-native APIs
Concern	Built for developers	Built for agents
Discovery	Human reads docs; OpenAPI as reference material	Machine-readable capability + tool manifest the agent enumerates
Reasoning	Edge cases live in prose and in the developer's head	Deterministic validation against rules stored as data
Errors	Prose message a human interprets and works around	Structured `error_code` + fix steps the agent self-corrects on
Authorization	Developer wires OAuth once, by hand	Signing authority read per call from the register: the register's coded signing rules for the company
Proof	`200` plus a response body	Response hash + provenance record + append-only trail
Determinism	Same call may vary with time or server state	Same input + same rule version = same output

What an agent-native API does differently

Closing the four gaps is a concrete checklist, not a philosophy. An agent-native API treats every one of them as a first-class part of the contract:

Machine-readable discovery. Capabilities, tool manifests, and an llms.txt the agent can enumerate, so it never guesses an endpoint or a parameter.
Deterministic validation before any action. Input is checked against what the register states before the agent acts, so a malformed request is caught at the edge instead of discovered too late.
Structured, self-correcting errors. Every failure returns a machine-readable error_code and concrete fix steps, so the agent can repair the request and retry instead of looping on the same broken call.
Explicit authority resolution. The register's coded signing rules for the company are read on every call from the public register, never assumed from a token that was wired up once.
A record and a trail. Every response carries a hash of the response and a timestamp, the API stores a provenance record of the source it read, and each lookup lands in an append-only audit chain that no one, including the API provider, can rewrite.
Transparency metadata. Each answer carries the rule version and data-freshness stamps it was computed against, so the agent knows how current and how authoritative the result is.

The contrast is sharpest at the error boundary. A conventional API hands an agent something a human has to interpret. An agent-native API hands back something the agent can act on directly:

{
  "success": false,
  "error_code": "ORG_NUMBER_INVALID_CHECKSUM",
  "explanation": {
    "summary": "The organisation number failed the MOD-11 checksum.",
    "fix_steps": [
      "Verify the nine digits against Brønnøysund.",
      "Retry with the corrected number."
    ]
  }
}

Nothing in that body needs a human to read it. The agent branches on error_code, surfaces the fix_steps to whoever can act on them, and retries when the precondition holds.

AVERT: the five-step loop an agent runs

AVERT is the name for that agent-native loop: the five steps an AI agent follows to take a regulated action on Norwegian government systems and come away with proof it can stand behind. The full framework lives at apier.no/avert; in short:

Authorize. Read the entity's registered signing rule (signaturrett and prokura) before anything else happens, and let your agent apply it to the action at hand.
Validate. The agent checks its planned action against what the register records, and every error Apier returns is machine-readable so the agent can self-correct. Apier forwards nothing to government.
Execute. The binding step happens in the company's own systems, under the company's own authority. Apier offers no write path and submits nothing.
Receipt. A tamper-evident record of what was read, from which register and when (a response hash and a provenance record on every response, a signed certificate on request), so the basis for the action can be independently verified later.
Trail. An append-only, compounding audit chain of the entity's regulated actions, which no one, including Apier, can rewrite.

Where this stands today: read lookups run in production and every read lands in the append-only trail. The write path (Execute as a binding submission, such as actually filing an MVA-melding) is not offered by Apier: the company files in its own systems. An agent cannot use Apier to file a VAT return; it can read the register's coded signing rules for the company, read the deadlines, check its inputs against the register, and keep a provable record of what it read up to the binding step. The specification is public and open to review at github.com/PowerLaunch/avert-spec.

Where Apier fits

Apier is the API and MCP layer that gives AI agents sourced, dated answers about Norwegian companies from the public registers (Brønnøysundregistrene) and the published rules, and implements the agent-native contract for reads: machine-readable discovery, deterministic validation, structured self-correcting errors, signed receipts, and an append-only trail. It does not sell company data; data lookups are a commodity. Proof and trail are not, and that is the layer AVERT defines.

If you are building an agent that needs verified facts about Norwegian companies, start with the docs and a key:

Sign up for an API key — free tier, no government credentials required to start in the sandbox.
Read the docs — endpoints, the MCP server, and the structured-error contract in full.
The AVERT framework — the five-step loop and how each step maps to a government system.

Common questions

Why can't an AI agent just use a normal REST API?

An agent can call a REST endpoint, but it cannot reliably read prose docs, reason through legal edge cases, recover from prose error messages, or prove what it did. On a regulated action that gap means hallucinated parameters and a result the agent cannot stand behind.

What is AVERT?

AVERT is a five-step loop (Authorize, Validate, Execute, Receipt, Trail) that an AI agent follows to take a regulated action on Norwegian government systems and come away with cryptographic proof.

Can an AI agent use Apier to file a Norwegian VAT return?

No. Apier reads company facts, signing authority and deadlines, and every read lands in an append-only trail. Apier does not submit VAT returns or other filings; in the AVERT loop the Execute step happens in the company's own systems, under the company's own authority.