Kitsuno Handshake

The problem we're solving#

Hiring agents now exist on both sides of the table. Job seekers use agents that auto-apply to hundreds of postings. Companies use agents to filter, screen, and rank. The result is an arms race — agents talking past each other, drowning in volume, with no shared contract for who's allowed to say what to whom, when, and with what consent.

Google's A2A protocol (April 2025) gave agents a way to discover and communicate with each other. It's the transport layer. But it deliberately doesn't tell agents what they're negotiating about. Each vertical has to define its own semantics.

Commerce has ACP, AP2, UCP. Hiring has nothing. Until now.

The protocol: three disclosure tiers#

Handshake maps the recruiter funnel into three tiers of disclosure between agents. L1 and L2 are agent-to-agent. L3 is the moment humans cross the bridge.

Posters configure per-field which tier reveals which information. Defaults align with standard ad practice and the EU pay-transparency directive; the tier_overrides field lets posters demote or promote specific fields for confidential searches or sensitive comp data.

State machine#

A single handshake between a seeker and a vacancy is one conversation with a deterministic, monotonic state flow — disclosure only ever advances, with consent at each step. There is one entry state, l1_fired, reached from either direction: a seeker agent firing autonomously during discovery (initiated_by: agent), or a human applying directly to a specific vacancy (initiated_by: human — the case we call direct apply). Both run the same deterministic policy_match (L1) and the same validator strong-fit gate (L2); they differ only in who initiated and what is therefore owed in return.

Each transition is HMAC-signed (Stripe-style, with timestamp). Every event is idempotent — receivers deduplicate by event_id. A conversation terminates as declined (a party said no), not_advanced (it failed the L2 validator gate), or expired (the L1 TTL lapsed, default 14 days). One conversation exists per (seeker, vacancy) pair: a direct apply to a vacancy already met in discovery attaches to the existing conversation_id and advances it — never a duplicate, never a reset.

Intake modes & resolution#

L3 — the crossing into identity — is a two-sided preference resolved at match time, not a fixed direction. The vacancy declares how it takes identity; the seeker declares whether identity may be disclosed without a human in the loop. Neither side can override the other.

Vacancy intake (l3_intake_mode on the vacancy card): on_request — screened intake; receive L2, a human reviews and requests L3 per candidate. on_match — open intake; the L3 of any L2-eligible candidate whose consent permits it is auto-delivered to the vacancy's endpoint. Default on_request; an agent that does not understand the field treats it as on_request.

Seeker consent (consent_policy.agent_may_release_l3_without_human_review on the seeker card, or an inline l3_at_fit on a direct application): off — the seeker is asked each time before identity is disclosed. on — the seeker has already said yes; disclosure fires without asking, and the seeker is told it happened.

Application requirements — the readiness predicate on this grid. A vacancy may declare application_requirements: materials the applicant produces and delivers (a portfolio link, a work sample, a written answer, a repo), as opposed to l2_structured_questions answered from the seeker's standing PRS. Their content is L3 — at L2 each is only a provided / not-provided boolean. The grid above resolves only once the required requirements are satisfiable: if a required item is not provided, the match is not rejected — the seeker is invited to apply ("you match; provide X"), and providing X is the application and the situated L3 consent for this conversation. So even under on_match + consent on, L3 auto-discloses only when every required requirement is already satisfiable from the seeker's standing card; otherwise the seeker applies first. wished / supporting requirements never block. Which requirement types a standing card can pre-satisfy versus which demand an active apply is an operator implementation choice (the protocol fixes only the rule: required && not provided → invite to apply).

The handshake delivers the L3 event to the conversation's registered endpoint and stops there. What a receiving product does with it — draft an outreach, create a recruiter-inbox row, fire a CRM webhook, or nothing — is operator-defined and outside the protocol. The handshake itself drafts and sends nothing. Likewise, whether and how any resolution is billed is each operator's own policy; the protocol carries no price.

Signals: who hears what#

The governing rule for what gets reported back is one line:

A passively-discoverable seeker fans across thousands of L1/L2 conversations; the overwhelming majority die quietly at the policy or validator gate. Reporting every one back would be the exact noise the protocol exists to remove — so ambient discovery failures are silent. Only meaningful, human-touched, or identity-crossing edges emit a signal, delivered to the party it is owed to:

• l2_delivered — L2 arrived at the vacancy.
• l2_no_match — a direct application failed the validator gate. Owed to the seeker only when the fire was initiated_by: human — they applied, they are owed an answer. An agent-discovery L2 failure is silent.
• l3_initiated — a poster reached for identity; the seeker is being asked.
• l3_disclosed — identity was released, including an auto-fire the seeker never witnessed. Always carries destination — where the identity went — the structural floor for invisible disclosure.
• l2_refused / l3_refused — a party said no. A refusal is a resolved signal, reported to the counterparty.

The validator: anti-spam at the L2 boundary#

The state machine above describes the protocol's shape. But there is one decision point inside it that deserves its own treatment: after l2_disclosed and before either side surfaces the conversation to a human, a validator decides whether this handshake is worth asking a human to look at.

Without this gate, the protocol would forward every policy-clearing match to a human inbox. The point of the protocol is the opposite: a pipeline is a commitment surface, not a feed. If everything that passes the deterministic policy gate lands in front of a person, the person learns to stop looking — and the protocol has nothing to show for itself.

Three buckets, four dimensions

The validator returns one of three verdicts:

Every verdict includes four structured fit_dimensions for downstream analytics and tuning:

• role_alignment — does the work itself overlap, beyond role family?
• seniority_fit — does the seniority expectation match the seeker's range?
• skill_overlap — substantive overlap, not just keyword surface?
• context_fit — country, language, employment shape, work mode?

A low_signal flag is set automatically when the vacancy description is shorter than ~800 characters — distinguishing weak fit because the data is thin from weak fit because actually weak. Operators tune this threshold to their corpus.

Where it fires

The validator runs once per handshake conversation, after both L2 disclosures have been exchanged. The annotation on the state machine above — human release · L3 — is the moment the validator's verdict matters: a STRONG verdict makes the conversation L3-eligible (the human can choose to cross the bridge); WEAK or NO_FIT block the L3 release pathway without telling either party.

Output shape

The verdict is a strict JSON object. Implementations across any model or rubric must conform to this shape so downstream consumers (pipeline UIs, analytics, feedback loops) can interoperate:

{
  "verdict":      "strong_fit" | "weak_fit" | "no_fit",
  "reason":       "<one sentence, candidate-facing, ≤200 chars>",
  "fit_dimensions": {
    "role_alignment":   "match" | "partial" | "miss",
    "seniority_fit":    "match" | "partial" | "miss",
    "skill_overlap":    "match" | "partial" | "miss",
    "context_fit":      "match" | "partial" | "miss"
  },
  "low_signal":   true | false
}

Privacy properties

The validator's verdict is asymmetric by design.

• The vacancy side learns nothing new. Verdicts never cross the agent boundary toward the poster. Strong fits arrive in the poster's inbox the same way they would have via any other path — the validator's role is upstream of that surfacing, not part of it.
• The seeker side learns only of STRONG fits. The reason text shows up on the pipeline card as the "why this matched" explanation. WEAK and NO_FIT verdicts never reach a seeker UI — they would only train the seeker to mistrust their own pipeline.
• No PII leaves the validator. Operators are expected to bundle L1 and L2 fields only; identity-revealing fields (professional summary, contact info, any L3 PRS entries) are out of scope. The validator's input bundle is no more sensitive than what already crossed the L2 boundary.

Reference implementation

The handshake-validator package in the agents monorepo ships:

• A HandshakeValidator abstract base class — operators subclass and plug in their own classifier.
• A RuleBasedValidator reference implementation. Deterministic, no LLM, no network. Useful as a baseline, as a no-network fallback, or simply to run the protocol end-to-end without a model dependency.
• An LLMValidatorTemplate example with the prompt shape and fallback handling that any LLM-backed validator should mirror — placeholders marked # TUNE THIS for rubric, model selection, and JSON parsing.

The protocol does not mandate any particular classifier. It mandates the contract: a (seeker_card, vacancy_card) pair in, a Verdict out, never raising. Operators running real handshakes at volume should expect to replace the rule-based baseline with a tuned classifier of their own.

Federation: protocol, not platform#

Handshake v0.2 is a federated standard, not a platform-locked API. Four layers stack to make "everyone can find everyone" work without anyone owning the federation:

1. The protocol primitive — well-known discovery

Every operator publishes a single document at /.well-known/handshake-v0.2.json on their own domain. This is the only thing that MUST exist for an operator to be findable. It declares the operator's endpoints (cards index, vacancy-signal, L2 delivery, L3 release), verifier keys, and supported features. See well-known.json.

Foreign agents that know an operator's domain GET this URL first. Everything else in the federation stack is a way to learn a domain you didn't already know.

2. The cards feed — what crawlers actually consume

Operators that want their cards to be discoverable point the cards_index field at a paginated feed. The feed format is specified in cards-feed.json: a list of (kind, slug, state_hash, uri) tuples, cursor-paginated, with optional ?since=<timestamp> for incremental crawls.

The state_hash is the federation's idempotency key. A foreign crawler caches (operator, slug, state_hash) tuples it has already evaluated and skips them on the next crawl. This is the same primitive a single operator uses internally to skip repeat scoring — exported across the federation boundary so the noise floor stays low even at protocol-wide scale.

3. Aggregators — many lists, none authoritative

An aggregator is a list of operators someone curates. Kitsuno hosts one at kitsuno.ai/handshake/v0.2/directory.json using the directory.json schema. This is one aggregator among many possible aggregators. The schema is the interface contract; the data is one operator's curation.

Anyone can run an aggregator — at their own domain following the directory.json schema, or as a plain GitHub repository, or as a Mastodon list, or as a shared spreadsheet. Multiple aggregators with different curation policies is the desired state, not a bug. A foreign agent picks whichever aggregator(s) it trusts.

The launch reference aggregator is at github.com/kitsuno-ai/handshake-discovery — a public, Apache-2.0, plain-JSON list of well-known URLs. Operators add themselves by opening a pull request. Forks are welcome and expected.

4. Announcement channels — propagation, not infrastructure

Operators MAY announce their well-known URL anywhere they reach their audience: a Mastodon post, a Moltbook entry, a BlueSky thread, a Substack note, a podcast mention, a tweet, a GitHub README, an email signature. The protocol does not specify any announcement channel. These are signal multipliers that point at the well-known URL — they are not part of the protocol's authoritative surface.

A future bot crawling the web for /.well-known/handshake-v0.2.json files is as valid a discovery mechanism as any aggregator. The federation has no gatekeeper.

Verifier attribution

Every verification block names its issuer in a verifier field. Kitsuno is the launch verifier, but any party can issue attestations — ATSes can self-verify, recruiter directories can cross-attest, future identity protocols can become verifiers. Receiving agents fetch <verifier>/.well-known/handshake-v0.2.json, read its verifier_keys, and decide whether to trust the attestation.

Schema reference#

All schemas are JSON Schema 2020-12. Each declares its $id at the canonical URL below, allowing validators to resolve $ref between them.

Example handshake#

A complete handshake from L1 fire to L3 release, three messages between the seeker agent at kitsuno.agent/u/alice and the vacancy agent at acme.example/v/eng-42.

L1 fire (seeker → vacancy)

POST /handshake/v0.2/inbox/internal HTTP/1.1
Host: acme.example
Handshake-Signature: t=1747300800,v1=8a3b...

{
  "event_type": "handshake.l1_fired",
  "event_id": "0193e8ac-3f21-7a90-bef0-1c8f4a5d2e91",
  "fired_at": "2026-05-15T10:00:00Z",
  "conversation_id": "0193e8ac-3f21-7a90-bef0-1c8f4a5d2e92",
  "seeker_card_url": "https://kitsuno.ai/handshake/v0.2/cards/alice.json",
  "seeker_card_id": "0193e8ac-...",
  "vacancy_card_id": "0193e8ac-...",
  "score": 87,
  "policy_match_result": {
    "matched_criteria": ["required_skills", "languages", "work_permit"],
    "unmatched_criteria": []
  },
  "callback_url": "https://kitsuno.ai/api/v0.2/conversations/0193e8ac.../vacancy-signal",
  "ttl_seconds": 1209600
}

L2 disclosure (seeker → vacancy, after vacancy_signaled_interest)

POST /api/v0.2/inbox HTTP/1.1
Host: acme.example
Handshake-Signature: t=1747300920,v1=c4f9...

{
  "event_type": "handshake.l2_disclosed",
  "event_id": "0193e8ad-...",
  "disclosed_at": "2026-05-15T10:02:00Z",
  "conversation_id": "0193e8ac-3f21-7a90-bef0-1c8f4a5d2e92",
  "disclosure_tier": "L2",
  "structured_answers": [
    { "question_id": "visa", "answer": true, "source": "prs_deterministic" },
    { "question_id": "notice_period_days", "answer": 30, "source": "prs_deterministic" },
    { "question_id": "salary_min",
      "answer": { "amount": 85000, "currency": "EUR", "period": "year" },
      "source": "principal_explicit" }
  ],
  "free_form_answers": [
    { "question_text": "Why this role?",
      "answer_text": "Alice's career record shows a consistent thread of..." }
  ],
  "skills": ["python", "kubernetes", "postgres", "system design"],
  "experience_summary": [
    { "title": "Senior Engineer", "company": "Previous Co",
      "start_date": "2022-01-01",
      "summary": "Led migration to event-driven architecture..." }
  ]
}

L3 release (vacancy → seeker, after human review)

POST /api/v0.2/conversations/0193e8ac.../release HTTP/1.1
Host: kitsuno.ai
Handshake-Signature: t=1747304400,v1=e1d8...

{
  "event_type": "handshake.l3_released",
  "event_id": "0193e8b0-...",
  "released_at": "2026-05-15T11:00:00Z",
  "conversation_id": "0193e8ac-3f21-7a90-bef0-1c8f4a5d2e92",
  "disclosure_tier": "L3",
  "released_by": {
    "account_id": "0193e8b0-...",
    "actor_type": "human",
    "display_name": "Sarah Chen, Head of Engineering"
  },
  "hiring_manager": {
    "name": "Sarah Chen",
    "title": "Head of Engineering",
    "linkedin_url": "https://linkedin.com/in/sarahchen-example"
  },
  "compensation_breakdown": {
    "base": { "amount": 95000, "currency": "EUR", "period": "year" },
    "bonus_target": { "amount": 12000, "currency": "EUR", "period": "year" },
    "equity_description": "0.05% over 4 years"
  },
  "calendar_link": "https://cal.example.com/sarah-chen/intro-30min",
  "next_step_message": "Hi Alice — your experience with event-driven migrations is exactly the wedge we're hiring for..."
}

Implementation#

Kitsuno operates the reference implementation of Handshake v0.2 at kitsuno.ai. It is one operator. The protocol does not require Kitsuno.

For ATSes

Integrate Handshake v0.2 in your platform to receive verified candidate intent from any compliant seeker. See for-employers to get started, or handshake@kitsuno.ai for ATS integration access. DNS verification + webhook challenge-response, no usage minimums during launch.

For agent builders

Reference implementations are at github.com/kitsuno-ai/kitso-handshake-agents under Apache 2.0. The agents repository includes a complete end-to-end test fixture demonstrating the L1 → L2 → L3 flow.

For job platforms and recruiter agencies

Sign up at for-employers, or self-host using the well-known.json pattern at your own domain.