Files
Eduard van Valkenburg 6e95517659 Python: Split type checkers by target (pyright source, 5 checkers on tests/samples) (#6443)
* Python: Split type checkers by target (pyright source, 5 checkers on tests/samples)

Rework the typing setup along the lines of the 'too many type checkers'
approach:

- Pyright (strict) is now the sole source-code type checker; mypy is
  removed from source and its [tool.mypy] block becomes a relaxed profile
  used only for tests/samples.
- Tests are checked by all five checkers (pyright relaxed, mypy, pyrefly,
  ty, zuban); samples by pyright, pyrefly, and ty. All run in a relaxed/
  basic profile so authors aren't forced into over-annotation.
- Add pyrightconfig.tests.json and bump sample pyright configs to basic.
- Unify test/sample typing onto the same parallel fan-out used by source
  pyright via run_command_items in task_runner.py.
- Make version-conditional imports symmetric: keep or drop the
  '# type: ignore' on both branches so results match across interpreter
  versions (local vs CI).
- Update SKILL.md, DEV_SETUP.md, and CODING_STANDARD.md for the five
  gating checkers and pyright on source+tests+samples.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Python: Fix merge regressions from main (typing + runtime)

Merging main into the type-checker split branch surfaced regressions that
the new five-checker test suite and unit tests caught:

Runtime fixes:
- anthropic: restore the dropped `cache_read_input_token_count` mapping in
  _parse_usage_from_anthropic (lost during merge conflict resolution).
- gemini: _get_function_calling_mode test helper returned str(enum)
  ('FunctionCallingConfigMode.AUTO') instead of the enum value ('AUTO').
- openai: _response_id_from_token test helper was an infinite self-recursion;
  return token['response_id'].
- orchestrations: reset output_events per approval iteration so the terminal
  output assertion counts only the final run.
- core: drop a stale duplicate harness test whose message ('non-negative')
  contradicted the source ('positive').
- purview: import PolicyLocation/PolicyScope/ProtectionScopeActivities/
  ExecutionMode used by the processor tests.

Type-checker fixes (tests, relaxed profile):
- core: pyright/mypy/pyrefly/ty/zuban green-ups across the harness, MCP,
  observability and types tests.
- anthropic/openai: route provider-namespaced UsageDetails keys through a
  dict cast (extra_items TypedDict unsupported by mypy/ty).
- purview: typed model constructors and cache-mock casts.
- ag-ui: annotate WorkflowContext[Any, Any] so yield_output accepts test
  payloads, guard Optional forwarded_props, and ty-ignore intentional bad args.

Source pyright (sole source checker) flagged unnecessary ignores newly
introduced by merged code in core _tools.py and declarative _declarative_base.py.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Python: Isolate per-package mypy cache in test-typing fan-out

The parallel test-typing fan-out runs many mypy processes concurrently,
all defaulting to a single shared ./.mypy_cache. Concurrent writes corrupt
the cache and mypy aborts with INTERNAL ERROR (intermittently, depending on
worker timing) -- which is why CI's Test Typing job failed on a shifting set
of packages while a single-package run was fine.

Give each mypy invocation an isolated cache dir keyed by its target paths so
incremental caching still works per package without races. Other checkers
(zuban/pyrefly/ty/pyright) maintain their own caches and are unaffected.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Python: Make lab pyright-only on source (drop source mypy)

Lab was the last package still running mypy on its source code, requiring
mypy-only `# type: ignore` comments that pyright (the sole source checker
everywhere else) flags as unnecessary. Align lab with the rest of the
monorepo:

- Remove the lab source mypy poe tasks (mypy-gaia/lightning/tau2) and the
  now-dead strict [tool.mypy] config block.
- Drop the 'Run lab mypy' CI step; lab source is type-checked by pyright only.

Lab tests remain covered by the workspace test-typing fan-out (mypy, pyrefly,
ty, zuban, pyright over tests using the relaxed root config).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Python: Fix test-typing regressions from latest main merge

A fresh merge from main brought in new test code never run under the
five-checker test-typing suite. Green up across the affected packages:

- core: narrow Optional span.attributes with 'and' guards in span filters
  and assert+cast the json.loads(...attributes[...]) reads (test_observability);
  match the existing as_agent ignore on the protocol-typed fixture (test_clients).
- openai: align new streaming tests with the established chat_options dict
  pattern (ChatOptions TypedDict isn't assignable to dict), route Optional
  .annotations[0] access through a small _first_annotation helper (mirrors the
  file's assert-not-None convention), and annotate a mapped ResponseStream.
- foundry_hosting: annotate error: dict[str, Any] = body.get(...) or {}
  (zuban needs the annotation).
- foundry: narrow ignores for the live AIProjectClient credential arg (pyrefly)
  and connections.get_default (zuban) SDK type gaps.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* updated pyright version

* pyright fix

* Python: Fix source typing for pyright 1.1.410

Pyright 1.1.410 tightened several checks. Apply the same source fixes as
upstream PR #6275:

- anthropic: import AsyncAnthropicBedrock from anthropic.lib.bedrock and
  AsyncAnthropicVertex from anthropic.lib.vertex (no longer re-exported from
  the anthropic top-level package -> reportPrivateImportUsage).
- core _types.py: cast the transform-hook result to UpdateT (reportAssignmentType).
- core _workflows/_events.py: annotate the @contextmanager helper as
  Generator[None] instead of Iterator[None] (reportDeprecated).
- redis: build the combined filter expression with an explicit loop instead of
  reduce(and_, ...), which pyright could no longer fully type (drops the now
  unused functools.reduce / operator.and_ imports).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

* Python: Accept plain-text body in Azure Functions workflow/run endpoint

The workflow_orchestrator already accepts plain strings as well as JSON
objects via context.get_input(), but the start_workflow_orchestration HTTP
handler only accepted JSON and returned 400 for any non-JSON body. This made
the functions integration tests that POST text/plain to /api/workflow/run
(e.g. test_09_workflow_shared_state) fail consistently with 400 != 202.

Fall back to the raw request body (decoded as UTF-8) when the body is not
JSON, rejecting only a truly empty body. The JSON path is unchanged.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

---------

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-06-18 15:06:20 +00:00
..

Declarative Agent Samples

This folder contains sample code demonstrating how to use the Microsoft Agent Framework Declarative package to create agents from YAML specifications. The declarative approach allows you to define your agents in a structured, configuration-driven way, separating agent behavior from implementation details.

Installation

Install the declarative package via pip:

pip install agent-framework-declarative --pre

What is Declarative Agent Framework?

The declarative package provides support for building agents based on YAML specifications. This approach offers several benefits:

  • Cross-Platform Compatibility: Write one YAML definition and create agents in both Python and .NET - the same agent configuration works across both platforms
  • Separation of Concerns: Define agent behavior in YAML files separate from your implementation code
  • Reusability: Share and version agent configurations independently across projects and languages
  • Flexibility: Easily swap between different LLM providers and configurations
  • Maintainability: Update agent instructions and settings without modifying code

Samples in This Folder

1. Get Weather Agent (get_weather_agent.py)

Demonstrates how to create an agent with custom function tools using the declarative approach.

  • Uses Azure OpenAI Responses client
  • Shows how to bind Python functions to the agent using the bindings parameter
  • Loads agent configuration from declarative-agents/agent-samples/chatclient/GetWeather.yaml
  • Implements a simple weather lookup function tool

Key concepts: Function binding, Azure OpenAI integration, tool usage

2. Microsoft Learn Agent (microsoft_learn_agent.py)

Shows how to create an agent that can search and retrieve information from Microsoft Learn documentation using the Model Context Protocol (MCP).

  • Uses Azure AI Foundry client with MCP server integration
  • Demonstrates async context managers for proper resource cleanup
  • Loads agent configuration from declarative-agents/agent-samples/foundry/MicrosoftLearnAgent.yaml
  • Uses Azure CLI credentials for authentication
  • Leverages MCP to access Microsoft documentation tools

Requirements: pip install agent-framework-foundry

Key concepts: Azure AI Foundry integration, MCP server usage, async patterns, resource management

3. Inline YAML Agent (inline_yaml.py)

Shows how to create an agent using an inline YAML string rather than a file.

  • Uses Azure AI Foundry v2 Client with instructions.

Requirements: pip install agent-framework-foundry

Key concepts: Inline YAML definition.

4. Azure OpenAI Responses Agent (azure_openai_responses_agent.py)

Illustrates a basic agent using Azure OpenAI with structured responses.

  • Uses Azure OpenAI Responses client
  • Shows how to pass credentials via client_kwargs
  • Loads agent configuration from declarative-agents/agent-samples/azure/AzureOpenAIResponses.yaml
  • Demonstrates accessing structured response data

Key concepts: Azure OpenAI integration, credential management, structured outputs

5. OpenAI Responses Agent (openai_agent.py)

Demonstrates the simplest possible agent using OpenAI directly.

  • Uses OpenAI API (requires OPENAI_API_KEY environment variable)
  • Shows minimal configuration needed for basic agent creation
  • Loads agent configuration from declarative-agents/agent-samples/openai/OpenAIResponses.yaml

Key concepts: OpenAI integration, minimal setup, environment-based configuration

Agent Samples Repository

All the YAML configuration files referenced in these samples are located in the declarative-agents/agent-samples folder at the repository root. This folder contains declarative agent specifications organized by provider:

  • declarative-agents/agent-samples/azure/ - Azure OpenAI agent configurations
  • declarative-agents/agent-samples/chatclient/ - Chat client agent configurations with tools
  • declarative-agents/agent-samples/foundry/ - Azure AI Foundry agent configurations
  • declarative-agents/agent-samples/openai/ - OpenAI agent configurations

Important: These YAML files are platform-agnostic and work with both Python and .NET implementations of the Agent Framework. You can use the exact same YAML definition to create agents in either language, making it easy to share agent configurations across different technology stacks.

These YAML files define:

  • Agent instructions and system prompts
  • Model selection and parameters
  • Tool and function configurations
  • Provider-specific settings
  • MCP server integrations (where applicable)

Common Patterns

Creating an Agent from YAML String

from agent_framework.declarative import AgentFactory

with open("agent.yaml", "r") as f:
    yaml_str = f.read()

agent = AgentFactory().create_agent_from_yaml(yaml_str)
# response = await agent.run("Your query here")

Creating an Agent from YAML Path

from pathlib import Path
from agent_framework.declarative import AgentFactory

yaml_path = Path("agent.yaml")
agent = AgentFactory().create_agent_from_yaml_path(yaml_path)
# response = await agent.run("Your query here")

Binding Custom Functions

from pathlib import Path
from agent_framework.declarative import AgentFactory

def my_function(param: str) -> str:
    return f"Result: {param}"

agent_factory = AgentFactory(bindings={"my_function": my_function})
agent = agent_factory.create_agent_from_yaml_path(Path("agent_with_tool.yaml"))

Using Credentials

from pathlib import Path
from agent_framework.declarative import AgentFactory
from azure.identity import AzureCliCredential

agent = AgentFactory(
    client_kwargs={"credential": AzureCliCredential()}
).create_agent_from_yaml_path(Path("azure_agent.yaml"))

Adding Custom Provider Mappings

from pathlib import Path
from agent_framework.declarative import AgentFactory
# from my_custom_module import MyCustomChatClient

# Register a custom provider mapping
agent_factory = AgentFactory(
    additional_mappings={
        "MyProvider": {
            "package": "my_custom_module",
            "name": "MyCustomChatClient",
            "model_field": "model",
        }
    }
)

# Now you can reference "MyProvider" in your YAML
# Example YAML snippet:
# model:
#   provider: MyProvider
#   id: my-model-name

agent = agent_factory.create_agent_from_yaml_path(Path("custom_provider.yaml"))

This allows you to extend the declarative framework with custom chat client implementations. The mapping requires:

  • package: The Python package/module to import from
  • name: The class name of your SupportsChatGetResponse implementation
  • model_field: The constructor parameter name that accepts the value of the model.id field from the YAML

You can reference your custom provider using either Provider.ApiType format or just Provider in your YAML configuration, as long as it matches the registered mapping.

Using PowerFx Formulas in YAML

The declarative framework supports PowerFx formulas in YAML values, enabling dynamic configuration based on environment variables and conditional logic. Prefix any value with = to evaluate it as a PowerFx expression.

Environment Variable Lookup

Access environment variables using the Env.<variable_name> syntax:

model:
  connection:
    kind: key
    apiKey: =Env.OPENAI_API_KEY
    endpoint: =Env.BASE_URL & "/v1"  # String concatenation with &

  options:
    temperature: 0.7
    maxOutputTokens: =Env.MAX_TOKENS  # Will be converted to appropriate type

Conditional Logic

Use PowerFx operators for conditional configuration. This is particularly useful for adjusting parameters based on which model is being used:

model:
  id: =Env.MODEL_NAME
  options:
    # Set max tokens based on model - using conditional logic
    maxOutputTokens: =If(Env.MODEL_NAME = "gpt-5", 8000, 4000)

    # Adjust temperature for different environments
    temperature: =If(Env.ENVIRONMENT = "production", 0.3, 0.7)

    # Use logical operators for complex conditions
    seed: =If(Env.ENVIRONMENT = "production" And Env.DETERMINISTIC = "true", 42, Blank())

Supported PowerFx Features

  • String operations: Concatenation (&), comparison (=, <>), substring testing (in, exactin)
  • Logical operators: And, Or, Not (also &&, ||, !)
  • Arithmetic: Basic math operations (+, -, *, /)
  • Conditional: If(condition, true_value, false_value)
  • Environment access: Env.<VARIABLE_NAME>

Example with multiple features:

instructions: =If(
  Env.USE_EXPERT_MODE = "true",
  "You are an expert AI assistant with advanced capabilities. " & Env.CUSTOM_INSTRUCTIONS,
  "You are a helpful AI assistant."
)

model:
  options:
    stopSequences: =If("gpt-4" in Env.MODEL_NAME, ["END", "STOP"], ["END"])

Note: PowerFx evaluation happens when the YAML is loaded, not at runtime. Use environment variables (via .env file or env_file parameter) to make configurations flexible across environments.

Running the Samples

Each sample can be run independently. Make sure you have the required environment variables set:

  • For Azure samples: Ensure you're logged in via Azure CLI (az login)
  • For OpenAI samples: Set OPENAI_API_KEY environment variable
# Run a specific sample
python get_weather_agent.py
python microsoft_learn_agent.py
python inline_yaml.py
python azure_openai_responses_agent.py
python openai_responses_agent.py

Learn More

Next Steps

  1. Explore the YAML files in the declarative-agents/agent-samples folder to understand the configuration format
  2. Try modifying the samples to use different models or instructions
  3. Create your own declarative agent configurations
  4. Build custom function tools and bind them to your agents