Tao Chen
e3b4b6662b
* feat(workflows): Make telemetry opt-in via WithOpenTelemetry() - Add WorkflowTelemetryOptions class with EnableSensitiveData property - Add WorkflowTelemetryContext to manage ActivitySource lifecycle - Add WithOpenTelemetry() extension method on WorkflowBuilder - Update all workflow components to use telemetry context: - WorkflowBuilder, Workflow, Executor - InProcessRunnerContext, InProcessRunner - LockstepRunEventStream, StreamingRunEventStream - All edge runners (Direct, FanIn, FanOut, Response) - Telemetry is now disabled by default - Users must call WithOpenTelemetry() to enable spans/activities BREAKING CHANGE: Workflow telemetry is now opt-in. Users who relied on automatic telemetry must add .WithOpenTelemetry() to their workflow builder. * refactor: Pass telemetry context as parameter instead of via interface - Remove IWorkflowContextWithTelemetry interface - Add internal ExecuteAsync overload that accepts WorkflowTelemetryContext - Public ExecuteAsync delegates with WorkflowTelemetryContext.Disabled - InProcessRunner passes TelemetryContext when calling ExecuteAsync - BoundContext now implements IWorkflowContext (not the removed interface) * Add optional ActivitySource parameter to WithOpenTelemetry Allow users to provide their own ActivitySource when enabling telemetry, giving them better control over the ActivitySource lifecycle. When not provided, the framework creates one internally (existing behavior). Changes: - Add optional activitySource parameter to WithOpenTelemetry() extension - Update WorkflowTelemetryContext to accept external ActivitySource - Add unit test for user-provided ActivitySource scenario * Add component-level telemetry control with disable flags Allow users to selectively disable specific activity types via WorkflowTelemetryOptions. All activities are enabled by default. New disable flags: - DisableWorkflowBuild: Disables workflow.build activities - DisableWorkflowRun: Disables workflow_invoke activities - DisableExecutorProcess: Disables executor.process activities - DisableEdgeGroupProcess: Disables edge_group.process activities - DisableMessageSend: Disables message.send activities Added helper methods to WorkflowTelemetryContext for each activity type and updated all activity creation sites to use them. * Implement EnableSensitiveData to log executor input/output When EnableSensitiveData is true in WorkflowTelemetryOptions, executor input and output are logged as JSON-serialized attributes in the executor.process activity. New activity tags: - executor.input: JSON serialized input message - executor.output: JSON serialized output result (non-void only) Added suppression attributes for AOT/trimming warnings since this is an opt-in feature for debugging/diagnostics. * Refactor activity start methods to centralize tagging logic Move tagging logic into WorkflowTelemetryContext methods: - StartExecutorProcessActivity now accepts executorId, executorType, messageType, and message; sets all tags including executor.input when EnableSensitiveData is true - Added SetExecutorOutput method to set executor.output after execution - StartMessageSendActivity now accepts sourceId, targetId, and message; sets all tags including message.content when EnableSensitiveData is true Simplified Executor.cs and InProcessRunnerContext.cs by removing inline tagging code. Added message.content tag constant. * Revert Python changes * Update samples and code cleanup * Fix file formatting * Add comment * Add telemetry configuration to declarative workflow * Remove delays in tests * Address comments
Getting started with Foundry Agents
The getting started with Foundry Agents samples demonstrate the fundamental concepts and functionalities of Azure Foundry Agents and can be used with Azure Foundry as the AI provider.
These samples showcase how to work with agents managed through Azure Foundry, including agent creation, versioning, multi-turn conversations, and advanced features like code interpretation and computer use.
Classic vs New Foundry Agents
Note
Recently, Azure Foundry introduced a new and improved experience for creating and managing AI agents, which is the target of these samples.
For more information about the previous classic agents and for what's new in Foundry Agents, see the Foundry Agents migration documentation.
For a sample demonstrating how to use classic Foundry Agents, see the following: Agent with Azure AI Persistent.
Agent Versioning and Static Definitions
One of the key architectural changes in the new Foundry Agents compared to the classic experience is how agent definitions are handled. In the new architecture, agents have versions and their definitions are established at creation time. This means that the agent's configuration—including instructions, tools, and options—is fixed when the agent version is created.
Important
Agent versions are static and strictly adhere to their original definition. Any attempt to provide or override tools, instructions, or options during an agent run or request will be ignored by the agent, as the API does not support runtime configuration changes. All agent behavior must be defined at agent creation time.
This design ensures consistency and predictability in agent behavior across all interactions with a specific agent version.
The Agent Framework intentionally ignores unsupported runtime parameters rather than throwing exceptions. This abstraction-first approach ensures that code written against the unified agent abstraction remains portable across providers (OpenAI, Azure OpenAI, Foundry Agents). It removes the need for provider-specific conditional logic. Teams can adopt Foundry Agents without rewriting existing orchestration code. Configurations that work with other providers will gracefully degrade, rather than fail, when the underlying API does not support them.
Getting started with Foundry Agents prerequisites
Before you begin, ensure you have the following prerequisites:
- .NET 10 SDK or later
- Azure Foundry service endpoint and project configured
- Azure CLI installed and authenticated (for Azure credential authentication)
Note: These samples use Azure Foundry Agents. For more information, see Azure AI Foundry documentation.
Note: These samples use Azure CLI credentials for authentication. Make sure you're logged in with az login and have access to the Azure Foundry resource. For more information, see the Azure CLI documentation.
Samples
| Sample | Description |
|---|---|
| Basics | This sample demonstrates how to create and manage AI agents with versioning |
| Running a simple agent | This sample demonstrates how to create and run a basic Foundry agent |
| Multi-turn conversation | This sample demonstrates how to implement a multi-turn conversation with a Foundry agent |
| Using function tools | This sample demonstrates how to use function tools with a Foundry agent |
| Using function tools with approvals | This sample demonstrates how to use function tools where approvals require human in the loop approvals before execution |
| Structured output | This sample demonstrates how to use structured output with a Foundry agent |
| Persisted conversations | This sample demonstrates how to persist conversations and reload them later |
| Observability | This sample demonstrates how to add telemetry to a Foundry agent |
| Dependency injection | This sample demonstrates how to add and resolve a Foundry agent with a dependency injection container |
| Using MCP client as tools | This sample demonstrates how to use MCP clients as tools with a Foundry agent |
| Using images | This sample demonstrates how to use image multi-modality with a Foundry agent |
| Exposing as a function tool | This sample demonstrates how to expose a Foundry agent as a function tool |
| Using middleware | This sample demonstrates how to use middleware with a Foundry agent |
| Using plugins | This sample demonstrates how to use plugins with a Foundry agent |
| Code interpreter | This sample demonstrates how to use the code interpreter tool with a Foundry agent |
| Computer use | This sample demonstrates how to use computer use capabilities with a Foundry agent |
Running the samples from the console
To run the samples, navigate to the desired sample directory, e.g.
cd FoundryAgents_Step01.2_Running
Set the following environment variables:
$env:AZURE_FOUNDRY_PROJECT_ENDPOINT="https://your-foundry-service.services.ai.azure.com/api/projects/your-foundry-project" # Replace with your Azure Foundry resource endpoint
$env:AZURE_FOUNDRY_PROJECT_DEPLOYMENT_NAME="gpt-4o-mini" # Optional, defaults to gpt-4o-mini
If the variables are not set, you will be prompted for the values when running the samples.
Execute the following command to build the sample:
dotnet build
Execute the following command to run the sample:
dotnet run --no-build
Or just build and run in one step:
dotnet run
Running the samples from Visual Studio
Open the solution in Visual Studio and set the desired sample project as the startup project. Then, run the project using the built-in debugger or by pressing F5.
You will be prompted for any required environment variables if they are not already set.