Files
microsoft--agent-framework/python/packages/devui
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-05-14 15:05:27 +00:00
2026-05-14 15:05:27 +00:00
2026-05-14 15:05:27 +00:00

DevUI - A Sample App for Running Agents and Workflows

A lightweight, standalone sample app interface for running entities (agents/workflows) in the Microsoft Agent Framework supporting directory-based discovery, in-memory entity registration, and sample entity gallery.

Important

DevUI is a sample app to help you get started with the Agent Framework. It is not intended for production use. For production, or for features beyond what is provided in this sample app, it is recommended that you build your own custom interface and API server using the Agent Framework SDK.

DevUI Screenshot

Quick Start

# Install
pip install agent-framework-devui --pre

You can also launch it programmatically

from agent_framework import Agent
from agent_framework.openai import OpenAIChatClient
from agent_framework.devui import serve

def get_weather(location: str) -> str:
    """Get weather for a location."""
    return f"Weather in {location}: 72°F and sunny"

# Create your agent
agent = Agent(
    name="WeatherAgent",
    client=OpenAIChatClient(),
    tools=[get_weather]
)

# Launch debug UI - that's it!
serve(entities=[agent], auto_open=True)
# → Opens browser to http://localhost:8080

In addition, if you have agents/workflows defined in a specific directory structure (see below), you can launch DevUI from the cli to discover and run them.


# Launch web UI + API server
devui ./agents --port 8080
# → Web UI: http://localhost:8080
# → API: http://localhost:8080/v1/*

DevUI is auth-enabled by default. Localhost starts with a generated development token logged at startup; pass it as Authorization: Bearer <token> for direct API calls.

When DevUI starts with no discovered entities, it displays a sample entity gallery with curated examples from the Agent Framework repository. You can download these samples, review them, and run them locally to get started quickly.

Using MCP Tools

Important: Don't use async with context managers when creating agents with MCP tools for DevUI - connections will close before execution.

# ✅ Correct - DevUI handles cleanup automatically
mcp_tool = MCPStreamableHTTPTool(url="http://localhost:8011/mcp", client=client)
agent = Agent(tools=mcp_tool)
serve(entities=[agent])

MCP tools use lazy initialization and connect automatically on first use. DevUI attempts to clean up connections on shutdown

Resource Cleanup

Register cleanup hooks to properly close credentials and resources on shutdown:

from azure.identity.aio import DefaultAzureCredential
from agent_framework import Agent
from agent_framework.openai import OpenAIChatCompletionClient
from agent_framework_devui import register_cleanup, serve

credential = DefaultAzureCredential()
client = OpenAIChatCompletionClient()
agent = Agent(name="MyAgent", client=client)

# Register cleanup hook - credential will be closed on shutdown
register_cleanup(agent, credential.close)
serve(entities=[agent])

Works with multiple resources and file-based discovery. See tests for more examples.

Directory Structure

For your agents to be discovered by the DevUI, they must be organized in a directory structure like below. Each agent/workflow must have an __init__.py that exports the required variable (agent or workflow).

Note: .env files are optional but will be automatically loaded if present in the agent/workflow directory or parent entities directory. Use them to store API keys, configuration variables, and other environment-specific settings.

agents/
├── weather_agent/
│   ├── __init__.py      # Must export: agent = Agent(...)
│   ├── agent.py
│   └── .env             # Optional: API keys, config vars
├── my_workflow/
│   ├── __init__.py      # Must export: workflow = WorkflowBuilder(start_executor=...)...
│   ├── workflow.py
│   └── .env             # Optional: environment variables
└── .env                 # Optional: shared environment variables

Importing from External Modules

If your agents import tools or utilities from sibling directories (e.g., from tools.helpers import my_tool), you must set PYTHONPATH to include the parent directory:

# Project structure:
# backend/
# ├── agents/
# │   └── my_agent/
# │       └── agent.py    # contains: from tools.helpers import my_tool
# └── tools/
#     └── helpers.py

# Run from project root with PYTHONPATH
cd backend
PYTHONPATH=. devui ./agents --port 8080

Without PYTHONPATH, Python cannot find modules in sibling directories and DevUI will report an import error.

Viewing Telemetry (Otel Traces) in DevUI

Agent Framework emits OpenTelemetry (Otel) traces for various operations. You can view these traces in DevUI by enabling instrumentation when starting the server.

devui ./agents --instrumentation

OpenAI-Compatible API

For convenience, DevUI provides an OpenAI Responses backend API. This means you can run the backend and also use the OpenAI client sdk to connect to it. Use agent/workflow name as the entity_id in metadata, and set streaming to True as needed.

# Simple - use your entity name as the entity_id in metadata
curl -X POST http://localhost:8080/v1/responses \
  -H "Authorization: Bearer <devui-token>" \
  -H "Content-Type: application/json" \
  -d @- << 'EOF'
{
  "metadata": {"entity_id": "weather_agent"},
  "input": "Hello world"
}
EOF

Or use the OpenAI Python SDK:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="<devui-token>"
)

response = client.responses.create(
    metadata={"entity_id": "weather_agent"},  # Your agent/workflow name
    input="What's the weather in Seattle?"
)

# Extract text from response
print(response.output[0].content[0].text)
# Supports streaming with stream=True

Multi-turn Conversations

Use the standard OpenAI conversation parameter for multi-turn conversations:

# Create a conversation
conversation = client.conversations.create(
    metadata={"agent_id": "weather_agent"}
)

# Use it across multiple turns
response1 = client.responses.create(
    metadata={"entity_id": "weather_agent"},
    input="What's the weather in Seattle?",
    conversation=conversation.id
)

response2 = client.responses.create(
    metadata={"entity_id": "weather_agent"},
    input="How about tomorrow?",
    conversation=conversation.id  # Continues the conversation!
)

How it works: DevUI automatically retrieves the conversation's message history from the stored thread and passes it to the agent. You don't need to manually manage message history - just provide the same conversation ID for follow-up requests.

OpenAI Proxy Mode

DevUI provides an OpenAI Proxy feature for testing OpenAI models directly through the interface without creating custom agents. Enable via Settings → OpenAI Proxy tab.

How it works: The UI sends requests to the DevUI backend (with X-Proxy-Backend: openai header), which then proxies them to OpenAI's Responses API (and Conversations API for multi-turn chats). This proxy approach keeps your OPENAI_API_KEY secure on the server—never exposed in the browser or client-side code.

Example:

curl -X POST http://localhost:8080/v1/responses \
  -H "Authorization: Bearer <devui-token>" \
  -H "X-Proxy-Backend: openai" \
  -d '{"model": "gpt-4.1-mini", "input": "Hello"}'

Note: Requires OPENAI_API_KEY environment variable configured on the backend.

CLI Options

devui [directory] [options]

Options:
  --port, -p      Port (default: 8080)
  --host          Host (default: 127.0.0.1; non-loopback hosts require auth)
  --headless      API only, no UI
  --no-open       Don't automatically open browser
  --instrumentation  Enable OpenTelemetry instrumentation
  --reload        Enable auto-reload
  --mode          developer|user (default: developer)
  --no-auth       Disable auth for loopback-only local development
  --auth-token    Custom authentication token (required for non-loopback hosts unless DEVUI_AUTH_TOKEN is set)

UI Modes

  • developer (default): Full access - debug panel, entity details, hot reload, deployment
  • user: Simplified UI with restricted APIs - only chat and conversation management
# Development
devui ./agents

# Local-only no-auth development
devui ./agents --no-auth

Key Endpoints

API Mapping

Given that DevUI offers an OpenAI Responses API, it internally maps messages and events from Agent Framework to OpenAI Responses API events (in _mapper.py). For transparency, this mapping is shown below:

OpenAI Event/Type Agent Framework Content Status
Lifecycle Events
response.created + response.in_progress AgentStartedEvent OpenAI
response.completed AgentCompletedEvent OpenAI
response.failed AgentFailedEvent OpenAI
response.created + response.in_progress WorkflowEvent (type='started') OpenAI
response.completed WorkflowEvent (type='status') OpenAI
response.failed WorkflowEvent (type='failed') OpenAI
Content Types
response.content_part.added + response.output_text.delta TextContent OpenAI
response.reasoning_text.delta TextReasoningContent OpenAI
response.output_item.added FunctionCallContent (initial) OpenAI
response.function_call_arguments.delta FunctionCallContent (args) OpenAI
response.function_result.complete FunctionResultContent DevUI
response.function_approval.requested FunctionApprovalRequestContent DevUI
response.function_approval.responded FunctionApprovalResponseContent DevUI
response.output_item.added (ResponseOutputImage) DataContent (images) DevUI
response.output_item.added (ResponseOutputFile) DataContent (files) DevUI
response.output_item.added (ResponseOutputData) DataContent (other) DevUI
response.output_item.added (ResponseOutputImage/File) UriContent (images/files) DevUI
error ErrorContent OpenAI
Final Response.usage field (not streamed) UsageContent OpenAI
Workflow Events
response.output_item.added (ExecutorActionItem)* WorkflowEvent (type='executor_invoked') OpenAI
response.output_item.done (ExecutorActionItem)* WorkflowEvent (type='executor_completed') OpenAI
response.output_item.done (ExecutorActionItem with error)* WorkflowEvent (type='executor_failed') OpenAI
response.output_item.added (ResponseOutputMessage) WorkflowEvent (type='output') OpenAI
response.workflow_event.complete WorkflowEvent (other types) DevUI
response.trace.complete WorkflowEvent (type='status') DevUI
response.trace.complete WorkflowEvent (type='warning') DevUI
Trace Content
response.trace.complete DataContent (no data/errors) DevUI
response.trace.complete UriContent (unsupported MIME) DevUI
response.trace.complete HostedFileContent DevUI
response.trace.complete HostedVectorStoreContent DevUI

*Uses standard OpenAI event structure but carries DevUI-specific ExecutorActionItem payload

  • OpenAI = Standard OpenAI Responses API event types
  • DevUI = Custom event types specific to Agent Framework (e.g., workflows, traces, function approvals)

OpenAI Responses API Compliance

DevUI follows the OpenAI Responses API specification for maximum compatibility:

OpenAI Standard Event Types Used:

  • ResponseOutputItemAddedEvent - Output item notifications (function calls, images, files, data)
  • ResponseOutputItemDoneEvent - Output item completion notifications
  • Response.usage - Token usage (in final response, not streamed)

Custom DevUI Extensions:

  • response.output_item.added with custom item types:
    • ResponseOutputImage - Agent-generated images (inline display)
    • ResponseOutputFile - Agent-generated files (inline display)
    • ResponseOutputData - Agent-generated structured data (inline display)
  • response.function_approval.requested - Function approval requests (for interactive approval workflows)
  • response.function_approval.responded - Function approval responses (user approval/rejection)
  • response.function_result.complete - Server-side function execution results
  • response.workflow_event.complete - Agent Framework workflow events
  • response.trace.complete - Execution traces and internal content (DataContent, UriContent, hosted files/stores)

These custom extensions are clearly namespaced and can be safely ignored by standard OpenAI clients. Note that DevUI also uses standard OpenAI events with custom payloads (e.g., ExecutorActionItem within response.output_item.added).

Entity Management

  • GET /v1/entities - List discovered agents/workflows
  • GET /v1/entities/{entity_id}/info - Get detailed entity information
  • POST /v1/entities/{entity_id}/reload - Hot reload entity (for development)

Execution (OpenAI Responses API)

  • POST /v1/responses - Execute agent/workflow (streaming or sync)

Conversations (OpenAI Standard)

  • POST /v1/conversations - Create conversation
  • GET /v1/conversations/{id} - Get conversation
  • POST /v1/conversations/{id} - Update conversation metadata
  • DELETE /v1/conversations/{id} - Delete conversation
  • GET /v1/conversations?agent_id={id} - List conversations (DevUI extension)
  • POST /v1/conversations/{id}/items - Add items to conversation
  • GET /v1/conversations/{id}/items - List conversation items
  • GET /v1/conversations/{id}/items/{item_id} - Get conversation item

Health

  • GET /health - Health check

Security

DevUI is designed as a sample application for local development and is not intended for production use. For production, or for features beyond this sample app, build a custom interface and API server using the Agent Framework SDK.

Auth is enabled by default. Unauthenticated mode is allowed only when DevUI is bound to localhost or 127.0.0.1. Network-reachable binds such as 0.0.0.0, LAN IPs, and hostnames require Bearer token authentication with an explicit token.

For shared development hosts:

# Set a token explicitly before binding beyond loopback
DEVUI_AUTH_TOKEN="<secure-dev-token>" devui ./agents --mode user --host 0.0.0.0

# Or pass the token on the command line
devui ./agents --mode user --host 0.0.0.0 --auth-token "<secure-dev-token>"

Do not use --no-auth with 0.0.0.0, LAN IPs, or hostnames. That configuration fails closed before startup.

Security features:

  • User mode restricts developer-facing APIs
  • Bearer token authentication is enabled by default
  • Unauthenticated mode is loopback-only (localhost / 127.0.0.1)
  • Non-loopback binds require DEVUI_AUTH_TOKEN or --auth-token
  • Only loads entities from local directories or in-memory registration
  • No remote code execution capabilities
  • Binds to localhost (127.0.0.1) by default

Best practices:

  • Do not use DevUI as a production deployment surface
  • Use --mode user plus DEVUI_AUTH_TOKEN or --auth-token for shared development hosts
  • Review all agent/workflow code before running
  • Only load entities from trusted sources
  • Use .env files for sensitive credentials (never commit them)

Implementation

  • Discovery: agent_framework_devui/_discovery.py
  • Execution: agent_framework_devui/_executor.py
  • Message Mapping: agent_framework_devui/_mapper.py
  • Conversations: agent_framework_devui/_conversations.py
  • API Server: agent_framework_devui/_server.py
  • CLI: agent_framework_devui/_cli.py

Examples

See working implementations in python/samples/02-agents/devui/

License

MIT