[Agents Extension] Add support for run and invoke commands

[trangevi]

Adds two new commands to the agent extension

1. run starts the agent on the local machine. If there is more than one agent in the current azd project, a name will have to be specified.
2. invoke executes a /responses call against an agent, either running locally or in the cloud

[Copilot]

Pull request overview

Adds local development ergonomics to the azure.ai.agents azd extension by introducing run (start an agent locally) and invoke (send messages to a local or remote agent), plus wiring init to persist a detected startupCommand for later reuse.

Changes:

• Add azd ai agent run to detect project type, install deps, and launch the agent process locally.
• Add azd ai agent invoke to call a locally running agent or stream responses from the remote Foundry endpoint, with persisted session/conversation IDs.
• Enhance init flows to detect/prompt for a startup command and write it into the service’s AdditionalProperties.startupCommand.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 16 comments.

Show a summary per file

File	Description
cli/azd/extensions/azure.ai.agents/internal/cmd/run.go	New run command: dependency install, env loading, and subprocess management for local agent dev loop.
cli/azd/extensions/azure.ai.agents/internal/cmd/invoke.go	New invoke command: local HTTP call and remote streaming SSE invocation with session/conversation handling.
cli/azd/extensions/azure.ai.agents/internal/cmd/root.go	Registers the new run and invoke subcommands on the extension root command.
cli/azd/extensions/azure.ai.agents/internal/cmd/init.go	Detects/prompts for startupCommand during init and stores it in service additional properties.
cli/azd/extensions/azure.ai.agents/internal/cmd/init_from_code.go	Same startupCommand detection/prompt behavior for init-from-code flow.
cli/azd/extensions/azure.ai.agents/internal/cmd/helpers.go	New helpers for startup detection, azd project/service resolution, and local state persistence (.foundry-agent.json).
cli/azd/extensions/azure.ai.agents/internal/cmd/helpers_test.go	Unit tests for startup command and project-type detection logic.
cli/azd/extensions/azure.ai.agents/internal/cmd/agent_context.go	Minor signature adjustment to resolveAgentEndpoint.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

@trangevi I've opened a new pull request, #7028, to work on those changes. Once the pull request is ready, I'll request review from you.

[wbreza]

Code Review Summary

TL;DR

This PR adds run and invoke commands to the azure.ai.agents extension for local development. The implementation is solid with good test coverage for pure functions, thoughtful dependency management, and well-structured SSE streaming. However, there are several areas that need attention around command consistency, code duplication, and error handling.

✅ What Looks Good

• Thorough table-driven tests for pure functions (parseCommand, detectProjectType, SSE parsing, etc.)
• Thoughtful dependency installation with uv/pip fallback and cross-platform venv resolution
• Clean SSE stream handling with generous buffer and proper error event support

Key Theme: Command Consistency

As the extension grows, it's important that all commands follow consistent patterns — especially around how they resolve which service to operate on. Currently show and monitor require explicit --name flags, while init uses interactive prompts for selection. The new run and invoke commands should establish a consistent pattern for service resolution: accept an optional --name, and when multiple services exist, prompt the user to select rather than returning an error. This sets a good UX precedent for all future commands.

Findings Summary

Priority	Count
🟠 High	4
🟡 Medium	5
🟢 Low	2
Total	11

See inline comments for details.

[wbreza]

Code Review (Re-review)

✅ Prior Review Items — All Resolved

All 9 issues from the prior review are addressed:

1. Multi-service resolution now prompts via promptForAgentService()
2. resolveStartupCommandForInit extracted to shared helper
3. --no-prompt mode respected (returns empty string)
4. Signal handler cleanup with done channel + signal.Stop
5. invokeLocal passes parent context to HTTP request
6. saveLocalContext errors now propagated
7. Startup command log distinguishes source ("Detected" vs "Using")
8. Config file uses resolveConfigPath with .azure/<env>/
9. Single azdClient per command

Config File Location

The .foundry-agent.json stored in .azure/<env>/ is the right approach — session/conversation IDs are per-environment (different Foundry endpoints), the file stays gitignored as mutable dev state, and it persists across terminal restarts.

✅ What Looks Good

• Well-structured extraction of shared helpers into helpers.go
• Comprehensive table-driven tests for pure functions (parseCommand, detectProjectType, SSE parsing)
• Proper signal handling with cleanup and context cancellation
• Good command UX with positional argument support and --no-prompt handling
• SSE streaming implementation is solid with error handling

Remaining Suggestions

Priority	Count
High	1
Medium	2
Low	3

See inline comments for details. None are blocking.