fix(agents): resolve remote invoke name from inline service config

[glharper]

What

Remote azd ai agent invoke failed after initializing a unified azure.yaml against an existing (brownfield) Foundry project, even though the azure.ai.agent service and its agent name were declared inline.

The command failed with the misleading fallback error that an agent name was required.

Root cause

resolveAgentServiceFromProject populated AgentServiceInfo.AgentName only from the deployed environment output:

AGENT_<SERVICE>_NAME

That output is written after deployment. Brownfield init writes the hosted-agent definition — including its name — inline on the azure.ai.agent service, but does not create the deploy output. Therefore explicit-protocol remote invoke (--protocol invocations in the repro) resolved the service successfully but left the target agent name empty.

Using the azure.yaml service key as a fallback would be unsafe because the service key and deployed agent name may intentionally differ.

Fix

• Seed the resolved agent name from the inline/config-nested hosted-agent definition (project.AgentDefinitionFromService).
• Continue reading AGENT_<SERVICE>_NAME; when present, it overrides the inline definition because it reflects the resource actually deployed.
• Do not fall back to the service key.
• Keep malformed/missing inline definitions best-effort so existing deployed projects with environment outputs are not regressed.

This lets remote invoke work immediately for the reported brownfield/unified configuration while preserving deployed-name precedence after azd deploy.

Tests

• TestResolveAgentServiceFromProject_UsesInlineNameBeforeDeploy reproduces the issue: service key differs from the inline agent name and no AGENT_<SERVICE>_NAME exists. The inline name is resolved.
• TestResolveAgentServiceFromProject_EnvironmentNameWins verifies deployed environment output remains authoritative when it differs from the inline definition.

Validation

• go build ./...
• go test ./... -count=1 (all extension packages)
• go vet ./...
• gofmt clean
• golangci-lint run ./internal/cmd/... — 0 issues
• cspell — 0 issues

No CHANGELOG.md entry is included; extension changelog entries are added during the release process.

Fixes #9109

[github-actions]

📋 Prioritization Note

Thanks for the contribution! The linked issue isn't in the current milestone yet.
Thank you for logging this issue; our team is reviewing it. If you need urgent prioritization, tag @RickWinter and @kristenwomack to let us know.

[Copilot]

Pull request overview

Fixes brownfield remote agent invocation by resolving the deployed agent name from inline service configuration.

Changes:

• Uses inline hosted-agent names before deployment outputs exist.
• Preserves environment output precedence.
• Adds regression tests for both resolution paths.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
internal/cmd/helpers.go	Adds inline agent-name fallback resolution.
internal/cmd/helpers_test.go	Tests fallback and deployed-name precedence.

[jongio]

Verified the fix locally. Seeding the agent name from the inline hosted-agent definition before reading AGENT_<SERVICE>_NAME correctly fixes brownfield pre-deploy remote invoke, and the environment output still wins once it exists since it's applied after. All callers already guard on a non-empty AgentName, so no downstream regression. Both regression tests pass here.

[trangevi]

This feels like the wrong fix to me. If I understand what we're doing correctly, we're resolving the agent name from the azure.yaml, because the env var that we populate at deployment time doesn't exist. This means we haven't deployed yet, which also means we shouldn't be able to invoke that agent. Adding handling which allows a user to invoke against a previously existing deployed agent just because the names match has the potential to lead to unexpected confusion due to different code, protocols, etc.

In the case where a user has an azure.yaml without the corresponding env var, we should probably fail invoke, saying that the agent doesn't appear to have been deployed yet.

If the claim in the corresponding work item is that users should be able to invoke agents in existing projects by redefining the agent in the local azure.yaml, I don't think that's correct. They can already invoke without the need for an azd project at all, we added that support, I don't think we should introduce this potential logic split.

[jongio]

I traced the remote invoke path to sanity-check @trangevi's concern about invoking before deploy.

The endpoint isn't gated on deploy. In project mode, resolveRemoteContext gets the project endpoint from resolveAgentEndpoint then resolveProjectEndpoint (the Foundry project cascade), which resolves from stored project context rather than AGENT_<SVC>_ENDPOINT. So once the name is set, invoke builds <project>/agents/<name>/... and calls it whether or not azd deployed anything. The concern is real in that sense: if the resolved Foundry project already has an agent with the inline name, a pre-deploy invoke will hit it.

The thing is, that capability already exists without this PR. azd ai agent invoke <name> with an explicit name has always seeded rc.name from the arg, resolved the same endpoint, and invoked with no deploy required. --agent-endpoint does the same. What this PR changes is narrow: it auto-fills the name from the azure.yaml agent definition when the user omits it, instead of erroring with "agent name is required".

So the real question isn't "should undeployed agents be invokable", since the explicit-name and --agent-endpoint paths already allow that today. It's whether the azure.yaml-defined name should auto-resolve to match those paths or stay stricter. For the brownfield adopt flow this targets (init against an existing Foundry project that already contains the agent), auto-resolving to the inline name lands on the agent the user actually adopted.

If we do want a guard, the cleaner spot is a pre-invoke "not deployed / agent not found" check that applies to all three name-resolution paths, so the behavior stays consistent regardless of how the agent name is supplied.