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
..
2026-04-01 13:47:20 +00:00

DevUI Samples

This folder contains sample agents and workflows designed to work with the Agent Framework DevUI - a lightweight web interface for running and testing agents interactively.

What is DevUI?

DevUI is a sample application that provides:

  • A web interface for testing agents and workflows
  • OpenAI-compatible API endpoints
  • Directory-based entity discovery
  • In-memory entity registration
  • Sample entity gallery

Note

: DevUI is a sample app for development and testing. For production use, build your own custom interface using the Agent Framework SDK.

Quick Start

Option 1: In-Memory Mode (Programmatic Registration)

Run a single sample directly. This demonstrates how to register agents and workflows in code without using DevUI's directory discovery.

This sample uses Azure AI Foundry. Before running it:

  1. Copy .env.example in this folder to .env, or export the same values in your shell
  2. Set FOUNDRY_PROJECT_ENDPOINT and FOUNDRY_MODEL
  3. Run az login

Then start the sample:

cd python/samples/02-agents/devui
python in_memory_mode.py

This opens your browser at http://localhost:8090 with two Foundry-backed agents and a simple text transformation workflow.

Option 2: Directory Discovery with Shared Root .env

Run the folder-level launcher to load samples/02-agents/devui/.env and then start DevUI with directory discovery for this folder:

cd python/samples/02-agents/devui
python main.py

This starts the server at http://localhost:8080 with all discoverable agents and workflows available. The root .env acts as shared fallback configuration for discovered samples.

Option 3: Directory Discovery with the devui CLI

If you prefer the CLI directly, you can still launch DevUI from this folder:

cd python/samples/02-agents/devui
devui .

DevUI discovery checks for a sample-specific .env first and then falls back to .env in samples/02-agents/devui/.

Sample Structure

DevUI discovers samples from Python packages that export either agent or workflow.

Typical agent layout:

agent_name/
├── __init__.py      # Must export: agent = ...
├── agent.py         # Agent implementation
└── .env.example     # Optional example environment variables

Typical workflow layout:

workflow_name/
├── __init__.py      # Must export: workflow = ...
├── workflow.py      # Workflow implementation
├── workflow.yaml    # Optional declarative definition
└── .env.example     # Optional example environment variables

Available Samples

Agents

Sample What it demonstrates Required keys / auth
agent_weather/ A richer Foundry-backed weather agent that shows chat middleware, function middleware, tool calling, and an approval-required tool alongside auto-approved tools. FOUNDRY_PROJECT_ENDPOINT, FOUNDRY_MODEL, plus Azure CLI auth via az login
agent_foundry/ A minimal Foundry-backed weather agent with current weather and forecast tools. Use this when you want the smallest possible directory-discovered agent sample. FOUNDRY_PROJECT_ENDPOINT, FOUNDRY_MODEL, plus Azure CLI auth via az login

Workflows

Sample What it demonstrates Required keys / auth
workflow_declarative/ A YAML-defined workflow loaded through WorkflowFactory, with nested age-based branching and no model client code. None
workflow_with_agents/ A content review workflow that uses agents as executors and routes based on structured review output (Writer -> Reviewer -> Editor/Publisher -> Summarizer). AZURE_OPENAI_ENDPOINT, plus AZURE_OPENAI_CHAT_MODEL or AZURE_OPENAI_MODEL; Azure CLI auth via az login; AZURE_OPENAI_API_VERSION is optional
workflow_spam/ A multi-step spam detection workflow with human-in-the-loop approval, branching for spam vs. legitimate messages, and a final reporting step. None
workflow_fanout/ A larger fan-out/fan-in data processing workflow with parallel validation, multiple transformations, QA, aggregation, and demo failure toggles. None

Standalone Examples

Sample What it demonstrates Required keys / auth
in_memory_mode.py Registers multiple entities directly in Python: two Foundry-backed agents plus a simple workflow, all served from one file without directory discovery. FOUNDRY_PROJECT_ENDPOINT, FOUNDRY_MODEL, plus Azure CLI auth via az login

Environment Variables

For samples that require external services:

  1. Copy .env.example to .env
  2. Fill in the required values
  3. Run az login for samples that use Azure CLI authentication

Directory discovery checks .env files in this order:

  1. The entity directory itself, for example agent_weather/.env
  2. The root DevUI samples folder, samples/02-agents/devui/.env

That means the root .env.example can hold shared defaults for multiple samples, while a sample-specific .env can override those values when needed.

in_memory_mode.py and main.py both load .env from samples/02-agents/devui/, so the root .env.example in this folder is the right starting point for both commands.

Alternatively, set environment variables globally:

# Foundry-backed samples
export FOUNDRY_PROJECT_ENDPOINT="https://your-project.services.ai.azure.com"
export FOUNDRY_MODEL="gpt-4o"

# Azure OpenAI workflow_with_agents sample
export AZURE_OPENAI_ENDPOINT="https://your-resource.openai.azure.com"
export AZURE_OPENAI_CHAT_MODEL="gpt-4o"
export AZURE_OPENAI_MODEL="gpt-4o"

az login

Using DevUI with Your Own Agents

To make your agent discoverable by DevUI:

  1. Create a folder for your agent
  2. Add an __init__.py that exports agent or workflow
  3. (Optional) Add a .env file for environment variables

Example:

# my_agent/__init__.py
from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient

agent = Agent(
    name="MyAgent",
    description="My custom agent",
    client=OpenAIChatClient(),
    # ... your configuration
)

Then run:

devui /path/to/my/agents/folder

API Usage

DevUI exposes OpenAI-compatible endpoints:

curl -X POST http://localhost:8080/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "agent-framework",
    "input": "What is the weather in Seattle?",
    "extra_body": {"entity_id": "agent_directory_weather-agent_<uuid>"}
  }'

List available entities:

curl http://localhost:8080/v1/entities

Learn More

Troubleshooting

Missing credentials or settings: Check your .env files, confirm the required variables for the sample you are running, and make sure az login has completed for Azure-authenticated samples.

Import errors: Make sure you've installed the devui package:

pip install agent-framework-devui --pre

Port conflicts: DevUI uses ports 8080 (directory mode) and 8090 (in-memory mode) by default. Close other services or specify a different port:

devui --port 8888