Back to all discussions

  •   9 days ago

External A2A agent - SendA2AMessage always returns "did not respond with a task" despite valid Task on the wire

Hi PO team,
External A2A agent registered and Connected. Manual consult from the General Chat Agent fires SendA2AMessage with the correct externalAgentId. FHIR context (fhirToken, fhirUrl, patientId) arrives in message.metadata as expected. My agent runs end-to-end and returns HTTP 200 OK with a valid JSON-RPC 2.0 envelope containing a populated Task object.

Every consult still ends with:
{ "content":[{"type":"text","text":"The external agent did not respond with a task"}], "isError": true }

The General Chat Agent then composes its own fallback answer instead of rendering the consulted agent's response.

Stack: built from the po-adk-python template (google-adk 1.18.0, a2a-sdk[http-server] 0.3.22, Python 3.11 on Cloud Run, ADK to_a2a wiring untouched). Reproduced on both an ngrok-free.dev URL and on a Cloud Run URL, so it is not a transport / proxy / TLS issue.

What I have already tried, none of which changed the outcome:
- Method-name handling: PO sends SendMessage and SendStreamingMessage (PascalCase). I rewrite to message/send and message/stream so the SDK accepts the JSON-RPC payload and validation succeeds.
- role handling: PO sends ROLE_USER. I rewrite inbound to "user" so Pydantic accepts it.
- Response shape: I have tried both A2A v0.2 (kind discriminators on Task/Message/Part) and v1.0 (no kind, OneOf parts), and both lowercase ("completed") and proto-style ("TASK_STATE_COMPLETED") for status.state. Outbound history role tested as both "user"/"agent" and ROLE_USER/ROLE_AGENT.
- Required Task fields all present: id, contextId, status, artifacts (with artifactId and non-empty parts), history.

In every variant the response is HTTP 200 with a parseable Task in the result field, and PO's SendA2AMessage tool still raises "did not respond with a task". The error is raised after a 200 OK from the agent, so the response is being received but rejected by the validator on PO's side.

Could engineering clarify:
1. What exact A2A schema version does SendA2AMessage validate against — v0.2 (kind-discriminated Task/Message/Part) or v1.0 (OneOf parts, no kind field)?
2. For status.state and message.role: lowercase string values per the A2A spec, or proto-style enums (TASK_STATE_COMPLETED / ROLE_AGENT)?
3. Is there a server-side log entry keyed on the JSON-RPC request id (or the taskId my agent emits) that records where the validator rejects? Or a known set of conditions that produce this specific "did not respond with a task" error string?
4. Same path used by Orchestrator/BYO consults, or a separate code path for External agents?

Live agent card (no auth required, GET only):
https://homeward-434257808344.us-central1.run.app/.well-known/agent-card.json

  • 2 comments

  • Manager   •   9 days ago

    Hello,

    1. We use v1 of the a2a specification
    2. We follow the a2a specification, we do not enforce or support custom sdk style messages if this is what you mean.
    3. We check to see if your response has a $.result.task object. Review the specification here: https://a2a-protocol.org/latest/specification/#61-basic-task-execution
    4. The orchestrator does not use a2a to communicated with linked byo agents. Only external agents you select as part of the dropdown in your chat interface uses a2a to communicate.

    My recommendations:

    - Ensure that your agent is returning a response in the format specified by the a2a specification (v1).
    - If you can also provide us the exact JSON your agent is returning to us, we can see if there are issues with the structure of it preventing us from parsing it.

  •   •   9 days ago

    Thanks for your advice Mahbubul! It worked! ✨

Log in or sign up for Devpost to join the conversation.