
Support different agent clients through one interface
Agent clients can use different wire vocabularies while reaching the same application behavior. Wildo translates supported A2A method names and response shapes at the transport boundary.
Your actor systems do not need separate implementations for each client vocabulary.
Example — Keep an existing integration working
An older integration asks for tasks/get; another uses GetTask. Both address the same underlying task operation while receiving their expected response vocabulary.
For engineers
The implementation distinguishes its 0.2.5 and 1.0 dialects from method names. These two request bodies illustrate the same task lookup; use a task owned by the authenticated caller:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tasks/get",
"params": { "id": "owned-task-id" }
}
{
"jsonrpc": "2.0",
"id": 1,
"method": "GetTask",
"params": { "id": "owned-task-id" }
}
Both examples need the published agent URL and a Bearer token for that audience. The exact request fields accepted by a client SDK should follow its dialect; the transport normalizer adapts them before service dispatch.
Start work without waiting for the answer
These paired examples follow Wildo’s dialect normalizer and task projection. POST either body to the published agent URL with Content-Type: application/json and a Bearer token for that endpoint audience. The messages are alternatives, not two steps of one turn. They select the published todo-assistant skill; replace metadata.skillId with a skill ID from the chosen card. A card exposing several skills requires an explicit selection.
Earlier vocabulary, requesting a nonblocking turn:
{
"jsonrpc": "2.0",
"id": 10,
"method": "message/send",
"params": {
"message": { "role": "user", "messageId": "request-10", "parts": [{ "kind": "text", "text": "Summarize my current tasks." }] },
"metadata": { "skillId": "todo-assistant" },
"configuration": { "blocking": false }
}
}
Representative successful task creation response; IDs and timestamp are illustrative:
{
"jsonrpc": "2.0",
"id": 10,
"result": {
"kind": "task",
"id": "task-10",
"contextId": "conversation-10",
"status": { "state": "working", "timestamp": "2026-09-12T09:00:00.000Z" }
}
}
Later vocabulary expresses the same choice with an inverted flag:
{
"jsonrpc": "2.0",
"id": 11,
"method": "SendMessage",
"params": {
"message": { "role": "user", "messageId": "request-11", "parts": [{ "kind": "text", "text": "Summarize my current tasks." }] },
"metadata": { "skillId": "todo-assistant" },
"return_immediately": true
}
}
The response retains the task shape while changing the state vocabulary:
{
"jsonrpc": "2.0",
"id": 11,
"result": {
"kind": "task",
"id": "task-11",
"contextId": "conversation-11",
"status": { "state": "TASK_STATE_WORKING", "timestamp": "2026-09-12T09:00:00.000Z" }
}
}
Keep the returned task ID for tasks/get or GetTask; contextId identifies the conversation, not the task. Subsequent lookups may report completion, failure or an input request. The local normalizer also accepts returnImmediately for the later flag.
Task creation can fail: this implementation then falls back to a blocking message reply. Check result.kind before starting a task-following loop. A direct message stream is a different path and normally returns message frames; an approval pause can materialize a task. Use the task follow-up example when you have received a task.
Translate the whole exchange
The boundary maps method names, task-state spelling and non-blocking configuration, then serializes replies for the detected dialect. Merely renaming the request method would leave a client misreading the response.
| Internal operation | Earlier method | Later method |
|---|---|---|
| Send a message | message/send | SendMessage |
| Read a task | tasks/get | GetTask |
| Cancel a task | tasks/cancel | CancelTask |
| Follow task updates | tasks/resubscribe | SubscribeToTask |
Not every operation has a counterpart in both dialects: the implementation’s task listing is a later-dialect operation. Read the published agent card and use a compatible client rather than assuming a one-to-one replacement for every method.