fix(agents): resolve remote invoke name from inline service config by glharper · Pull Request #9114 · Azure/azure-dev

glharper · 2026-07-13T14:52:05Z

What

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

Root cause

Project-mode invoke normally gets the deployed agent identity from AGENT_<SERVICE>_NAME, which is created by deployment. Brownfield adoption can point azure.yaml at an existing Foundry project/agent without producing a new deploy output, leaving automatic name resolution empty.

Fix

The final implementation distinguishes intentional brownfield adoption from an undeployed greenfield service and scopes the behavior to invoke only:

Remote invoke only opts into inline-name resolution when the agent's uses: list references an azure.ai.project service with a non-empty endpoint. This is the explicit brownfield signal.
Shared resolver callers — including destructive commands such as delete — remain env-only and cannot implicitly target an adopted agent.
AGENT_<SERVICE>_NAME remains authoritative whenever deployment output exists.
The brownfield fallback is used only after the active environment was read successfully and the name key was confirmed absent/empty. Transient/auth/daemon lookup failures do not trigger it.
Auto protocol detection caches an azure.yaml service key; when no deployed/brownfield name resolves, that cached selector is cleared. If the second service resolution fails, the error is surfaced rather than treating the cached service key as a Foundry agent name.
A greenfield service with no deployment output fails with a dependency error (missing_agent_env_vars) and guidance to run azd deploy.
Explicit agent-name and --agent-endpoint invocation remain unchanged for users intentionally targeting an existing agent without deployment.
The azure.yaml service key is never used as the implicit agent-name fallback because service and deployed agent names may differ.

This preserves the reported brownfield workflow while preventing greenfield or shared/destructive commands from silently targeting an older live agent with matching name but different code or protocols.

Tests

Brownfield uses: + project endpoint resolves the inline name only through invoke's opt-in resolver option.
The default shared resolver does not return the brownfield inline name.
Greenfield project with no endpoint does not resolve the inline name.
Deployed environment output overrides the inline name.
Transient env lookup failure does not enable the fallback.
Auto protocol clears a cached service selector when no target name resolves; explicit protocol preserves an intentional direct name.
Missing deploy output returns dependency-category azd deploy guidance with CodeMissingAgentEnvVars.

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

Brownfield init against an existing Foundry project writes the hosted agent name inline in the azure.ai.agent service, but does not populate the deployed AGENT_<SERVICE>_NAME environment output. Remote invoke only consulted that env value, so an otherwise valid unified azure.yaml service resolved with an empty agent name and failed with the misleading "agent name is required" error. Seed AgentServiceInfo.AgentName from the inline/config-nested hosted-agent definition, then let AGENT_<SERVICE>_NAME override it after deployment. Do not fall back to the azure.yaml service key because the service and deployed agent names may intentionally differ. Adds regression coverage for pre-deploy/brownfield inline-name resolution and for deployed environment output retaining precedence. Fixes #9109 Co-authored-by: Copilot <[email protected]> Copilot-Session: ea5e8124-350f-4420-b3dc-f88011b2aa74

github-actions · 2026-07-13T14:52:22Z

📋 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 · 2026-07-14T00:21:23Z

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.

Addresses review feedback on PR #9114. Using every inline azure.yaml agent name as a pre-deploy fallback could silently invoke an older live agent with matching name but different code or protocols. Only use the inline name when the agent explicitly depends on an azure.ai.project service with a non-empty endpoint, which is the brownfield adoption signal from the reported scenario. Greenfield services without AGENT_<SERVICE>_NAME remain blocked and now receive an actionable "deploy first" validation error. Explicit agent names and --agent-endpoint continue to support intentionally invoking existing agents without deployment. Deployed AGENT_<SERVICE>_NAME remains authoritative. Adds tests for brownfield fallback, greenfield rejection, env precedence, and the improved error. Co-authored-by: Copilot <[email protected]> Copilot-Session: ea5e8124-350f-4420-b3dc-f88011b2aa74

glharper · 2026-07-14T16:59:02Z

Addressed the review discussion in f67f8a7 after reading all comments.

@trangevi — agreed that a broad inline-name fallback was too permissive: a greenfield, undeployed azure.yaml could accidentally target an older live agent with matching name but different code/protocols. The fallback is now limited to the reported brownfield adoption shape: the agent must use an azure.ai.project service with a non-empty endpoint. Otherwise, absent AGENT_<SERVICE>_NAME produces a structured “run azd deploy first” error.

@jongio — this retains the intentional existing-agent capability you described. Explicit name and --agent-endpoint remain unchanged, and brownfield adoption can still auto-resolve the inline name because the existing-project endpoint is explicitly declared. Deployed env output still wins.

Added focused tests for brownfield fallback, greenfield rejection, deployed-name precedence, and the improved error. Full extension validation remains green.

Copilot

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

jongio

Re-reviewed the reworked approach against the new commit. Gating the inline fallback on brownfield adoption (agent depends on an azure.ai.project service with a non-empty endpoint) preserves the #9109 fix while stopping a greenfield service from silently invoking an older live agent that shares the inline name. The deployed AGENT_<SERVICE>_NAME output still overrides, and greenfield now returns an actionable deploy-first error. Brownfield, greenfield, and env-precedence tests pass locally.

Non-blocking: the deploy-state branch is a missing-output case, so exterrors.Dependency with CodeMissingAgentEnvVars lines up with evalAgentContextError and the category table in the extension AGENTS.md better than Validation/CodeInvalidParameter. Fine as a follow-up.

A final call-site audit found that the shared agent resolver is also used by destructive commands such as delete. Applying the brownfield inline-name fallback globally could let delete target an adopted pre-existing agent before azd had deployed it. Make brownfield inline-name resolution an explicit resolver option and enable it only from remote invoke. All other commands retain env-only deployed-name resolution. The regression test asserts the default shared resolver does not target the brownfield agent, while invoke's opt-in path still resolves it. Co-authored-by: Copilot <[email protected]> Copilot-Session: ea5e8124-350f-4420-b3dc-f88011b2aa74

glharper · 2026-07-14T17:14:55Z

Follow-up 5db0605 scopes the brownfield inline-name fallback to remote invoke only after a full call-site audit found the shared resolver is also used by destructive commands such as delete. Shared callers remain env-only, so they cannot implicitly target an adopted pre-existing agent. The brownfield invoke path still works via an explicit opt-in resolver option; greenfield deploy-first behavior and env precedence are unchanged. Full validation remains green.

Copilot

Pull request overview

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

Address review feedback by reporting a missing AGENT_<SERVICE>_NAME deployment output as exterrors.Dependency with CodeMissingAgentEnvVars, matching existing agent-context error classification. Assert the stable code and dependency category in the invoke error test. Co-authored-by: Copilot <[email protected]> Copilot-Session: ea5e8124-350f-4420-b3dc-f88011b2aa74

Check adopted agent names against the selected existing Foundry project, require confirmation before reuse, and persist replacement names when declined. Co-authored-by: Copilot <[email protected]> Copilot-Session: ef953bfc-0f9a-477e-aef6-7e703f7e4bee

glharper · 2026-07-15T16:02:19Z

Addressed the review feedback in commit 4936d3b1d:

Brownfield unified azure.yaml init now checks each declared agent name against the selected existing Foundry project.
A collision shows the existing-agent warning and requires an explicit, default-No confirmation before mirroring that agent.
Declining prompts for a unique replacement name and persists it back to azure.yaml.
The PR's intentional brownfield invoke behavior remains unchanged after that opt-in.
Added regression coverage for inline, workflow, legacy config, replacement, and multi-agent ordering cases.

Copilot

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 4 comments.

jongio

Re-reviewed the new commit (4936d3b) that adds brownfield agent-name conflict confirmation to the unified azure.yaml adopt path.

confirmAdoptedAgentNameConflicts runs after configureFoundryProject stamps FOUNDRY_PROJECT_ENDPOINT into the environment, so the shared resolveExistingAgentNameConflict resolver reads the selected project's endpoint and actually checks each declared agent against it rather than silently no-opping. updateAdoptedAgentNames only rewrites azure.yaml when the resolved name differs, walks services in sorted order, and handles both the unified inline shape (path name) and the deprecated config-nested shape (path config.name). It's gated on result.FoundryProject != nil, so greenfield init skips the check. Build and the new TestAdoptedAgentNameConfig / TestUpdateAdoptedAgentNames tests pass locally.

Non-blocking: in no-prompt mode the shared resolver prints "re-run init with --agent-name <unique-name>", but the unified azure.yaml adopt path returns through runInitFromAzureYaml and doesn't consume flags.agentName, so that specific recovery hint doesn't apply to adopted services. Adoption-specific no-prompt guidance would read better as a follow-up.

RickWinter

This resolves the agent name for remote invoke from the inline service configuration when deployment output is absent. No material issues found, and nothing blocks merge.

jongio

Re-checked the current HEAD. The narrowed opt-in scope handles the shared/destructive-command concern, but two things are still open.

The design question trangevi raised is the key one: gating brownfield resolution on a project endpoint proves the project exists, not that the inline agent exists in it, so remote invoke can still target a name that was never deployed. That's a maintainer decision on the intended behavior, not something to settle in code review.

One concrete code gap on the auto-protocol invoke path is noted inline.

Co-authored-by: Copilot <[email protected]>

Copilot

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

jongio

The protocol/name split (protocolServiceName vs flags.name) resolves my earlier point: the positional azd ai agent invoke my-agent form now keeps the direct name through auto-detected protocol instead of returning deploy-first guidance. Verifying the inline name via AgentExists before targeting the adopted project, and surfacing env-read failures instead of falling back silently, both tighten the brownfield path. Built the extension package and ran the cmd tests locally, all green.

Co-authored-by: Copilot Autofix powered by AI <[email protected]>

Copilot

Pull request overview

Copilot reviewed 10 out of 10 changed files in this pull request and generated 1 comment.

jongio

Re-checked the new autofix commit (ae1fd5d). Returning immediately once the brownfield inline agent is confirmed to exist is correct: this branch only runs when AGENT_<SERVICE>_NAME is absent from the environment, so the sibling version and endpoint outputs aren't present to read anyway, and AgentName plus ProjectEndpoint are already set for the invoke. The not-exists path is unchanged. Re-approving against the new HEAD.

azure-pipelines · 2026-07-16T01:21:55Z

Azure Pipelines: Successfully started running 1 pipeline(s). 21 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run.

Copilot AI review requested due to automatic review settings July 13, 2026 14:52

glharper requested review from JeffreyCA, huimiu, therealjohn, trangevi and trrwilson as code owners July 13, 2026 14:52

microsoft-github-policy-service Bot assigned glharper Jul 13, 2026

Copilot started reviewing on behalf of glharper July 13, 2026 14:56 View session

Copilot AI reviewed Jul 13, 2026

View reviewed changes

github-actions Bot added the ext-agents azure.ai.agents extension label Jul 13, 2026

jongio approved these changes Jul 13, 2026

View reviewed changes

trangevi requested changes Jul 14, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings July 14, 2026 16:58

Copilot started reviewing on behalf of glharper July 14, 2026 16:59 View session

Copilot AI reviewed Jul 14, 2026

View reviewed changes

Comment thread cli/azd/extensions/azure.ai.agents/internal/cmd/invoke.go

jongio approved these changes Jul 14, 2026

View reviewed changes

Copilot AI review requested due to automatic review settings July 14, 2026 17:14

Copilot started reviewing on behalf of glharper July 14, 2026 17:14 View session

Copilot AI reviewed Jul 14, 2026

View reviewed changes

Comment thread cli/azd/extensions/azure.ai.agents/internal/cmd/invoke.go Outdated

Comment thread cli/azd/extensions/azure.ai.agents/internal/cmd/invoke.go Outdated

glharper requested review from Copilot and trangevi July 14, 2026 17:20

Copilot started reviewing on behalf of glharper July 14, 2026 17:20 View session

Copilot AI review requested due to automatic review settings July 15, 2026 16:25

glharper requested a review from hund030 as a code owner July 15, 2026 16:25

Copilot started reviewing on behalf of glharper July 15, 2026 16:25 View session

Copilot AI reviewed Jul 15, 2026

View reviewed changes

jongio approved these changes Jul 15, 2026

View reviewed changes

RickWinter reviewed Jul 15, 2026

View reviewed changes

jongio reviewed Jul 15, 2026

View reviewed changes

Comment thread cli/azd/extensions/azure.ai.agents/internal/cmd/invoke.go Outdated

trangevi approved these changes Jul 15, 2026

View reviewed changes

fix(agents): address invoke resolution feedback

41567ba

Co-authored-by: Copilot <[email protected]>

Copilot AI review requested due to automatic review settings July 16, 2026 00:23

Copilot started reviewing on behalf of glharper July 16, 2026 00:24 View session

glharper enabled auto-merge (squash) July 16, 2026 00:25

Copilot AI reviewed Jul 16, 2026

View reviewed changes

Comment thread cli/azd/extensions/azure.ai.agents/internal/cmd/helpers.go

jongio approved these changes Jul 16, 2026

View reviewed changes

Potential fix for pull request finding

ae1fd5d

Co-authored-by: Copilot Autofix powered by AI <[email protected]>

Copilot AI review requested due to automatic review settings July 16, 2026 01:00

Copilot started reviewing on behalf of glharper July 16, 2026 01:01 View session

Copilot AI reviewed Jul 16, 2026

View reviewed changes

Comment thread cli/azd/extensions/azure.ai.agents/internal/cmd/init_adopt.go

Copilot started work on behalf of glharper July 16, 2026 01:11 View session

jongio approved these changes Jul 16, 2026

View reviewed changes

Copilot finished work on behalf of glharper July 16, 2026 01:17

glharper closed this Jul 16, 2026

auto-merge was automatically disabled July 16, 2026 01:21
Pull request was closed

glharper reopened this Jul 16, 2026

trangevi approved these changes Jul 16, 2026

View reviewed changes

trangevi merged commit c316e90 into main Jul 16, 2026
42 checks passed

jongio mentioned this pull request Jul 17, 2026

fix: read unified azure.yaml in agent run and deploy #9149

Merged

Uh oh!

Conversation

glharper commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What

Root cause

Fix

Tests

Validation

Uh oh!

github-actions Bot commented Jul 13, 2026

📋 Prioritization Note

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

jongio left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

trangevi left a comment

Choose a reason for hiding this comment

Uh oh!

jongio commented Jul 14, 2026

Uh oh!

glharper commented Jul 14, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

jongio left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

glharper commented Jul 14, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

glharper commented Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jongio left a comment

Choose a reason for hiding this comment

Uh oh!

RickWinter left a comment

Choose a reason for hiding this comment

Uh oh!

jongio left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

jongio left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Uh oh!

glharper commented Jul 13, 2026 •

edited

Loading

jongio left a comment •

edited

Loading

jongio left a comment •

edited

Loading

glharper commented Jul 15, 2026 •

edited

Loading