How it works

Every agent request goes through the same three steps: authenticate, pass through, record. Nothing is ever blocked.

1. Authenticate

The middleware inspects the incoming HTTP request and tries each enabled method, strongest first. The first one that verifies wins.

The result is one of three shapes:

type AgentAuthResult =
  | { status: 'verified'; agent: { id; name; vendor; method; claims? } }
  | { status: 'unverified'; reason; claimedName?; attempted }
  | { status: 'none' } // no agent signals — treat as human traffic

• verified — a credential checked out. agent.id is stable (a signer URL, key:<agentId>, oauth2:<clientId> or crawler:<name>), so you can key sessions and your own app logic on it.
• unverified — the request looks like an agent (a bot user agent, a signature, a key) but nothing verified. reason says why, e.g. web-bot-auth:expired or crawler:rdns_mismatch. The agent still browses your site normally.
• none — no agent signals at all. Human visitors land here and are never affected.

2. Pass through

Every request continues to your app — verified, unverified or human. The verified identity travels with it as x-agentronics-* request headers (forged ones are stripped first), so your routes know which agent they're talking to. If authentication itself ever fails internally, the request continues as unauthenticated traffic — Agentronics never takes your site down.

3. Record

Each agent sign-in can be streamed to the console as an auth log.

Server and browser

Some agents never execute your JavaScript — crawlers, API agents, most signed fetchers — so only the server half can see them. Others operate your page directly — WebMCP clients and browser agents — and the browser SDK authenticates those in the page. Both produce the same identity model and the same trust levels, and both stream to the same console.

What gets counted

Each unique verified identity that authenticates in a month is one monthly active agent. Human visitors and unverified agents are never counted.