Bug: Remote invoke for invocations-protocol agents silently falls back to responses endpoint, fails with invalid_payload

[larrylhollan]

Bug: Remote invoke for invocations-protocol agents silently falls back to responses endpoint, fails with invalid_payload

Describe the bug

When running azd ai agent invoke against a deployed invocations-protocol agent, the remote invoke path silently falls through to the responses handler, which:

1. Posts to {endpoint}/agents/{name}/endpoint/protocols/openai/responses instead of the invocations endpoint
2. Includes a "conversation": {"id": ...} property in the request body
3. The endpoint-scoped responses API rejects this with HTTP 400: Endpoint-scoped response APIs are stateless and do not support conversation context. Remove the 'conversation' property.

This affects all invocations-protocol templates when vnext is enabled and protocol resolution falls back to the default (responses).

To reproduce

1. Deploy a hosted agent using an invocations-protocol template (e.g., Multi-Turn Chat Python /invocations from hosted-agents-vnext-private-preview/samples/)
2. Run: azd ai agent invoke multiturn-chat-invocations "My name is Alice and my favorite color is blue."
3. Observe HTTP 400 error with invalid_payload

Expected behavior

The invoke command should detect that the deployed agent uses the invocations protocol and route through invocationsRemote(), not responsesRemote().

Root cause (from source analysis of PR #7422)

In invoke.go, the Run() method dispatches like this:

if isVNextEnabled(ctx) {
    protocol := a.resolveRemoteProtocol(ctx)
    if protocol == agent_api.AgentProtocolInvocations {
        return a.invocationsRemote(ctx)
    }
}
return a.responsesRemote(ctx)

resolveRemoteProtocol() calls resolveAgentProtocol() (in helpers.go), which:

1. Resolves the agent service from azure.yaml
2. Reads the local agent.yaml manifest from the service directory
3. Returns the first protocol listed, defaulting to AgentProtocolResponses on any error

Failure mode: If the agent name passed to azd ai agent invoke <name> "message" does not match a service in the local azure.yaml, resolveAgentService() fails, protocol defaults to responses, and the request routes through responsesRemote().

Additionally, responsesRemote() with vnext enabled always includes "conversation": {"id": convID} in the body, but the endpoint-scoped responses API is stateless and rejects this property.

Suggested fixes

1. Primary: Select invocationsRemote() based on the deployed agent manifest (server-side), not just the local agent.yaml
2. Secondary: responsesRemote() with vnext should not include conversation for endpoint-scoped responses APIs (stateless APIs reject it)
3. Defensive: Log a warning when protocol resolution fails instead of silently defaulting to responses

Related issues

• choose which protocol to use for invoke #7492 — Adding a --protocol flag to azd ai agent invoke would serve as a user-facing workaround
• azd ai agent invoke works with the invocations protocol #7431 — Original invocations protocol support (closed)

Environment

• azd version: azure.ai.agents extension v0.1.20-preview (2026-04-02)
• OS: Linux (Ubuntu)
• Region: northcentralus
• Template: Multi-Turn Chat Python /invocations (hosted-agents-vnext-private-preview samples)

Additional context

Trace ID: f1855e1f-9508-4bb4-bafb-64822547d6d6
Request ID: 81d218c0d235edbb17c342d7d39ba14c

[rajeshkamal5050]

@therealjohn @trangevi — the silent fallback issue here got partially addressed with the --protocol flag (#7679) and resolveAgentProtocol now returns errors instead of defaulting. Can you check if this is fully resolved or if there are remaining edge cases? Thanks.