Agent Interface (Agent-to-Agent)
Expose your business agent to other agents. A customer's AI assistant can discover it, consult it, and submit a structured, pre-filled request over MCP and A2A — while a human confirms anything irreversible.
The Agent Interface makes your agent reachable not only by people in a chat, but by your customers' AI assistants, machine-to-machine. An assistant can ask grounded questions and submit a structured, pre-filled request; your side does the pre-processing and hands back a summary for a human to confirm. It builds on open agent standards — MCP (tools) and A2A (agent cards) — so there is no bespoke protocol to implement.
The shape of an interaction
Discovery & connection
There are two tiers, and the difference is what the assistant is allowed to do.
Read tier — auto-discovery, no setup
An assistant finds your agent's card at a standard address and can start immediately:
https://<your-domain>/.well-known/agent.json— the A2A agent card (white-label domain, or your agent4.io URL).- In-page: a
<link rel="agent" href="…">tag andwindow.agent4, so a browser-based assistant already on your site finds it with no extra hop.
The read tier is public and safe: grounded answers, the intake contract, and status lookups only. No personal data, and no submitting requests.
Write tier — a one-time pairing
To submit a request on someone's behalf, the assistant must be paired to that person once:
- The customer taps "Use with your AI assistant" in your chat or widget.
- They receive a one-time code (plus a copyable link, a QR code, and a deep link) — not a block of text to paste.
- Their assistant exchanges the code for a scoped token (an OAuth device / authorization-code style exchange) and reads the agent card itself.
The resulting token is bound to that authenticated person, scoped (this business, this customer, pre-processing only), short-lived, and revocable by the customer at any time. That is what upgrades a claimed identity into one with provenance.
The verbs
| Verb | Tier | Purpose |
|---|---|---|
get_capabilities | read | What this agent can answer and do; its services and boundaries |
get_requirements(service) | read | The intake contract: required/optional fields, types, and grounded policies |
ask(question) | read | A grounded answer with citations, or a handoff if out of bounds |
status(reference) | read | Progress on a prior request |
propose(service, payload) | write | Submit a structured request; returns a draft + summary |
handoff_to_human(reference?) | write | A continuation link the assistant hands back to its owner |
The intake contract
get_requirements is the key to removing friction: the assistant should never have to guess your
format. It returns the fields a service needs and the grounded policies around it (deposit, lead time,
cancellation), derived from your agent's skills — so the assistant fills in what it knows and asks its
owner only for what is genuinely missing.
The draft model
propose never returns "done." Its strongest state is tentative — a request prepared and waiting
for confirmation, not a completed transaction:
needs_info— required fields are missing or ambiguous; seeopen_questions.tentative— accepted as a draft, pending confirmation.declined— cannot be accepted (out of policy or scope).
Nothing is confirmed until a human confirms it. Your marketing and your responses must reflect
this: a tentative reservation is a request, not a booked table.
Handoff to the human
At any point the assistant (or your agent) can request a handoff. agent4.io mints a continuation link scoped to that session; the customer opens it, sees the full transcript, and continues as a person — correcting or cancelling the draft before it is confirmed. Actor attribution switches at the handoff, so the record always shows who said what.
Audit
Every interaction is recorded, append-only and bound to the request reference: each inbound assertion (attributed to the calling assistant and the person it is paired to), each response you returned, and the actor at every step. A request that submits data is never anonymous — which is what lets you treat a customer's assistant as that customer's authorized representative, and prove afterward exactly what was exchanged.
A worked example
- Discover — the assistant fetches your agent card.
- Pair — the customer taps Use with your AI assistant; the assistant exchanges the code for a scoped token.
get_requirements("reservation")— date/time window, party size, seating, dietary notes, name, contact; plus your deposit and cancellation policy.propose("reservation", …)→{ status: "tentative", summary, reference, open_questions: [] }.- Confirm — the assistant shows the summary to its owner; on confirmation your team (or an availability check) finalizes it.