* .NET: Add Microsoft Fabric sample #3674 (#4230) Co-authored-by: Chris <66376200+crickman@users.noreply.github.com> * Python: Phase 2: Embedding clients for Ollama, Bedrock, and Azure AI Inference (#4207) * Phase 2: Embedding clients for Ollama, Bedrock, and Azure AI Inference Add embedding client implementations to existing provider packages: - OllamaEmbeddingClient: Text embeddings via Ollama's embed API - BedrockEmbeddingClient: Text embeddings via Amazon Titan on Bedrock - AzureAIInferenceEmbeddingClient: Text and image embeddings via Azure AI Inference, supporting Content | str input with separate model IDs for text (AZURE_AI_INFERENCE_EMBEDDING_MODEL_ID) and image (AZURE_AI_INFERENCE_IMAGE_EMBEDDING_MODEL_ID) endpoints Additional changes: - Rename EmbeddingCoT -> EmbeddingT, EmbeddingOptionsCoT -> EmbeddingOptionsT - Add otel_provider_name passthrough to all embedding clients - Register integration pytest marker in all packages - Add lazy-loading namespace exports for Ollama and Bedrock embeddings - Add image embedding sample using Cohere-embed-v3-english - Add azure-ai-inference dependency to azure-ai package Part of #1188 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Fix mypy duplicate name and ruff lint issues - Rename second 'vector' variable to 'img_vector' in image embedding loop - Combine nested with statements in tests - Remove unused result assignments in tests Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * updates from feedback * Fix CI failures in embedding usage handling - Fix Azure AI embedding mypy issues by normalizing vectors to list[float], safely accumulating optional usage token fields, and filtering None entries before constructing GeneratedEmbeddings - Avoid Bandit false positive by initializing usage details as an empty dict - Update OpenAI embedding tests to assert canonical usage keys (input_token_count/total_token_count) Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * [Purview] Mark responses as responses and fix epoch bug for python long overflow (#4225) * .NET: Support InvokeMcpTool for declarative workflows (#4204) * Initial implementation of InvokeMcpTool in declarative workflow * Cleaned up sample implementation * Updated sample comments. * Added missing executor routing attribute * Fix PR comments. * Updated based on PR comments. * Updated based on PR comments. * Removed unnecessary using statement. * Update Python package versions to rc2 (#4258) - Bump core and azure-ai to 1.0.0rc2 - Bump preview packages to 1.0.0b260225 - Update dependencies to >=1.0.0rc2 - Add CHANGELOG entries for changes since rc1 - Update uv.lock Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * .NET: Fixing issue where OpenTelemetry span is never exported in .NET in-process workflow execution (#4196) * 1. Add reproduction test for issue #4155: workflow.run Activity never stopped in streaming OffThread path The WorkflowRunActivity_IsStopped_Streaming_OffThread test demonstrates that the workflow.run OpenTelemetry Activity created in StreamingRunEventStream.RunLoopAsync is started but never stopped when using the OffThread/Default streaming execution. The background run loop keeps running after event consumption completes, so the using Activity? declaration never disposes until explicit StopAsync() is called. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> 2. Fix workflow.run Activity never stopped in streaming OffThread execution (#4155) The workflow.run OpenTelemetry Activity in StreamingRunEventStream.RunLoopAsync was scoped to the method lifetime via 'using'. Since the run loop only exits on cancellation, the Activity was never stopped/exported until explicit disposal. Fix: Remove 'using' and explicitly dispose the Activity when the workflow reaches Idle status (all supersteps complete). A safety-net disposal in the finally block handles cancellation and error paths. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Add root-level workflow.session activity spanning run loop lifetime\n\nImplements two-level telemetry hierarchy per PR feedback from lokitoth:\n- workflow.session: spans the entire run loop / stream lifetime\n- workflow_invoke: per input-to-halt cycle, nested within the session\n\nThis ensures the session activity stays open across multiple turns,\nwhile individual run activities are created and disposed per cycle.\n\nAlso fixes linkedSource CancellationTokenSource disposal leak in\nStreamingRunEventStream (added using declaration)." * Address Copilot review: fix Activity/CTS disposal, rename activity, add error tag\n\n1. LockstepRunEventStream: Remove 'using' from Activity in async iterator\n and manually dispose in finally block (fixes #4155 pattern). Also dispose\n linkedSource CTS in finally to prevent leak.\n2. Tags.cs: Add ErrorMessage (\"error.message\") tag for runtime errors,\n distinct from BuildErrorMessage (\"build.error.message\").\n3. ActivityNames: Rename WorkflowRun from \"workflow_invoke\" to \"workflow.run\"\n for cross-language consistency.\n4. WorkflowTelemetryContext: Fix XML doc to say \"outer/parent span\" instead\n of \"root-level span\".\n5. ObservabilityTests: Assert WorkflowSession absence when DisableWorkflowRun\n is true.\n6. WorkflowRunActivityStopTests: Fix streaming test race by disposing\n StreamingRun before asserting activities are stopped.\n7. StreamingRunEventStream/LockstepRunEventStream: Use Tags.ErrorMessage\n instead of Tags.BuildErrorMessage for runtime error events." * Review fixes: revert workflow_invoke rename, use 'using' for linkedSource, move SessionStarted earlier\n\n- Revert ActivityNames.WorkflowRun back to \"workflow_invoke\" (OTEL semantic convention contract)\n- Use 'using' declaration for linkedSource CTS in LockstepRunEventStream (no timing sensitivity)\n- Move SessionStarted event before WaitForInputAsync in StreamingRunEventStream to match Lockstep behavior" * Improve naming and comments in WorkflowRunActivityStopTests" * Prevent session Activity.Current leak in lockstep mode, add nesting test Save and restore Activity.Current in LockstepRunEventStream.Start() so the session activity doesn't leak into caller code via AsyncLocal. Re-establish Activity.Current = sessionActivity before creating the run activity in TakeEventStreamAsync to preserve parent-child nesting. Add test verifying app activities after RunAsync are not parented under the session, and that the workflow_invoke activity nests under the session." * Fix stale XML doc: WorkflowRun -> WorkflowInvoke in ObservabilityTests --------- Co-authored-by: alliscode <bentho@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * Python / .NET Samples - Restructure and Improve Samples (Feature Branc… (#4092) * Python: .NET Samples - Restructure and Improve Samples (Feature Branch) (#4091) * Moved by agent (#4094) * Fix readme links * .NET Samples - Create `04-hosting` learning path step (#4098) * Agent move * Agent reorderd * Remove A2A section from README Removed A2A section from the Getting Started README. * Agent fixed links * Fix broken sample links in durable-agents README (#4101) * Initial plan * Fix broken internal links in documentation Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Revert template link changes; keep only durable-agents README fix Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * .NET Samples - Create `03-workflows` learning path step (#4102) * Fix solution project path * Python: Fix broken markdown links to repo resources (outside /docs) (#4105) * Initial plan * Fix broken markdown links to repo resources Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Update README to rename .NET Workflows Samples section --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * .NET Samples - Create `02-agents` learning path step (#4107) * .NET: Fix broken relative link in GroupChatToolApproval README (#4108) * Initial plan * Fix broken link in GroupChatToolApproval README Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Update labeler configuration for workflow samples * .NET - Reorder Agents samples to start from Step01 instead of Step04 (#4110) * Fix solution * Resolve new sample paths * Move new AgentSkills and AgentWithMemory_Step04 samples * Fix link * Fix readme path * fix: update stale dotnet/samples/Durable path reference in AGENTS.md Co-authored-by: crickman <66376200+crickman@users.noreply.github.com> * Moved new sample * Update solution * Resolve merge (new sample) * Sync to new sample - FoundryAgents_Step21_BingCustomSearch * Updated README * .NET Samples - Configuration Naming Update (#4149) * .NET: Restore AzureFunctions index parity with ConsoleApps under DurableAgents samples (#4221) * Clean-up `05_host_your_agent` * Config setting consistency * Refine samples * AGENTS.md * Move new samples * Re-order samples * Move new project and fixup solution * Fixup model config * Fix up new UT project --------- Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> * Python: Fix Bedrock embedding test stub missing meta attribute (#4287) * Fix Bedrock embedding test stub missing meta attribute * Increase test coverage so gate passes * Python: (ag-ui): fix approval payloads being re-processed on subsequent conversation turns (#4232) * Fix ag-ui tool call issue * Safe json fix * Python: Update workflow orchestration samples to use AzureOpenAIResponsesClient (#4285) * Update workflow orchestration samples to use AzureOpenAIResponsesClient * Fix broken link * Move scripts to scripts folder --------- Co-authored-by: Roger Barreto <19890735+rogerbarreto@users.noreply.github.com> Co-authored-by: Chris <66376200+crickman@users.noreply.github.com> Co-authored-by: Eduard van Valkenburg <eavanvalkenburg@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: Rishabh Chawla <rishabhchawla1995@gmail.com> Co-authored-by: Peter Ibekwe <109177538+peibekwe@users.noreply.github.com> Co-authored-by: Dmytro Struk <13853051+dmytrostruk@users.noreply.github.com> Co-authored-by: Ben Thomas <ben.thomas@microsoft.com> Co-authored-by: alliscode <bentho@microsoft.com> Co-authored-by: Copilot <198982749+Copilot@users.noreply.github.com> Co-authored-by: Evan Mattson <35585003+moonbox3@users.noreply.github.com>
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.
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 notificationsResponse.usage- Token usage (in final response, not streamed)
Custom DevUI Extensions:
response.output_item.addedwith 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 resultsresponse.workflow_event.complete- Agent Framework workflow eventsresponse.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/workflowsGET /v1/entities/{entity_id}/info- Get detailed entity informationPOST /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 conversationGET /v1/conversations/{id}- Get conversationPOST /v1/conversations/{id}- Update conversation metadataDELETE /v1/conversations/{id}- Delete conversationGET /v1/conversations?agent_id={id}- List conversations (DevUI extension)POST /v1/conversations/{id}/items- Add items to conversationGET /v1/conversations/{id}/items- List conversation itemsGET /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 --authfor any deployment exposed to end users - Review all agent/workflow code before running
- Only load entities from trusted sources
- Use
.envfiles 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
