Files
agent-framework/python/packages/devui
T
Eduard van Valkenburg 1e350ea22f Python: [BREAKING] PR2 — Wire context provider pipeline, remove old types, update all consumers (#3850)
* PR2: Wire context provider pipeline and update all internal consumers

- Replace AgentThread with AgentSession across all packages
- Replace ContextProvider with BaseContextProvider across all packages
- Replace context_provider param with context_providers (Sequence)
- Replace thread= with session= in run() signatures
- Replace get_new_thread() with create_session()
- Add get_session(service_session_id) to agent interface
- DurableAgentThread -> DurableAgentSession
- Remove _notify_thread_of_new_messages from WorkflowAgent
- Wire before_run/after_run context provider pipeline in RawAgent
- Auto-inject InMemoryHistoryProvider when no providers configured

* fix: update all tests for context provider pipeline, fix lazy-loaders, remove old test files

* refactor: update all sample files for context provider pipeline (AgentThread→AgentSession, ContextProvider→BaseContextProvider)

* fix: update remaining ag-ui references (client docstring, getting_started sample)

* fix: make get_session service_session_id keyword-only to avoid confusion with session_id

* refactor: rename _RunContext.thread_messages to session_messages

* refactor: remove _threads.py, _memory.py, and old provider files; migrate devui to use plain message lists

* rename: remove _new_ prefix from test files

* refactor: rewrite SlidingWindowChatMessageStore as SlidingWindowHistoryProvider(InMemoryHistoryProvider)

* fix: read full history from session state directly instead of reaching into provider internals

* fix: update stale .pyi stubs, sample imports, and README references for new provider types

* fix: remove stale message_store, _notify_thread_of_new_messages, and session_id.key references in samples

* refactor: merge context_providers and sessions sample folders into sessions, remove aggregate_context_provider

* refactor: UserInfoMemory stores state in session.state instead of instance attributes

* feat: add Pydantic BaseModel support to session state serialization

Pydantic models stored in session.state are now automatically serialized
via model_dump() and restored via model_validate() during to_dict()/from_dict()
round-trips. Models are auto-registered on first serialization; use
register_state_type() for cold-start deserialization.

Also export register_state_type as a public API.

* fix mem0

* Update sample README links and descriptions for session terminology

- Replace 'thread' with 'session' in sample descriptions across all READMEs
- Update file links for renamed samples (mem0_sessions, redis_sessions, etc.)
- Fix Threads section → Sessions section in main samples/README.md
- Update tools, middleware, workflows, durabletask, azure_functions READMEs
- Update architecture diagrams in concepts/tools/README.md
- Update migration guides (autogen, semantic-kernel)

* Fix broken Redis README link to renamed sample

* Fix Mem0 OSS client search: pass scoping params as direct kwargs

AsyncMemory (OSS) expects user_id/agent_id/run_id as direct kwargs,
while AsyncMemoryClient (Platform) expects them in a filters dict.
Adds tests for both client types.

Port of fix from #3844 to new Mem0ContextProvider.

* Fix rebase issues: restore missing _conversation_state.py and checkpoint decode logic

- Add back _conversation_state.py (encode/decode_chat_messages) lost in rebase
- Fix on_checkpoint_restore to decode cache/conversation with decode_chat_messages
- Fix on_checkpoint_restore to use decode_checkpoint_value for pending requests
- Add tests/workflow/__init__.py for relative import support
- Fix test_agent_executor checkpoint selection (checkpoints[1] not superstep)

* Add STORES_BY_DEFAULT ClassVar to skip redundant InMemoryHistoryProvider injection

Chat clients that store history server-side by default (OpenAI Responses API,
Azure AI Agent) now declare STORES_BY_DEFAULT = True. The agent checks this
during auto-injection and skips InMemoryHistoryProvider unless the user
explicitly sets store=False.

* Fix broken markdown links in azure_ai and redis READMEs

* Fix getting-started samples to use session API instead of removed thread/ContextProvider API

* updates to workflow as agent

* fix group chat import

* Rename Thread→Session throughout, fix service_session_id propagation, remove stale AGUIThread

- Fix: Propagate conversation_id from ChatResponse back to session.service_session_id
  in both streaming and non-streaming paths in _agents.py
- Rename AgentThreadException → AgentSessionException
- Remove stale AGUIThread from ag_ui lazy-loader
- Rename use_service_thread → use_service_session in ag-ui package
- Rename test functions from *_thread_* to *_session_*
- Rename sample files from *_thread* to *_session*
- Update docstrings and comments: thread → session
- Update _mcp.py kwargs filter: add 'session' alongside 'thread'
- Fix ContinuationToken docstring example: thread=thread → session=session
- Fix _clients.py docstring: 'Agent threads' → 'Agent sessions'

* Fix broken markdown links after thread→session file renames

* fix azure ai test
1e350ea22f · 2026-02-12 21:00:32 +00:00
History
..
2026-02-11 00:20:29 +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/*

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.azure import AzureOpenAIChatClient
from agent_framework_devui import register_cleanup, serve

credential = DefaultAzureCredential()
client = AzureOpenAIChatClient()
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 "Content-Type: application/json" \
  -d @- << 'EOF'
{
  "metadata": {"entity_id": "weather_agent"},
  "input": "Hello world"
}

Or use the OpenAI Python SDK:

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="not-needed"  # API key not required for local DevUI
)

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 "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)
  --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)
  --auth          Enable Bearer token authentication
  --auth-token    Custom authentication token

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

# Production (user-facing)
devui ./agents --mode user --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 should not be exposed to untrusted networks without proper authentication.

For production deployments:

# User mode with authentication (recommended)
devui ./agents --mode user --auth --host 0.0.0.0

This restricts developer APIs (reload, deployment, entity details) and requires Bearer token authentication.

Security features:

  • User mode restricts developer-facing APIs
  • Optional Bearer token authentication via --auth
  • 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:

  • Use --mode user --auth for any deployment exposed to end users
  • 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