Skip to main content
Wildo.ai Coming soon

Agent protocols

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.

Two A2A dialects translate to a common application conversation.

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 operationEarlier methodLater method
Send a messagemessage/sendSendMessage
Read a tasktasks/getGetTask
Cancel a tasktasks/cancelCancelTask
Follow task updatestasks/resubscribeSubscribeToTask

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.

Building a B2B product or an internal tool?

Wildo is not self-service yet. Tell us what you have in mind and we will say plainly whether it fits, and what happens next.