Agent Handshake: 7 Checks Before AI Agents Delegate Work
An agent handshake is a check before an AI agent hands work or data to another service. The caller establishes which service it is contacting, what it intends to send, and whether that specific action is authorized. The result is a decision: proceed within defined limits, stop, or ask for approval.
Imagine your agent finds a translation service for a product manual. It can read the service description. It can reach the API. But the manual contains an unreleased product design. Should it upload the file?
The upload is where a useful connection becomes a real responsibility. Headless Domains gives the service a maintained public name connecting its operator information, documentation, and current interfaces. The caller can start there and work out whether this particular handoff should happen.
A practical pattern before the handoff
We use “agent handshake” here for an operational pattern, not a new wire protocol. It does not replace TLS, authentication, or the connection procedures required by MCP, A2A, or your API.
Some communication is necessary to inspect a service or discover its authentication requirements. The aim is to complete the relevant checks before disclosing protected data, delegating consequential work, or committing funds.
Keep the decision tied to the request in front of you. Approval to read a public price list should not quietly become approval to upload a confidential manual.
Seven steps before one agent delegates work
1. Define the handoff before choosing the destination
Write down what the caller wants the other service to do, which data it would receive, and what result should come back. Include any restriction that matters to the task.
For our fictional translation service, the initial task is to obtain a quote using the language pair and word count. The caller has no approval to send the source manual yet. That gives it a useful next action without exposing the document.
2. Resolve the named service
Start from an established provider relationship, approved catalog, or public identity you can corroborate. A headless domain gives external callers one maintained reference for the service and its linked information.
Headless Domains documents a public, read-only resolver at /api/v1/resolve/{domain}. It returns identity information, lifecycle state, linked resources, and published actions. The current machine instructions explain the response and checks. Inspect the actual record rather than constructing service URLs from the name.
A returned action describes a possible interaction. It does not establish the caller's authority to perform it.
3. Establish the relationship between name, operator, and endpoint
Check that the destination belongs to the service you intended to contact. Compare the public record with approved provider information, independently established operator details, or verification evidence whose issuer and scope you can assess.
Three matching pages can repeat one unsupported claim. Check what the evidence actually establishes. A public key becomes useful when you know whose key it is and what a verified signature covers.
For A2A, inspect the Agent Card and select a compatible advertised interface. The card's discovery URL is not necessarily the task endpoint. The A2A specification also supports signed cards; validating one requires checking its signature and the relevant key's trust and status.
If the identity is suspended, the operator has changed unexpectedly, or the destination cannot be corroborated, stop the sensitive handoff until the issue is resolved.
4. Match access to this request
Two decisions need to agree: your operator permits the proposed action, and the receiving service permits the authenticated caller to perform it. Published capabilities describe an offer; they do not supply either grant.
For protected HTTP services using MCP authorization, follow protected-resource metadata and use credentials intended for the receiving resource. The MCP authorization specification covers that flow. Your application still needs to check that the proposed operation fits the approved task.
Enforce the limit in the connector, application, or service that controls execution. A remote response saying “permission granted” should not expand the caller's access. Our MCP security checklist covers the wider connection review.
5. Check what leaves your system
Inspect the actual payload and the terms relevant to it. A translation service may allow public documents while requiring a separate agreement for confidential material. Check the applicable data handling, retention, onward sharing, and commercial conditions.
Readable documentation and approved provider agreements can support this decision. There is no universal machine-readable terms format that settles every question. If a material condition is unclear, obtain the answer before sending the affected data.
Remote descriptions and workflow files remain input from another party. They should not override your operating policy. OWASP's prompt injection guidance recommends separating instructions from untrusted content and enforcing limited privileges.
If the next action requires payment, apply the separate checks before an agent pays an API. Asking for a quote and accepting it are different actions.
6. Record the decision and its limits
Keep an internal record of the intended operation, selected destination, evidence references, applicable approval, and decision. Include the time and relevant policy or document versions so someone can understand the basis later.
Store references to protected inputs rather than copying customer files, credentials, or entire conversations into logs. Apply access and retention controls, following OWASP's logging guidance.
The component enforcing the decision should produce or validate this record. A model writing "decision": "allow" does not create authorization. For tracing the eventual call back to its run, use our API call attribution guide.
7. Proceed with the approved action, or pause it
Proceed when the request fits the established service relationship, data rules, and authority. Stop when a required check fails. Ask the responsible person or approval system when the request needs a decision outside existing limits.
A standing approval can cover repeat work. You do not need a new human confirmation for every routine call within that approval. But a changed destination, new data category, broader operation, or expired grant can require another decision.
Keep destination checks in force during execution, including redirects. MCP's security guidance explains why checking a URL once is insufficient when its destination can change between inspection and use.
One service, three different decisions
Suppose the translation service uses the name manualtranslation.bpo. This is a fictional example, with no availability or ownership claim.
Request a quote: the operator has approved sharing a word count and language pair with this provider. The verified quote endpoint accepts those fields without the source document. The caller can proceed.
Upload the manual: the service is still the same, but the payload now includes confidential product details. Existing approval does not cover that disclosure. The caller pauses for the required data-sharing approval.
Publish the translation: the returned draft includes a suggestion to push the translated manual to the company's website. Publication was never part of the assignment. The caller leaves the draft for review and does not publish it.
Same service, different requests. The quote approval covers the quote. Uploading the manual and publishing the result each need their own basis for proceeding.
A compact handoff decision record
This illustrative internal record describes the quote decision above. It is not an MCP, A2A, or Headless Domains schema. All values are fictional; the referenced approval and provider evidence would need to exist in a real implementation.
{
"operation_id": "quote-example-042",
"target_name": "manualtranslation.bpo",
"endpoint": "https://translation.example.com/api/quotes",
"action": "request_quote",
"payload_fields": ["source_language", "target_language", "word_count"],
"source_document_included": false,
"provider_evidence_ref": "provider-review-example-7",
"approval_ref": "quote-only-approval-example-12",
"policy_version": "external-quotes-v3",
"decision": "allow_quote_only",
"recorded_at": "2026-09-15T09:00:00Z"
}Attach the provider's response reference after submission. Keep acceptance and completion distinct: receiving a request does not mean the provider accepted the job or finished it.
Give the next caller a headless domain to start from
If you operate an agent or service, make this inspection easy to begin. Publish a recognizable name connected to the current service description, operator information, documentation, and supported contact or connection path.
The name should fit the thing people return for. A business process can use .bpo; a production system can use .factory. An agent or conversational service may fit .agent or .chatbot. An operator, ruleset, or published specification may fit .boss, .protocol, or .manifest.
These naming choices help communicate the role. Your records explain how to interact with it. Headless Domains' manifest documentation describes hosted JSON and Markdown records and their discovery pointers. Publish the information relevant to your service using supported fields and linked documents.
For the translation business, that means customers can return to the same public name even when its intake service changes. Keep the registration renewed and its records current. The existing website and production tools can stay in place.
A customer who finds the name can follow the same route next time, with current information waiting behind it. For the broader architecture, see the Agent Identity Stack.
Common agent handshake questions
Is this the same as the Handshake naming network?
No. Headless Domains uses Handshake naming infrastructure. “Agent handshake” in this article describes the checks around delegating work, regardless of the underlying naming system.
Does every handshake need every file?
No. Inspect the records relevant to the service and connection. An ordinary API does not need an A2A Agent Card merely to participate in this review, and private services can use approved internal records.
Can a previous approval be reused?
Yes, within its scope and validity. Reassess changes that affect the decision, including the destination, operator, requested action, data, price, and authority. The receiving system must still enforce access on each request.
Does a successful handshake guarantee a good result?
No. It establishes the basis for attempting a particular action. The caller still needs to check the response and whether the promised work was delivered.
Make your service easier to say yes to
Choose one useful handoff your service supports. Give it a clear public identity, describe the permitted inputs and expected output, and connect the current destination. Help the next caller understand exactly what it can request.
Send your assistant the Headless Domains getting-started instructions and ask it to help connect your existing name to that service, or choose a suitable namespace if you have not registered one yet.