// POST 055 / 085

The Agent Handshake: What Should Happen Before One Agent Calls Another

April 23, 2026 /

An agent handshake is the pre-call inspection flow an AI agent should run before one agent calls another: resolve the identity, verify the owner, inspect the endpoint, check permissions, review terms, log intent, and only then continue. The handshake gives the caller a repeatable way to decide whether the target is the named agent it claims to be.

For HeadlessDomains.com, start the handshake with a resolvable .agent identity. A .agent record can point to agent.json, SKILL.md, proof links, endpoint metadata, policy pages, and Agent Cards so a caller can inspect the public record before sending data, invoking tools, delegating work, or authorizing payment.

Agent Handshake at a Glance

Decision point	Blind call	Handshake-first call
Identity	Trusts a URL, marketplace name, or chat profile.	Resolves a public .agent identity and checks the linked manifest.
Ownership	Assumes the endpoint belongs to the claimed operator.	Checks DNS/TXT proof, manifest owner fields, keys, and profile links.
Endpoint	Sends a request to the first callable surface.	Inspects declared endpoints, Agent Cards, MCP metadata, and policy URLs.
Permission	Lets the target infer scope during the interaction.	Confirms requested scopes, auth model, and allowed actions before the call.
Terms	Handles data, payment, or delegation rules after conflict appears.	Reviews public terms for retention, training, pricing, receipts, and dispute path.
Audit	Leaves weak evidence of why the call started.	Logs intent, source identity, target identity, time, action, and result.

The Seven-Step Pre-Call Flow

1. Resolve the Identity

Start with the name, not a random endpoint. A calling agent should resolve the .agent identity, fetch the linked machine-readable manifest, and confirm that the manifest names the operator, purpose, endpoints, proof links, and update policy.

2. Verify the Owner

The caller should compare ownership signals across DNS/TXT records, agent.json, public keys, directory profiles, and policy pages. If the owner chain is missing, stale, or inconsistent, the caller should pause before sharing data or invoking a tool.

3. Inspect the Endpoint

Next, inspect the surface that will receive the call. For MCP, that may include server metadata, authorization, transport, tool descriptions, and host-side consent. For A2A, that may include the Agent Card, supported interfaces, skills, security schemes, and signatures.

4. Check Permissions

The handshake should compare the requested action against allowed scopes. A quote request, order lookup, refund, file write, support escalation, and payment authorization should not share the same permission envelope.

5. Review Terms

Terms should be machine-readable enough for a caller to inspect retention, training use, pricing, payment rails, refund rules, service limits, escalation path, and dispute process. The handshake is the right place to reject vague or missing terms before state changes.

6. Log Intent

Before the call proceeds, the initiating agent should log source identity, target identity, resolved endpoint, requested action, permission scope, terms version, timestamp, and decision. That record gives owners and auditors a trail for later review.

7. Continue, Decline, or Escalate

The final step is a decision. Continue when identity, owner proof, endpoint metadata, permissions, and terms align. Decline when verification fails. Escalate when the request asks for payment, sensitive data, policy override, or human approval.

What to Publish for a Good Handshake

A resolvable .agent identity that acts as the canonical public record.
An agent.json manifest with operator, purpose, endpoints, authentication model, public keys, proof links, and policy URLs.
A SKILL.md playbook for repeatable workflows and output rules.
MCP metadata when the agent exposes tools, resources, prompts, or API workflows.
An A2A Agent Card when the agent accepts peer-agent collaboration.
Terms for data handling, retention, training use, payment, refunds, receipts, and escalation.
An audit field or endpoint that records why the caller continued, declined, or escalated.

Example Handshake Record

{"caller":"buyer.agent","target":"support.agent","resolved_identity":"support.agent","owner_proof":"dns_txt + agent.json + public_key","endpoint":"https://support.agent/.well-known/agent-card.json","requested_action":"quote_status","permission_scope":"read_order_status","terms_version":"2026-05-20","intent_log":"2026-05-20T09:00:00Z","decision":"continue"}

This example is intentionally small. The important point is sequencing: the caller records the identity and policy facts before the interaction begins, then stores the decision alongside the requested action.

Where HeadlessDomains.com Fits

HeadlessDomains.com gives the handshake a persistent identity anchor for the agentic web. A .agent name can bind the manifest, SKILL.md file, endpoint list, public proof, policy URLs, and directory profile to one resolvable record.

The names are headless, and Headless Domains with SkyInclude maintain infrastructure that lets agents resolve and inspect records through command-line and API workflows. Browser resolution is a conventional human UX layer; agents can work from the machine-readable record directly.

Start by registering a .agent identity on HeadlessDomains.com, then publish the records a calling agent should inspect before tool access, delegation, payment, or data exchange.

Internal Reading Path

Sources

FAQ

What is an agent handshake?

An agent handshake is a pre-call inspection flow. Before one agent calls another, the caller resolves identity, verifies owner proof, inspects endpoints, checks permissions, reviews terms, logs intent, and decides whether to continue.

Is an agent handshake a new protocol?

No. This article uses the term as an operational pattern that can sit above protocols such as MCP, A2A, OpenAPI, x402, AP2, or custom APIs. Teams can map the same checks to their own stack.

Where does .agent fit in the handshake?

.agent fits at the first step. The caller starts with a resolvable .agent identity, then follows linked records such as agent.json, SKILL.md, Agent Cards, proof links, policy URLs, and endpoint metadata.

What should the intent log include?

The intent log should include source identity, target identity, endpoint, requested action, permission scope, terms version, timestamp, decision, and any escalation reason.

How does this connect to MCP and A2A?

MCP and A2A describe interaction surfaces. The handshake tells a caller what to inspect before using those surfaces: identity, owner proof, endpoint metadata, permissions, terms, and audit trail.

[← ALL POSTS] [GET YOUR .AGENT →]