An open A2A profile for AI-mediated hiring. Two agents — one for the candidate, one for the recruiter — interview each other with cited, dereferenceable evidence.
§1 · Why HAP exists
Resumes are static; AI generators have made the medium unverifiable. ATS giants (Greenhouse, Lever, Workday) own the pipe but won't compose. HAP fixes both — without asking either side to switch vendors.
When both sides are AI agents — and they will be — they need a standard interview protocol to talk to each other. HAP is that protocol. One sentence: it lets a candidate-agent and an HR-agent run a structured interview without either side handing over a full resume or full job description upfront.
No central server, no on-chain claims. Each side runs its own agent on its own infrastructure. Discovery is optional and lives in a tracker layer, BitTorrent-style. Spam is a federation-policy problem — blocklists, rate limits, reputation — solved on top of the protocol, not inside the core.
peer-to-peer·vendor-neutral·no brokerA candidate-agent answers with a GitHub commit SHA, a conference talk URL, a paper DOI. The HR-agent dereferences and verifies — author byline matches, maintainer list contains the candidate, talk venue is real. Self-claim without trace is allowed but flagged as low-confidence.
every claim is a hyperlink·trust is per-URL, not per-nameThe candidate-agent decides what to disclose, in response to each question. The HR-agent asks for what the JD requires. PII stays on the candidate's box until both sides have committed to the session. Refusing to answer is a first-class outcome, not a red flag.
piece-wise·candidate consent on every byte
HAP messages are valid Google A2A
messages. We standardize content, not transport. Any
A2A-compliant runtime — OpenAI's, Anthropic's, Google's, yours —
speaks HAP the moment it declares the hap.v0 skill.
§2 · Specification · v0.1
Every HAP agent publishes an A2A AgentCard at
/.well-known/agent.json declaring the hap.v0
skill. Every interview is a sequence of seven well-typed messages.
Below are the canonical shapes; the full RFC adds prose, registries,
and versioning rules.
Stock A2A AgentCard plus a hap namespace declaring
role, version, supported evidence types, and rate limits. Spam
mitigation lives here — peers honor the declared limits.
{
"name": "alex-chen / candidate-agent",
"protocolVersion": "a2a/0.3",
"skills": ["hap.v0"],
"endpoints": { "message": "https://alex-chen.dev/a2a/message" },
"hap": {
"role": "candidate",
"supported_versions": ["v0.1"],
"supported_evidence_types": [
"github_user", "github_repo", "github_commit",
"talk", "blog_post", "package"
],
"rate_limit": { "per_day": 100, "per_hour": 20 }
}
}
A single structured question. evidence_preference tells
the candidate-agent what kinds of traces would be most credible —
but the candidate-agent chooses what to actually disclose.
{
"kind": "hap.ask",
"session_id": "h_01HXY7K4M2P9R8VQ",
"question_id": "q1",
"ask": {
"type": "open",
"prompt": "Walk me through an idempotency system you've shipped at >10k RPS.",
"evidence_preference": ["github_commit", "talk"]
}
}
Short prose answer plus an array of evidence objects. Each
evidence is a typed URL the HR-agent can dereference and verify.
confidence is self-declared but informs the
HR-agent's weighting.
{
"kind": "hap.answer",
"question_id": "q1",
"answer": {
"text": "Designed the key-normalization layer for our payment router…",
"evidence": [
{ "type": "github_commit", "url": "https://github.com/.../commit/9f4ac21" },
{ "type": "talk", "url": "https://youtu.be/AbCdE", "venue": "GopherCon 2024" }
],
"confidence": "high",
"decline_reason": null
}
}
Seven message kinds total. Either side may close the session at
any point. outcome is informational — HAP does not
rank, score, or decide; that's the consuming app's job.
§3 · Reference impls · 60-second quickstart
Three commands. Spins up a candidate-agent and an HR-agent on
localhost, runs one HAP session, prints the transcript.
No API keys required — falls back to a template HR-agent if no LLM
is configured.
↪ optional · OPENAI_API_KEY or ANTHROPIC_API_KEY in .env enables LLM-generated questions on the HR side.
↪ no key, no problem · template HR-agent ships with five pre-built question lines; hosted proxy at hap.dev/proxy if you want LLM without a key.
§4 · Where HAP sits
HAP is to Google's A2A what HTTP is to TCP. A2A handles the envelope — agent cards, message routing, auth. HAP standardizes the payload: what a hiring conversation actually contains.
The evidence registry is the only open extension point and is community-extended, not vendor-owned.
§4a · How HAP differs · honestly
We get asked "isn't this just another X?" a lot. Short answer: no. Long answer:
Owns application tracking; assumes the candidate sends a resume upfront. Interoperability is per-vendor; you build to their API. The HR-agent is a tenant inside their UI.
A protocol, not a product. Federated. Evidence-cited. Progressive disclosure. Ships today as MIT-licensed reference impls — and the ATS above can run an HR-agent on top of HAP without changing databases.
Cryptographically clean but adoption-blocked. Depends on an issuer ecosystem that doesn't exist yet for hiring. 3–5 years out by ecosystem estimate. We didn't want to be a dead-on-arrival spec.
§5 · Roadmap · published, dated, honest
We're 0.1. Anything before v1 may change. The point of publishing now is to get the schemas critiqued before they're hard to move. Dates are best-effort and slip publicly.
§6 · FAQ · for the skeptical reader
MCP is agent ↔ tool. HAP is agent ↔ agent. Two AI agents talking to each other about a job is a peer conversation, not a tool call. A2A is the right layer; HAP is the right profile on that layer.
We considered W3C VC and rejected it as premature — adoption is 3–5 years out and depends on an issuer ecosystem that doesn't exist for hiring. When VC matures, HAP evidence can wrap a VC like any other URL; the registry is open.
The same things that work for email and ActivityPub: TLS-served agent cards, declared rate limits, blocklists, reputation services. Spam is a federation-policy problem solved on top of the protocol — not inside the core.
Their call. Reference impls self-host by default. The hosted
convenience tier on hap.dev uses a "do not log" policy.
Data never leaves the candidate-agent unless the candidate-agent
chooses to disclose it.
LinkedIn is a database with identity and a marketplace attached. HAP is a wire format with none of those. We can't centralize even if we wanted to — the spec doesn't have a place to put a central server.
Out of scope. KYC providers do that. HAP gives the HR-agent enough public evidence (commits, talks, papers) to decide how much identity proof to ask for, before involving a human.
No. HAP is the interview channel, not the application tracking system. An ATS can plug in as the HR-agent runner; the ATS keeps its database and HAP carries the conversation.
One person. v0.1 is published to get punched at. PRs and issues on the GitHub repo are the entire roadmap process. If the schemas are wrong, we want to know before v1.0 locks them in.
It's MIT. It's v0.1. The fastest way to find out if it's any good is to run it.