Skip to lesson

MicrosoftMicrosoft Certified: Multi-Agent AI Solutions Expert2026-101.2 Specify technology components to include in a multi-agent solution

Preserve execution evidence without private reasoning

Completed by the knowledge check

Learning objective

Specify cross-service trace correlation, privacy-aware decision and execution metadata, and reproducible replay evidence without logging private model reasoning.

Core idea

You need evidence of what an agent system did, which controls allowed it, and which artifacts produced the result. You do not need a transcript of the model’s private reasoning. For an architect, a useful evidence design combines causal tracing, a small application decision record, and controlled replay inputs.

These serve different purposes. A trace connects execution across services. Decision metadata records an observable choice and its governing policy. A replay fixture preserves approved inputs and versions for a repeatable investigation. None proves that an internal model thought process is complete or that another inference call will return identical text.

How it works

Propagate context across service calls

OpenTelemetry propagates a trace ID and span context so a receiving service can create a span in the same trace. For HTTP, the default propagator uses W3C Trace Context; the traceparent header carries the trace ID, parent span ID, and trace flags. When a library does not propagate context automatically, use the Propagators API to inject context into a carrier at the sender and extract it at the receiver.

Apply this to the entire executed path: ingress, orchestrator, specialist, tool gateway, and downstream service. A request ID placed in unrelated log messages helps searching, but does not create causal spans. Verify propagation with a controlled request and inspect both sides of each service call rather than assuming that every framework or protocol preserves context.

Agent Framework documents a specific Python MCP mechanism. When an active OpenTelemetry span exists, client-opened MCP tools such as MCPStreamableHTTPTool, MCPStdioTool, and MCPWebsocketTool inject trace context into params._meta on tools/call. With the default propagator this includes traceparent and tracestate. This injection does not apply to provider-managed configurations such as FoundryChatClient.get_mcp_tool(...) or hosted-agent toolboxes, where the provider runtime issues the MCP request. Test that service-owned segment separately.

Preserve causality without inventing nesting

Not every handoff is a nested function call. Agent Framework workflow telemetry uses span links: the receiving executor.process span links to the source message.send span instead of becoming its child. edge_group.process also links to source send spans. This represents fan-in where several senders contribute to one processing step.

Retain those links when exporting telemetry. Flattening the workflow into one sequence of text logs loses the distinction between parallel work and nested calls. Keep the execution graph observable through executor and edge identifiers; see 1.2.8 for the delivery-status signals used to diagnose coordination failures.

Configure the export path explicitly. In Python, Agent Framework’s configure_otel_providers() reads supported OpenTelemetry exporter settings. OTEL_SERVICE_NAME and OTEL_SERVICE_VERSION identify the emitting service and version. Instrumentation and a telemetry destination are separate decisions: emitting spans does not itself establish that a backend receives them.

Collect a minimized decision record

Use an allowlist for application metadata. Suitable fields include the workflow version, selected executor, tool identifier, authorization or approval outcome, terminal status, elapsed time, attempt count, and a reference to the result artifact. Record an observable route selection or validation failure with a policy identifier, not a request for the model to reveal why it privately reasoned that way. These are application-defined fields, not a universal Foundry audit schema.

Raw private reasoning is not exposed as an audit transcript; Microsoft supports opt-in reasoning summaries through the Responses API reasoning.summary parameter, such as auto, and does not support attempts to extract raw reasoning through other methods. A summary is model-generated payload content subject to the same sensitive-data controls, not decision metadata; reasoning.summary is unsupported when multi-agent orchestration is enabled. Record the numeric reasoning-token usage as execution metadata instead: completion_tokens_details.reasoning_tokens for Chat Completions or output_tokens_details.reasoning_tokens for Responses.

Keep payload collection separate from those fields. Agent Framework Python defaults ENABLE_SENSITIVE_DATA to false; enable_instrumentation(enable_sensitive_data=False) explicitly keeps sensitive-data capture disabled. Enabling it can collect prompts, responses, function arguments, and results. Do not turn it on merely to obtain tool identifiers or timing. For .NET workflow telemetry, WorkflowTelemetryOptions.EnableSensitiveData controls raw input, output, and message content and also defaults to false.

These settings govern the instrumentation they configure, not every service in the solution. Foundry tracing is enabled by connecting the project to Azure Monitor Application Insights and can collect user inputs, model outputs, and tool data. Foundry tracing is generally available for prompt and hosted agents; workflow and external-agent tracing is in preview. Review the server-side collection policy as well as the client exporter. A client-side sensitive-data flag is not a project-wide redaction switch.

Foundry stores trace data in the connected Application Insights resource, with retention governed by Application Insights and Log Analytics configuration. Log access can use the Log Analytics Reader role; protected tables additionally require Privileged Monitoring Data Reader. Minimize before export and grant access deliberately. Restricting readers reduces exposure but does not undo collection of a secret or private content.

Build replay evidence separately

Define a versioned replay package for the investigation you intend to perform. Preserve the code revision, dependency lockfile, agent instructions version, workflow definition, model deployment reference and inference settings, tool schema versions, sanitized input, retrieved-evidence version, and captured tool responses. Include expected outcomes and the original trace reference. These are design requirements for your application; tracing does not automatically assemble this package.

Separate a fixture replay from a live rerun. A fixture replay substitutes captured, approved tool responses and checks routing and validation without repeating external effects. A live rerun calls the services again and can observe changed data, permissions, or model output. Make the mode explicit and prevent a diagnostic replay from repeating a payment, deletion, or notification.

Foundry offers trace-to-dataset generation through AIProjectClient.datasets.begin_create_generation_job(...). The resulting dataset has a name and version. redact_private_content defaults to true, while max_samples controls representative sampling and trace_ids selects specific traces. Sampling is not redaction. A generated evaluation dataset supports repeated testing, but does not replace tool fixtures, code versions, or a full execution replay record. Do not disable redaction just to make a production case easier to reproduce.

Key distinctions and trade-offs

Correlation versus causality: A common identifier joins records; trace parents and span links explain execution relationships.

Decision evidence versus private reasoning: A selected route, approval outcome, or validator result is observable evidence. Private model reasoning is not an audit prerequisite.

Minimized telemetry versus replay inputs: Operational traces can omit payloads. Approved replay fixtures can retain the specific sanitized inputs needed for testing under separate access and retention controls.

Reproducibility versus identical generation: Fixed versions and fixtures make the test conditions reviewable. They do not establish that live inference or downstream services produce byte-for-byte identical results.

Architecture / decision scenario

A support workflow routes a case to two specialists, queries an MCP tool, and proposes an account change. Investigators need to explain a wrong routing result without collecting private reasoning or customer content in general telemetry.

The ingress and specialists propagate OpenTelemetry context. Workflow send and process spans retain their links through fan-in. The team verifies the MCP segment: a client-opened transport carries params._meta, while a provider-managed connector requires a separate propagation check.

A custom decision record stores route, policy version, approval outcome, and terminal status. Sensitive capture remains disabled in Agent Framework, and the team separately reviews Foundry server-side tracing and telemetry access. The account change’s authorized execution evidence points to a protected result artifact rather than embedding the account record.

Investigators replay sanitized inputs against pinned workflow code and captured tool responses. They compare the route and validation outcome with the expected result. They can create a redacted, versioned Foundry evaluation dataset from selected trace IDs for regression testing, while keeping the replay harness unable to execute the account change.

Common exam traps

  • Assuming every MCP configuration receives Agent Framework’s automatic trace injection.
  • Converting fan-in span links into a misleading parent-child hierarchy.
  • Treating ENABLE_SENSITIVE_DATA=false as a server-side Foundry tracing policy.
  • Treating sampling as protection against private-content collection.
  • Logging private model reasoning to explain a tool’s observable execution.
  • Treating a trace-derived dataset as a complete or deterministic live replay.

What to remember

Propagate trace context, preserve workflow links, and record observable decisions with explicit versions. Keep sensitive payload capture and project tracing under separate review. Replay from controlled artifacts and fixtures; use redacted evaluation datasets for repeatable testing, and never require private model reasoning as execution evidence.

Knowledge check

References