For AI platforms
For AI platforms
Surface professional candidates from a pool of verified records, every claim sourced and dated, every response carrying structured non-recommendation disclosure. Implement via MCP or REST.
Why platforms implement ATAH
When an AI system identifies that a user needs human professional expertise, the response options are limited. The AI can refuse to engage. It can disclaim and leave the user with a search box. Or it can surface professionals — at which point the platform takes on the question of how those professionals were chosen and what verification stands behind them.
ATAH gives platforms a structured, defensible answer. The candidates surfaced come from a pool of verified records, drawn from authoritative sources — regulators, professional bodies, review platforms, independent verifiers — with every claim tagged for source and verification status. The AI ranks the candidates as it would any candidate set; ATAH provides a defensible basis for the candidates being in the pool.
Every response carries a presentation_disclosure block: a machine-readable assertion that the matching engine applied no commercial weighting, that the within-band ordering is randomised under a documented fairness policy, and that ATAH itself does not recommend or endorse individual professionals. AI platforms that reorder ATAH's response downstream MUST preserve this disclosure when surfacing results to users. The non-recommendation framing is part of the contract, not a marketing claim.
Verified candidates with provenance
Each candidate returned through ATAH includes the standard professional record fields plus a parallel provenance map. The provenance map shows, for each field, where the data came from, when it was last verified, and against which authoritative source.
A lawyer's licence status comes from their state bar; an insurance agent's appointment and licence status from state insurance department records and NIPR; board certifications from the relevant board; professional body memberships from those bodies; review-derived signals from review platforms ATAH has approved; availability and self-declared specialisms from the professional's own attestations. Each is tagged separately with verification status: registry-verified, partner-verified, VC-verified, or self-declared. Nothing is collapsed into an opaque trust score.
This gives platforms a defensible basis for the candidates surfaced — rooted in authoritative sources rather than scraped signals.
Two protocol components
Component 1 — Discovery. The query interface. AI agents pass declared need (matter type, jurisdiction, urgency, intent), a structured consent receipt, and a request_intent (self or on_behalf_of_client). The response is a candidate set with provenance and the presentation disclosure.
Component 2 — End-user handoff. The lifecycle for the end-user-self case (an individual or a business acting on its own behalf). AI agents choose one of three flow variants based on the category and user preference: off_protocol (Discovery only, no further ATAH mediation), contact_share (single-stage vault-mediated contact share), or full_lifecycle (Stage 1 appetite check, Stage 2 pre-handoff check, Stage 3 vault-mediated contact release with crypto-erasure on retrieval).
The professional-on-behalf-of-client case is served by Component 1 (Discovery) alone with request_intent: 'on_behalf_of_client'. ATAH does not deliver client contact details based on professional attestation.
Implementing ATAH
ATAH defines two transport bindings: MCP (Model Context Protocol) for agent-native integrations, and REST for platforms preferring a conventional HTTP API. Both bindings expose the same core protocol objects — Discovery queries, professional records with provenance, handoff lifecycle states, consent receipts, audit events, decision explanations.
The protocol is royalty-free to implement. The reference MCP endpoint will be free to query when operational. Authentication is required (OAuth 2.1) but there is no per-query fee, no licensing fee, and no commercial gate on protocol access at the platform layer.
POST /v1/query
Authorization: Bearer {oauth_token}
Content-Type: application/json
{
"criteria": {
"category": "insurance-agent",
"specialism": "personal-auto",
"location": "US-TX-AUS"
},
"request_intent": "self",
"limit": 10
}Full schemas, OpenAPI 3.1 contract, MCP tool definitions, and conformance requirements are published in the specification.
MCP and REST bindings
MCP binding
For agent-native platforms, ATAH exposes 14 MCP tools covering Discovery, handoff initiation, status checks, stage submissions, consent receipt management, withdrawal, and notification channel verification. Each tool declares its permitted_authority_bases so AI platforms can enforce authority discipline at the integration layer.
REST binding
For platforms preferring HTTP, ATAH defines a REST API with a broader surface than MCP — including end-user-facing, professional, partner, verifier, and admin endpoints. OAuth 2.1 authentication, JSON request and response, OpenAPI 3.1 contract published in the specification.