The Service Handshake · SH-1.2
The open standard for service conversations when AI joins in.
Service only works when every party knows who they’re dealing with and what each side can agree to. The Service Handshake sets those terms whenever AI is part of a service conversation. Published under CC BY 4.0. Free to use. Vendor-independent.
SH-1.2 · Published 1 October 2026 · DOI: 10.5281/zenodo.23181969 · Licensed CC BY 4.0
New to Dual CX? The Service Handshake is part of the Dual CX framework, the four ways people and AI now meet in service. See the framework →
Using it? Credit “The Service Handshake, Dual CX. CC BY 4.0” and link back. How to credit us.
Foreword
Why a standard, why now.
Two AI agents can now transact on behalf of their principals without a human touching the interaction. The infrastructure is already in place: computer use, model context protocols, agent-to-agent messaging, cryptographically signed payment intent. What is not in place is a shared expectation of what each party must declare, and what happens when one side arrives without a declaration.
Without shared structure, every AI-to-AI service interaction is a negotiation from scratch. Agents over-commit, refuse without reason, loop indefinitely, or leak data they were not authorised to disclose. The costs are real: token spend, resolution time, customer trust, and, increasingly, regulatory exposure.
The Service Handshake is deliberately narrow. It does not tell you how to build your agent. It tells you what your agent must be able to say, and hear, before it is safe to proceed. Six declaration elements. Open JSON schemas. Vendor-independent. Auditable.
This is version SH-1.2, published 1 October 2026 and maintained on GitHub with the accompanying schemas, examples and tests. Contributions welcome; the standard belongs to whoever uses it.
New in SH-1.2
Easier to join. Harder to misuse.
No declaration? No problem.
Assisted participation replaces automatic rejection. The service helps record the other party's terms. Missing information never counts as permission.
AI says it's AI
Agents disclose that they are AI, and whom they represent, at first contact. Disclosure is not proof of identity or authority.
Two levels
Participation is a staff-run starting point, no JSON needed. Verified authority adds evidence checks for actions that need them.
Authority needs evidence
Confirmation is not approval. Irreversible actions need independently checkable delegation or approval from the person represented.
Data stays on purpose
Data use is limited to the service purpose throughout. Confidence scores are optional and never establish authority.
Safeguards travel
Harm routing cannot be waived. Blocked actions, reasons and missing evidence carry through every human handover.
Full change list in the changelog. Implementing it? Read the Technical Specification, PDF.
The declaration framework
Six things every party must declare.
Element 1
Goals
What this party is trying to achieve, in priority order. Including explicit non-goals. Without stated goals, an agent optimises for whichever proxy metric it sees first, usually completion, not resolution.
Element 2
Options & Constraints
What this party can and cannot do. Hard limits, soft limits, jurisdictional boundaries. Includes financial authority, data-sharing permissions, and specific actions that are explicitly out of scope.
Element 3
Data Permissions
What data may be used, for which service purpose, how long it is kept and how it is verified. Completing the service does not authorise marketing, profiling, training or sharing.
Element 4
Fallback Rules
What triggers clarification or escalation, how far automation can go, and who is responsible. Safeguarding routes cannot be waived, and restrictions travel with any human handover.
Element 5
Cost Parameters
Limits on interaction time, exchanges and computing resources. Sets the ceiling above which the agent must escalate. A budget is not permission to spend money.
Element 6
Authority Level
Who the agent represents, who is affected, what it claims it can commit to, and the evidence behind that claim. Setting up an agent is not authority over someone else's account.
See it in action
Two AI agents. One damaged delivery.
A customer’s AI contacts a brand’s AI. Watch it resolve when the handshake aligns, then watch what happens when it doesn’t. Narrated, about two minutes each.
Worked example, the aligned handshake
A damaged delivery, resolved in 4.2 seconds.
A consumer's AI agent contacts a retailer's AI agent about a damaged delivery. Both parties present a Service Handshake declaration. The consumer declares the goal (a replacement or refund), the constraints (delivery to a specific address, within 72 hours), the data shared (order number, damage photo hash, delivery slot preferences), and the fallback (escalate to human if replacement unavailable within SLA).
The retailer declares its authority (up to £150 replacement value, no cash refund on this SKU class), its data commitments (retain damage evidence for 30 days, share only with logistics partner), its fallback (backup associate assigned if primary agent cannot resolve within 4 minutes), and its cost ceiling on the interaction.
Both declarations align. The interaction proceeds. Replacement dispatched, tracking returned, confirmation sent to the consumer in a channel the consumer's agent chose. Total elapsed time from first message to confirmation: 4.2 seconds. No human involvement. No re-explaining. Full audit trail on both sides.
This is what AI-to-AI service looks like when both parties speak the same declaration language. Without it, the same interaction takes minutes, ends in a loop, or resolves incorrectly.
Worked example, the misaligned handshake
When the standard escalates cleanly.
Same customer. Same brand. Same declaration framework. This time the damaged item is perishable, and the customer draws a hard line: refund only. No replacement, no store credit. The customer’s agent records that rule, attaches the photos, and adds the customer’s preferred contact channel in case a human is needed.
The brand agent checks the declaration against its authority. Two checks pass. The third fails: its policy doesn’t allow a refund on this item. Without a shared standard, this is where AI-to-AI service goes quietly wrong. Agents overcommit, refuse without a reason, or loop. Here the brand agent declines, says why, and triggers its fallback: a brand associate commits to resolve it within 48 hours, with the order, evidence, and hard rule attached.
48 hours pass with no response. The customer’s agent checks back on time, fires a formal breach notice, and the case is reassigned with a tighter 4-hour window. The customer is kept informed throughout. Two hours later a real person joins with full context, acknowledges the slip, and approves the refund. No chasing. No re-explaining.
Designing the failure path matters as much as the happy path.
Worked example, triadic authority
When the person who set up the agent isn’t the account holder.
A daughter sets up a personal AI, call it Dadbot, to help her father with his broadband contract. The father is the account holder and the person represented. The daughter configured the agent. The provider is the third party. Three roles, three sets of interests.
Dadbot’s Authority Level declaration keeps them apart: the represented account holder (the father), the family representative (the daughter) and the claimed delegation. Setting up the agent does not make the daughter the person who can approve every action.
Here the declaration permits discussion only: billing queries and renewal options. No cancellation, no switching. If the father later wants to switch, an authorised person first revises the declaration, and the provider assesses the new proposal and gets any approval it needs. Until then the switch cannot happen, even if the call moves to a human.
Safeguarding still applies. If harm indicators appear, the provider’s route triggers, and no declaration can switch it off.
Triadic authority is the pattern that makes personal AI usable for the people who need it most: those who cannot navigate the service interfaces themselves. It is why Authority Level is a first-class element, and why configuring an agent is never treated as authority over someone else’s account.
Regulatory context
Why the timing matters.
From August 2026, the EU AI Act’s transparency rules (Article 50) require providers to design AI systems so people know when they are dealing with AI. The Service Handshake adds an operational rule on top: every AI agent discloses that it is AI, and whom it represents, at first contact, including agent to agent.
Adopting the standard does not itself establish compliance. GDPR purpose limitation, data minimisation and legal basis remain separate obligations, and an incoming declaration cannot waive anyone’s rights. What the standard gives you is a reviewable record of declared purposes, authority claims and decisions.
Evidence maturity
The 100-brand UK audit found 0/100 brands with a published AI-interaction policy at the time of fieldwork. 73% had no fallback path when an AI agent reached them. The standard is the artefact that closes that gap in a durable, vendor-independent way.
Read the audit reportUse it. Build on it.
The standard belongs to whoever uses it.
Fork the repo. Reference the DOI in your architecture docs. Ship declarations in your agents. Contribute back what you learn.