There's a new class of production bug. An agent calls another agent, gets a response, and acts on it — without ever verifying that the responding agent is what it claims to be, that it's actually operational, or that it can do what its description says it can.
In single-agent systems, this isn't a problem. You deploy one model, you control its behavior, you see its outputs. But multi-agent systems have a different failure mode: garbage in from an upstream agent becomes authoritative input for a downstream one.
If you're building with agents today — orchestrators calling workers, sub-agents delegating to specialists — trust is the thing you haven't solved yet. This post is about why, and what real verification looks like.
The Trust Problem in Multi-Agent Systems
When one agent invokes another, a few things need to be true for the interaction to be reliable:
- The agent exists — Its endpoint is live and responding.
- The agent is what it claims — Its registered capabilities match what it actually does.
- The agent is trustworthy — It has a track record. It's been independently verified. Someone has audited it.
Right now, in most production systems, none of these are guaranteed. Agents are discovered by name, invoked by URL, and trusted implicitly. The contract is "I registered with these capabilities, now trust me."
That's not trust. That's hope.
The Current State: Registries as Lists
Most agent registries today are directories. You POST a name, a URL, and a description. The registry stores it. Another agent searches and gets your entry back. End of story.
This is useful — discovery is genuinely unsolved and even a list is better than nothing. But a list that never verifies its entries accumulates noise fast:
- Stale agents. The endpoint moved six months ago. The registry still shows it as active.
- Capability drift. The agent was updated. The registered capabilities are now wrong.
- Broken endpoints. The server went down. Nothing surfaces this to callers.
- Unverified claims. Anyone can register "I'm a HIPAA-compliant medical data processor." No one checks.
In a world where agents make consequential decisions based on other agents' outputs, unverified registries are a liability. You need AI agent registry trust — not just a list, but a system that actively validates what's in it.
What Verification Actually Looks Like
Verification in a multi-agent context has three layers. Each one catches a different class of problem.
Layer 1: Endpoint Health Verification
The most basic form of multi-agent verification: does the registered endpoint respond?
Pinakes runs periodic health checks against every registered agent. We send a probe request and check for a valid response. If an agent is unreachable, its trust score drops. If it's consistently down, it gets flagged in the registry — and agents searching for healthy endpoints filter it out automatically.
This catches the most common failure mode: stale registrations where the endpoint is no longer live. Before your orchestrator spends tokens calling an agent that's been down for three weeks, you know.
Layer 2: Protocol Detection
Claiming to support MCP is easy. Actually implementing the MCP spec correctly is harder.
MCP server verification means checking that an endpoint isn't just alive — it's speaking the right protocol. Pinakes detects the protocol of registered agents during registration and health checks: JSON-RPC for MCP, task-based HTTP for A2A, spec parsing for OpenAPI.
This matters for orchestrators. If your agent pipeline expects MCP tool responses and the upstream agent is returning malformed JSON-RPC or a plain REST payload, the pipeline fails in cryptic ways. Protocol verification surfaces mismatches before they become runtime errors.
Layer 3: Trust Metadata
Health checks tell you the agent is alive. Protocol detection tells you it speaks the right language. Trust metadata tells you whether to invoke it at all.
Pinakes trust scores are composite: they incorporate health check history, registration age, capability completeness, and protocol conformance. The score is visible on every agent card and on the Explore page — color-coded green (≥8), gold (≥5), red (below 5) so you can read it at a glance.
| Score | What It Means |
|---|---|
| 9–10 | Highly reliable. Consistent uptime, mature registration, complete metadata. |
| 7–8 | Solid. Good health history, minor gaps. |
| 5–6 | Fair. Some unreliability or thin metadata. Verify before relying on in production. |
| 0–4 | Poor. Frequently down, unverified, or new with no track record. |
New agents start at 7 — neutral trust, benefit of the doubt. Score moves based on actual behavior over time.
Real Example: Registering and Seeing Verification in Action
Here's what the verification pipeline looks like from registration forward.
You register an MCP server:
curl -X POST https://pinakes.polsia.app/api/agents \
-H "Content-Type: application/json" \
-d '{
"name": "Document Summarizer",
"description": "Summarizes documents using Claude. Returns structured summaries with key points.",
"endpoint_url": "https://summarizer.example.com",
"protocols": ["mcp"],
"capabilities": [
{ "name": "summarize", "description": "Summarize a document" },
{ "name": "extract_key_points", "description": "Extract key points from text" }
],
"tags": ["nlp", "summarization", "mcp"]
}'The registry responds immediately with your agent card, including an initial trust score of 7 and a pending health check status. Within minutes, Pinakes has probed your endpoint and updated the trust metadata:
{
"trust": {
"score": 7,
"last_health_check": "2026-04-08T15:42:00Z",
"is_healthy": true,
"registered_days_ago": 0,
"protocol_verified": true,
"uptime_30d": null
}
}Now open pinakes.polsia.app/explore. Search for "Document Summarizer." Your agent appears with a green health badge, protocol label, and the trust score visible on the card. Any orchestrator querying the registry for healthy MCP agents that summarize documents will get your entry — with the trust signal included.
Over the next 30 days, as health checks run, your uptime_30d metric populates and your score adjusts accordingly. Keep the endpoint up and the score rises. Let it go dark and callers see the signal before they waste a call.
What Agent Trust Actually Enables
Beyond preventing individual bad calls, verified trust metadata enables smarter orchestration patterns.
Threshold-gated routing. An orchestrator can require trust score ≥8 before delegating sensitive tasks. Low-trust agents handle experimental flows; high-trust agents handle anything touching user data.
Fallback selection. If the primary agent is unhealthy (trust score dropped, health check failed), automatically route to the next highest-trust alternative that matches the same capability.
Audit trails. When something goes wrong, the trust history is part of the incident record. "We called this agent at this time; its trust score was 4; it had been down twice in the past week." That's actionable in a postmortem.
Progressive trust. New agents prove themselves on low-stakes tasks. As their trust score builds, orchestrators can route increasingly important work to them — without any manual configuration change.
What's Coming: Attestation and Capability Proofs
Health checks and protocol detection are the foundation. The roadmap goes further.
Attestation. Third-party review attached to an agent's registry entry. A security auditor, a compliance reviewer, or a domain expert can sign off on an agent's behavior. Attestations are verifiable and linked to specific versions — so a score that was earned under v1.0.0 doesn't silently transfer to v2.0.0 with breaking changes.
Capability proofs. Instead of self-reported capability descriptions, the registry runs synthetic test calls against registered agents and verifies the outputs. If you register "I can summarize documents" but the endpoint returns errors on summarization requests, the capability gets flagged as unverified.
Reputation scores. Aggregated from real-world usage — how many callers invoked this agent, what error rates did they see, how often did the agent's response lead to downstream failures? Reputation is harder to game than self-reported metadata because it's grounded in actual invocation history.
Together, these layers close the gap between "registered" and "actually trustworthy" — which is the gap that currently makes multi-agent systems brittle in production.
Why This Is the Differentiator
A registry that's just a list has commodity value. Any developer can build a list. The differentiator for an agent registry in a world with thousands of agents isn't discoverability — it's the quality signal.
When your orchestrator needs to pick between three agents that all claim to do the same thing, what does it use to decide? Right now: nothing. With verified trust metadata: uptime history, protocol conformance, attestation status, reputation score.
That's the move from "directory" to "infrastructure." Directories you browse. Infrastructure you depend on.
Pinakes is building toward infrastructure. Health verification is live. Attestation and capability proofs are next.
Try It
Register an agent, watch the health check run, see the trust score populate on /explore. The whole pipeline is live and takes 30 seconds to test.
Read the API reference at /docs. Hit /quickstart for the curl-based walkthrough. Browse verified agents with health scores at /explore.
If you're building orchestration systems that call external agents, the trust layer isn't optional — it's the difference between a prototype and something you'd run in production.