AgentTalk is condition-based access applied to agent-to-agent sessions. Built by SkyeMeta on InsumerAPI, it verifies that both agents meet the same on-chain conditions before a session begins — the same model as a Sensitive Compartmented Information Facility (SCIF), where everyone inside has been verified to the same clearance level before any information is shared. The entire product is built on three InsumerAPI calls: POST /v1/attest for the creator, POST /v1/attest for the joiner, and POST /v1/attest again for re-verification.
The problem: identity is not qualification
Agent protocols handle trust with shared secrets. Agent A presents an API key. Agent B decides whether to trust it. This is identity-based authentication — it proves who you are, not what you are qualified to handle.
In regulated environments, this fails. A trading agent needs to prove collateral positions, not just identity. A legal agent needs to prove its principal holds compliance credentials. A defense agent needs to prove clearance-equivalent attestations. None of these are identity questions.
AgentTalk replaces identity-based auth with qualification-based access. Both agents prove they meet a set of verifiable, on-chain conditions before any information moves. The conditions are composable — up to 10 per channel, across any mix of 33 chains.
The architecture: three API calls
AgentTalk is a thin session layer over InsumerAPI. The entire product runs on three endpoints that each call POST /v1/attest under the hood:
- Declare (
POST /api/agenttalk/declare): Agent A creates a channel with conditions and a wallet address. AgentTalk calls InsumerAPIPOST /v1/attestwithformat: "jwt"to verify Agent A's wallet. If the attestation passes, a channel is created with achannelIdand aconditionsHash(SHA-256 of the canonical JSON conditions). - Join (
POST /api/agenttalk/join): Agent B submits its wallet to the channel. AgentTalk calls InsumerAPIPOST /v1/attestagain with the same conditions for Agent B's wallet. If both pass, a session is created. Each agent's attestation JWT is stored with the session. - Re-verify (
POST /api/agenttalk/session): Either agent can re-verify the session at any time. AgentTalk callsPOST /v1/attestfor both wallets against the original conditions. If either fails, the session is invalidated and deleted.
Only the channel creator needs an InsumerAPI key. The joining agent provides only a wallet address — the creator's key covers both attestation calls. Free tier: 10 calls, no signup.
The combination is the security
A SCIF doesn't check one thing. AgentTalk supports up to 10 composable conditions per channel:
POST /api/agenttalk/declare
{
"wallet": "0x...",
"conditions": [
{ "type": "token_balance", "chainId": 1,
"threshold": 1000000, "decimals": 6,
"label": "USDC >= $1M on Ethereum" },
{ "type": "token_balance", "chainId": 137,
"threshold": 500000, "decimals": 6,
"label": "USDC >= $500K on Polygon" },
{ "type": "nft_ownership", "chainId": 1,
"label": "Series 7 attestation NFT" },
{ "type": "nft_ownership", "chainId": 1,
"label": "KYC credential" },
{ "type": "nft_ownership", "chainId": 8453,
"label": "NDA attestation on Base" },
{ "type": "eas_attestation",
"label": "Accredited investor (EAS)" }
]
}
Six conditions, three chains, both agents, all must pass. Each condition maps to a single InsumerAPI condition object — token_balance, nft_ownership, or eas_attestation. The API evaluates all conditions in a single call and returns a signed boolean per condition. The conditionsHash binds the exact conditions evaluated to the cryptographic proof.
Dynamic enforcement
Access in a SCIF is not permanent. Clearance lapses, and access is revoked. AgentTalk works the same way.
The re-verify endpoint (POST /api/agenttalk/session) re-attests both wallets live against the original conditions. If either agent's wallet no longer meets any condition — the Series 7 NFT was revoked, the USDC balance dropped below threshold, the NDA attestation expired — the session is invalidated and deleted from storage.
This is dynamic access enforcement. The session reflects current on-chain state, not the state at the time of issuance. Sell the token, lose the session.
What the API returns
Each agent's attestation is an ECDSA-signed (ES256, P-256) response from InsumerAPI, verifiable offline via JWKS:
{
"sessionId": "ses_51f5c240...",
"agents": [
{
"wallet": "0xd8da6bf2...",
"attestation": {
"attestation": {
"id": "ATST-74BB3943E691B5FF",
"pass": true,
"results": [{ "met": true, "conditionHash": "0x..." }],
"attestedAt": "2026-04-01T02:15:19Z"
},
"sig": "17/J229P4P/0F3qr...",
"kid": "insumer-attest-v1",
"jwt": "eyJhbGciOiJFUzI1NiI..."
}
},
{
"wallet": "0x55fe002a...",
"attestation": { ... }
}
]
}
Both attestations carry sig (base64 P1363), kid (insumer-attest-v1), and a full ES256 JWT. Any third party can verify either attestation offline by fetching the public key from the JWKS endpoint. No callback to InsumerAPI required at verification time.
Who uses this
AgentTalk is built for regulated industries where both parties must prove qualification before information moves:
- Finance & Banking: Two trading agents verify collateral positions before negotiating. Credit syndication agents verify capital commitments before sharing term sheets.
- Legal: Law firm agents verify both represent parties to the same matter before sharing discovery. M&A agents verify escrow deposits before accessing deal terms.
- Intelligence & Defense: Autonomous systems verify clearance-equivalent credentials before exchanging classified data. ITAR-controlled agents verify export compliance on-chain.
- Healthcare: HIPAA-qualified data exchange — agents verify compliance attestations before sharing patient data. Clinical trial agents verify IRB approvals across organizations.
The InsumerAPI integration
AgentTalk uses exactly one InsumerAPI endpoint: POST /v1/attest. Every call includes format: "jwt" to receive the full ES256 JWT alongside the raw signature. The conditions array is passed through directly — AgentTalk does not interpret, transform, or cache conditions. It is a session layer, not a verification layer. The verification is InsumerAPI.
InsumerAPI returns a conditionHash per condition (SHA-256 of the canonical JSON for that condition), embedded in each signed result. AgentTalk independently computes a conditionsHash over the entire conditions array (SHA-256 of the canonical JSON array) to bind the channel to its declared conditions. Both use sorted-key canonical JSON for deterministic output. Together they create a tamper-evident binding: the channel knows what was declared, and each attestation proves what was evaluated.
Storage is ephemeral with TTL-based expiry. Channels and sessions expire automatically. No persistent database, no user accounts, no PII.
What comes next
The session proves both agents were qualified. It does not prove what happened during the session. The natural extension is a co-signed interaction record — both agents sign a shared receipt of the session outcome. This is being explored with TrustChain (bilateral co-signed records) as a receipt layer that binds to the AgentTalk sessionId and conditionsHash.
The pipeline would be: InsumerAPI attestation proves wallet state (before), AgentTalk session proves both agents met conditions (during), TrustChain co-signed record proves both agents agree on the outcome (after). Three layers, independently verifiable, composable.
AgentTalk is live at skyemeta.com/agenttalk. The reference implementation is on GitHub. 10 free calls to start — no signup, no credit card.
Build your own session layer
InsumerAPI is free to start. AgentTalk is three API calls. Verify wallet holdings across 33 blockchains, compose conditions, enforce dynamically.
Get Your API Key