Status and reliability for the Internet of AI Agents.

The argument in one paragraph

NANDA defines the agent. Status defines whether it works.

Project NANDA is building the discovery, identity, and federation layer for the Internet of AI Agents: the NANDA Index, AgentFacts, the auth/authz pattern that lets a third party read an agent without that agent being fully publicly exposed. What's notably absent from the spec at v1/v2 is a continuous reliability layer.

Evaluations are in scope per the working groups, but evaluations answer "did the agent pass a test once?" They don't answer "is the agent still working right now, from where real users are."

That's the gap Agent Status fills, and the integration is structural: Agent Status reuses NANDA's auth standard, reads registered agents without requiring full public exposure, and writes back a continuously-updated reliability profile as part of each agent's record.

Where we fit

Where Agent Status fits in the NANDA stack.

Three layers, one boundary that doesn't move. NANDA owns the top: the NANDA Index, AgentFacts, identity, the auth pattern. Agent Status owns the bottom: residential probes from Fabric, the validation engine, the per-agent reliability profile. The middle band is the part we've already built: the Agent Status NANDA Adapter, which reuses NANDA's auth standard to read registered agents and pull them into our monitoring pipeline.

The substrate

The reliability layer sits on top of NANDA.

NANDA is the substrate. The NANDA Index gives the ecosystem a federated way to find registered agents. AgentFacts describes them with signed, schema-validated metadata. The auth pattern lets a third party read an agent without that agent being fully publicly exposed. Evaluations are emerging through the NANDA working groups.

Agent Status builds on every one of those. We subscribe to the Index to discover registered agents. We read AgentFacts to know what to probe and how. We reuse NANDA's auth so agents stay scoped, not fully publicly exposed. And we write reliability data back as part of the agent's profile, so a NANDA-registered agent ships with a continuously-updated status alongside its static metadata.

Evaluations answer "did this agent pass a test once?" Status answers "is this agent still doing the right thing right now, from where users actually are?" Both belong in the spec. Both build on the same NANDA primitives.

Shipped

What we've already built.

The probe adapter and A2A runtime support are shipped code. The NANDA Index + host39 onboarding path is the active integration — URN resolve, agent card fetch, continuous monitoring on Fabric nodes.

How integration works

URN → card → probe → status.

NANDA Index assigns stable identities as URNs (e.g. urn:ai:domain:moonbakery39.com:agent:orders). SMB and personal operators publish A2A agent cards on host39.org; the Index resolves the URN to that card. Agent Status walks the same path, then probes the runtime endpoint from residential devices and writes back a reliability profile.

Architecture

Who does what — and where probes run.

Non-negotiable: probe execution stays on Fabric nodes. The Agent Status backend only resolves identities, schedules jobs, and aggregates verdicts — it never runs workloads directly.

Stable identity: the URN locator. Mutable probe target: AgentCard.url — re-resolved when TTL expires or the card is edited.

System layers

Ownership

Registration paths

Adapter runtime model

1. Ingress — poll host39/NANDA export, webhook on card.published, or manual URN in dashboard
2. Resolve — run hops 1–3 per locator; cache until ttl_seconds
3. Translate — map to monitoring row: name, endpoint_url, request_format, adapter_config with nanda_locator
4. Reconcile — create/update/pause via API; track external_id → agent id
5. TTL refresh — scheduler re-resolves before probe when cache stale
6. Write-back (Tier 1–2) — push summary status to host39 via status poll + reliability field

Legacy note: HOL discovery (hol_nanda + nanda_a2a) targets enterprise registry endpoints, not NANDA Index URNs or host39 cards. New integration work uses Index resolve.

Integration tiers

Three tiers, shipped in order.

One vocabulary everywhere: Tier 1 is the minimum live integration (reliability field in host39), Tier 2 adds public report + badge links, Tier 3 adds optional dashboard access. Agent Status has shipped the APIs for all three; host39 wires Tier 1 first. Probes always run on Fabric nodes only.

NANDA / host39 delivers for Tier 1: pilot URNs, webhook + status poll wiring, reliability field in AgentFacts. Agent Status delivers: partner API, resolve adapter, probe scheduling, and Tier 2–3 endpoints (already live). Full engineering checklists: agentstatus.dev/nanda/integration.

The ask

Here is the concrete next step we are proposing.

A working-group conversation with the NANDA team, starting with Mahesh and Ramesh, on three things:

Why now

Why this is structural, not bolted-on.

A registered agent isn't a working agent. NANDA gives the ecosystem a way to find agents, describe them, and authenticate them. The natural next question, the one enterprise buyers and downstream agents both ask, is whether the agent is currently doing what it claims to do, this week, from where users actually are. Without a reliability layer baked into the spec, every registered agent ships with an unanswered trust question.

The right shape is an open reliability standard that Agent Status is the reference implementation for, the same way Anthropic's MCP and Google's A2A sit underneath NANDA today. Open standard, multiple implementations possible, Agent Status as the operational layer that's already running.

Receipts

Numbers we stand behind.

Federated registries list 2,700+ NANDA-family agents; continuous monitoring percentages for the host39/NANDA Index cohort will be published after the Tier 1 pilot completes (target: 10+ agents, 7+ days, 15+ runs each). Methodology published alongside results.