Add an agent-mode harness example

[PratikDhanave (PratikDhanave)]

Continuing harness sample coverage (loop #1165, todo #1166): Go supports the agent-mode harness (agent/harness/agentmode) but examples/ has no sample.

Change

• New examples/02-agents/harness/step03_agentmode that attaches the agent-mode context provider (default plan/execute modes, with the mode_set/mode_get tools and per-mode instruction injection) to a Foundry agent, so the agent plans a task then switches to execute mode. Session-backed.
• Registered in cmd/verifyexamples (env-gated on FOUNDRY_PROJECT_ENDPOINT), skipping cleanly without credentials.

Builds, go vet, gofumpt clean; the verifyexamples test passes.

[Copilot]

Copilot review overview

🟡 Changes recommended

The example does not reliably demonstrate execute-mode instructions and has a naming inconsistency.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 1 · 1

Open (2)

• Split planning and execution into separate runs · New
• Rename ModalAssistant to ModeAssistant · New

What changed in this PR

Adds a session-backed Go example for the agent-mode harness and registers it with environment-gated verification.

Changes:

• Adds a plan/execute agent-mode sample with mode tools.
• Registers the sample with verifyexamples.

File	Summary
examples/​02-agents/​harness/​step03_agentmode/​main.go	Adds the agent-mode example. The execution flow should be split into planning and execution runs, and ModalAssistant should be renamed to ModeAssistant.
cmd/​verifyexamples/​examples.go	Registers the example for environment-gated verification.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Scope: examples (no public API change — agent/harness/agentmode is pre-existing and untouched by this PR; only a new examples/02-agents/harness/step03_agentmode/main.go sample and a cmd/verifyexamples registration entry are added)

Changed Go contract: None. No exported functions, types, or behavior changed.

Upstream evidence reviewed:

• .NET: dotnet/samples/02-agents/Agents/Agent_Step22_AgentMode/Program.cs
• Python: python/samples/02-agents/context_providers/agent_mode_provider.py

Both upstream samples demonstrate the plan→execute switch via an interactive loop: the agent is run once per user turn, the user (or agent, via mode_set) switches modes between turns, and the mode/instructions are re-injected by the context provider on the next RunAsync/run call. Neither upstream sample relies on a single non-interactive call to show both modes.

Result: Conceptually aligned with the upstream agent-mode harness (same tools, defaults, and session-backed mode state), but the Go example's single RunText(...).Collect() call cannot reliably demonstrate the execute-mode instructions — this matches the harness's Invoking/context-provider design (agent/agent.go: providers run once per top-level invoke, not per tool call), so a mode_set call inside the automatic tool loop updates session state without the current request's instructions reflecting execute mode. This root cause is already captured by the automated Copilot review's existing inline comment on main.go:51 (and a related naming nit on main.go:36), consistent with how both upstream samples split mode-switch demonstrations across separate turns/calls. No additional inline comment is needed to avoid duplicating the same finding.

No label changes: no exported Go API surface changed (no public-api-change), and neither public-api-change nor parity-approved is currently present, so nothing to remove.

Generated by Go API Consistency Review Agent · copilot · auto · 56 AIC · ⌖ 6.54 AIC · ⊞ 9.2K · ◷