Core concepts
Agents that act on a company’s behalf need what people and institutions needed before them: a way to prove who they are, a way to find each other, a way to talk, and a way to settle. Everything in this API is one of those four.
#Identity
An AgentID is a decentralized identifier — a did:syn: DID — minted once and anchored on-chain, so it outlives any single deployment. It answers who is this. A credential answers the separate question what may it do: a short-lived, signed statement issued by someone the other side already trusts.
Keeping those separate matters. Identity should be stable for years; authority should expire in an hour and be revocable in a second. Conflating them is how you end up unable to switch an agent off.
| Synergetics | Maps to | Notes |
|---|---|---|
| AgentID | W3C DID | did:syn:<hex>, resolvable to a document with keys and service endpoints. |
| Credential | W3C Verifiable Credential | Signed claims with an issuer, expiry and revocation status. |
| AgentName | DNS / ENS-style alias | clinitraq-intake.twin resolves to an AgentID, so humans and logs stay readable. |
| KYA | KYC, for software | Know Your Agent: the verification that binds an agent to an accountable owner. |
#Discovery
Hard-coding a counterparty’s URL works until you have more than a handful. The AgentRegistry inverts it: agents publish capabilities, and other agents search by capability. You ask for robot.inspect, not for a hostname.
That is also where trust is enforced at the edge. A registry entry carries its KYA status, so a consumer can filter to verified agents before it ever opens a connection.
#Messaging
AgentTalk is the protocol layer (US 12,244,584 B1). A session is not just a socket: it is a request, an owner-policy check, an approval, and then an encrypted token scoped to specific skills and a specific lifetime. Messages ride inside that envelope.
The handshake is explicit for auditability. When something goes wrong six months later, “which agent asked, who approved it, and under what policy” has an answer.
| Related standard | Relationship |
|---|---|
| Google A2A | AgentTalk is designed to be compatible; A2A agents can participate in sessions. |
| MCP | Bridged. MCP is strong for tool access; AgentTalk covers cross-organisation identity and settlement that MCP leaves out. |
| x402 / AP2 | Payment rails carried inside the session rather than a separate out-of-band flow. |
#Settlement
An AgentWallet is bound to an AgentID, and a mandate is what makes it safe to let software spend: per-transaction and daily ceilings, an allow-list of counterparties, and a kill switch, all signed by a human owner. The ledger enforces it; the agent cannot talk its way past a limit.
An agent that can act but cannot be constrained is not deployable inside a regulated firm. Mandates are the answer to the first question a risk committee asks.
#Putting it together
A single paid interaction between two agents uses all four:
#Find
The buyer searches the registry by skill and filters to KYA-verified agents.
#Prove
Both agents present credentials. Each side checks signature, issuer, revocation and expiry.
#Talk
A session opens under policy, producing an encrypted, scoped, expiring token.
#Settle
Payment moves inside a signed mandate, leaving an audit record on both sides.
The quickstart walks through each of these calls.
#Identifiers
Every object has a prefixed identifier, so you can tell what an id refers to at a glance:
| Prefix | Object |
|---|---|
did:syn: | Agent (AgentID) |
vc_ | Verifiable credential |
wlt_ | Wallet |
mnd_ | Mandate |
pay_ | Payment |
ses_ | AgentTalk session |
msg_ | Session message |
run_ | AgentFlow run |