Python: Add FHA declarative workflow sample

[TaoChenOSU]

Motivation & Context

A declarative workflow for FHA sample exists in other Foundry sample repos. We need to port it to the MAF repo too.

Description & Review Guide

Copy a sample from another Foundry sample repo to MAF repo.

Contribution Checklist

• The code builds clean without any errors or warnings
• All unit tests pass, and I have added new tests where possible
• The PR follows the Contribution Guidelines
• This PR is linked to an issue and there is no other open PR for this issue (see Related Issue above).
• This is not a breaking change. If it is a breaking change, add the breaking change label (or add "[BREAKING]" to the title prefix, before or after any language prefix) — a workflow keeps the label and title prefix in sync automatically.

[Copilot]

Pull request overview

Adds a new Python sample under python/samples/04-hosting/foundry-hosted-agents/responses/ demonstrating a Foundry-hosted, multi-turn declarative workflow (YAML) served via the Responses protocol, including a container setup that supports Power Fx evaluation.

Changes:

• Introduces a YAML workflow that routes between triage/technical/billing agents using InvokeAzureAgent + ConditionGroup.
• Adds a runnable host (main.py) that loads the declarative workflow via WorkflowFactory, wraps it with Workflow.as_agent(), and serves it using ResponsesHostServer.
• Adds packaging/deployment artifacts (requirements, Dockerfile w/ .NET runtime, agent config/manifest, env examples).

Reviewed changes

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

Show a summary per file

File	Description
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/workflow.yaml	Declarative customer-support triage workflow with routing conditions and activity output.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/requirements.txt	Sample dependencies including declarative + Foundry hosting packages and debug tooling.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/README.md	Sample walkthrough and run/deploy instructions for azd and VS Code.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/main.py	Implements triage + specialist agents and wires them into the declarative workflow host.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/Dockerfile	Container image build; installs .NET runtime required for Power Fx evaluation.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/agent.yaml	Hosted-agent configuration (Responses protocol 2.0.0 + model env var).
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/agent.manifest.yaml	Manifest for gallery/scaffolding with model resource and env var template.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/.env.example	Documents required environment variables for local runs.
python/samples/04-hosting/foundry-hosted-agents/responses/13_declarative_customer_support/.dockerignore	Excludes venv/cache/env files from container build context.

[github-actions]

Automated Code Review

Reviewers: 5 | Confidence: 91%

✓ Correctness

This PR adds a well-structured declarative workflow sample that follows established patterns from existing samples (01_basic, 05_workflows, and the 03-workflows/declarative/customer_support sample). All API usage is correct and verified against source: WorkflowFactory constructor, create_workflow_from_yaml_path, Workflow.as_agent(), Agent constructor with default_options, FoundryChatClient, and ResponsesHostServer. The workflow YAML uses valid ConditionGroup/elseActions syntax confirmed by existing samples and the declarative builder implementation. Dependencies are correctly specified with transitive packages (pydantic, python-dotenv, azure-identity) available through the listed direct dependencies. No correctness issues found.

✓ Security Reliability

This PR adds a declarative workflow sample for customer support triage. The code follows established patterns from sibling samples in the repository. Security practices are reasonable for a sample: .dockerignore excludes .env, credentials use DefaultAzureCredential (no hardcoded secrets), and environment variables are used for configuration. The Dockerfile downloads the official Microsoft dotnet-install.sh over HTTPS at build time, which is the canonical approach. No significant security or reliability issues found.

✓ Test Coverage

This PR adds a new declarative workflow sample. The repository convention is that samples under python/samples/ do not have associated unit tests — pytest is scoped to packages/**/tests only. No other sample in the responses/ directory has tests. The sample follows existing patterns (main.py, README, Dockerfile, workflow YAML, requirements.txt). No testable library logic is introduced; all code is application-level wiring. No test coverage issues to flag.

✓ Failure Modes

This sample adds a declarative workflow hosted agent for customer support triage. It follows the same patterns as the existing 12 samples in the directory (direct os.environ access, no explicit try/catch around setup). All failure paths are loud (KeyError, FileNotFoundError, ValueError from framework classes) rather than silent. The workflow YAML condition routing is correctly structured with GotoAction to EndWorkflow, preventing fall-through to subsequent actions. No concrete silent failure modes, swallowed exceptions, or operational hazards were identified in the diff.

✗ Design Approach

The sample’s overall workflow design is reasonable, but the local execution story is incomplete in a way that breaks the main onboarding paths. The README documents azd ai agent run and VS Code F5 as local workflows, while the only place this sample provisions the required .NET runtime for Power Fx is the Dockerfile. That leaves users on non-.NET machines following the documented local path into a workflow that produces no output.

Flagged Issues

• Local run/debug is documented as azd ai agent run and VS Code F5, but only the Dockerfile provides the .NET runtime that Power Fx needs. The shared hosted-agent guide describes azd ai agent run as a local host run after setting env vars rather than a containerized path, so users on machines without .NET can follow the documented sample exactly and get a non-responsive workflow. Either document a local .NET 10 prerequisite or make the supported local path containerized.

---

Automated review by TaoChenOSU's agents

[github-actions]

Flagged issue

Local run/debug is documented as azd ai agent run and VS Code F5, but only the Dockerfile provides the .NET runtime that Power Fx needs. The shared hosted-agent guide describes azd ai agent run as a local host run after setting env vars rather than a containerized path, so users on machines without .NET can follow the documented sample exactly and get a non-responsive workflow. Either document a local .NET 10 prerequisite or make the supported local path containerized.

---

Source: automated DevFlow PR review