Items marked (preview) in this article are currently in public preview. This preview is provided without a service-level agreement, and we don’t recommend it for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.
- What important behavior is happening repeatedly?
- Which agents, versions, or conversations are affected?
- What trace evidence supports the Insight?
- What should I investigate, evaluate, or improve next?
- Prepare an agent and its telemetry for Insights in Foundry.
- Run an Insights scan in the Microsoft Foundry portal.
- Review an Insight and validate its supporting evidence.
- Route a confirmed Insight to the appropriate next action.
- Run on-demand analysis and configure a schedule with the Python SDK.
- Troubleshoot common setup and result-quality issues.
Prerequisites
Before you begin, you need:- A Foundry project with a supported model deployment and a connected Azure Monitor Application Insights resource.
- For the Python examples, Python 3.10 or later and Azure CLI. Sign in by running
az login. - Permission to create role assignments at the required resource scopes, or an administrator who can assign the following roles before you run the workflow.
- For a Prompt agent, the interactive user must have the Foundry User role on the project. For a Hosted agent, the user must have the Foundry Project Manager role.
- The Monitoring Reader role on the connected Application Insights resource for both the interactive user and the Foundry project’s managed identity.
- If the
AppGenAIContenttable is protected, the Privileged Monitoring Data Reader role for each identity that reads protected content, including the project’s managed identity. For resource-scoped queries, assign the role on the connected Application Insights resource. For workspace-scoped queries, assign it on the linked Log Analytics workspace. For more information, see Grant access to protected tables. - The project’s managed identity needs access to the model deployment used for analysis.
- Recent, representative traces for the selected agent.
The Foundry RBAC roles were recently renamed. Foundry User, Foundry Owner, Foundry Account Owner, and Foundry Project Manager were previously named Azure AI User, Azure AI Owner, Azure AI Account Owner, and Azure AI Project Manager. You might still see the previous names in some places while the rename rolls out. The role IDs and core permissions are unchanged by the rename.
Choose a suitable agent
Start with one production agent that has:- A technical owner who can review the agent’s traces and Insights.
- Representative successful and unsuccessful traffic.
- Stable agent and version identities in telemetry.
- Repeated traffic from which patterns can emerge.
Verify trace readiness
Insights in Foundry can analyze only the evidence available in traces. Before you run a scan:- In your Foundry project, open the agent.
- Select Traces, and then open the tracing experience.
- Confirm that recent production or representative test traces are visible.
- Confirm that trace timestamps fall within the analysis lookback window.
How Insights in Foundry works
Insights in Foundry uses trace data from the Azure Monitor Application Insights resource connected to your Foundry project.Information in an Insight
Depending on the available trace data and supported configuration, an Insight can include:Run an Insights scan in the portal
- Sign in to Microsoft Foundry.
- Open the Foundry project that contains your agent.
- Select Build > Agents, and then select the agent.
- Select the Insights tab.
- Under Configuration, select the Judge model used to generate Insights.
- Select Run scan now.

Review generated Insights
When the analysis finishes, the Insights tab shows generated Insights for the selected agent.


- Affects an important user or business workflow.
- Has enough linked traces to indicate repetition.
- Includes representative traces that your team understands.
- Describes a behavior that the agent owner can confirm or challenge.
Validate an Insight
Don’t accept an Insight based only on its title or summary. Review its evidence before taking action.- Open the Insight.
- Read the description and proposed fix.
- Confirm the agent version, category, severity, status, and creation time.
- Expand the highlighted traces.
- For each highlighted trace, review its summary, duration, and token count. Then open the trace to verify the cited behavior.
- Compare problematic examples with healthy traces.
- Decide whether the behavior is real, important, correctly grouped, and assigned to the correct owner for further validation.
Take action on a confirmed Insight
The available actions depend on the Insight and the supported preview configuration.Investigate traces
Open the highlighted or filtered trace cohort to review the complete execution path, including model operations, tool calls, timing, errors, and agent output.Add evaluation coverage
If the Insight confirms an important expected behavior, create or update an evaluator or dataset so you can test the behavior explicitly before and after future changes. Evaluation validates behavior you know to test. Insights in Foundry helps identify which production behaviors should become explicit evaluation targets.Review a proposed improvement
Some Insights include a proposed prompt or code change. Review the proposal against:- The highlighted traces.
- The intended agent behavior.
- Healthy control traces.
- Security and policy requirements.
- Tests and evaluation datasets.
- Your normal source-control, review, and deployment process.
Concrete prompt or code proposals are available only for supported agent types and configurations and can change during preview. Code-based Hosted agents and Prompt agents are supported, with concrete fix proposals when available.
General guidance when agent code isn’t available
When Insights in Foundry can’t access editable agent instructions or source code, the proposed fix provides general remediation guidance instead of a concrete diff. Review the recommendation and apply it in the system that owns the agent implementation.
Prompt agent proposed fix
For a Prompt agent, the proposed fix can show a side-by-side diff of the agent instructions.
Code-based Hosted agent proposed fix
For a code-based Hosted agent, the proposed fix can show a side-by-side source code diff.
Route a dependency or platform issue
If the evidence points to a tool, model endpoint, MCP server, data source, network, or Foundry platform issue, route the Insight to the responsible owner. Don’t apply an agent-side prompt or code change when the agent doesn’t control the failing behavior. Use Azure Monitor for infrastructure availability, dependency health, quotas, throttling, and other operational incident workflows.Resolve, dismiss, or monitor recurrence
Where supported, use the Insight status to record that an Insight is active, resolved, or dismissed. Before marking an Insight resolved, verify the change against new production evidence or a relevant evaluation.Use the code samples
The following Python examples show the core SDK calls for an existing registered agent. They use the same APIs as the complete on-demand sample and scheduled sample in the Azure SDK for Python repository. Run the setup first, then use the on-demand or scheduled workflow in the same Python session. The examples keep the monitor and its Insights available for review. They don’t create an agent, generate traces, or delete existing monitors.Set up the Python client
Before you run the examples:- Complete the prerequisites, including model and telemetry access for the project’s managed identity.
- Select an agent with ingested traces from the last three hours for the on-demand example. For an external agent, the emitted OpenTelemetry agent ID must match its registered
otel_agent_id. - Set the following environment variables in your shell.
Install version 2.6.1 or later of the Azure AI Projects client library and Azure Identity:
allow_preview=True to use the preview operations under beta.agent_insight_monitors.
monitor = monitor_operations.get("<monitor-id>") instead. This approach preserves its current settings, runs, and Insights.
Run analysis on demand
Use the monitor from setup to analyze traces from the last three hours. The run starts asynchronously;poller.result() waits for completion.
Review and resolve an Insight
After analysis completes, list the monitor’s Insights with their details:<insight-id> with the ID you reviewed and run this optional step:
Run analysis on a schedule
To enable recurring analysis, update the monitor from setup with a six-hour interval. You don’t need to run on-demand analysis first.list_runs to find active runs and cancel_run if you need to stop them.
Close the clients
When you finish the examples, close the client and credential. This releases local connections; it doesn’t delete the monitor or disable its schedule.Run the complete samples
Use the on-demand sample or scheduled sample for a self-contained demonstration. Download the selected script and agent_insights_util.py into the same directory, and then follow the script’s installation and environment-variable instructions. Unlike the preceding excerpts, each complete sample:- Registers a temporary external agent with a unique name.
- Emits fictional traces and waits for ingestion. Trace generation doesn’t execute tools or call a model; Insights analysis uses your model deployment.
- Deletes its own monitor and agent in
finally. Ingested telemetry remains in Application Insights under its normal retention policy.
APP_INSIGHTS_RESOURCE_ID for ingestion queries. Their optional FOUNDRY_AGENT_NAME is a name prefix, not an existing agent name.
The scheduled sample shows how to enable a schedule and read its settings. It doesn’t wait for scheduled analysis. Its cleanup disables the schedule and cancels active runs before deletion, so it doesn’t leave recurring analysis enabled.
Troubleshoot Insights in Foundry
Insights in Foundry isn’t available or a scan can’t start
Check that:- Insights in Foundry is available in the selected subscription and region.
- The project uses a supported Foundry project type.
- You can see recent traces in the connected Application Insights resource.
- The project is connected to the intended Application Insights resource.
- You assigned the required user and managed-identity roles at the correct scopes.
- You can read protected trace content when required.
- Role assignments have propagated.
- The selected insight-generation model is available and has quota.
404 response from the preview API can indicate that Insights in Foundry isn’t enabled for the selected subscription context. A 403 response indicates that the endpoint is reachable but the caller isn’t authorized.
The first analysis is still running
Analysis runs asynchronously. Confirm that the lookback window contains traces, and then return later. Don’t reset or repeatedly reenable the monitor while a run is active. If the state doesn’t change within the expected processing period, record:- Subscription and project identifiers.
- Agent name and version.
- Monitor and run IDs.
- Start time in UTC.
- Request ID from a failed API response, when available.
- A screenshot of the current state.
No Insights were generated
The absence of generated Insights doesn’t necessarily mean that setup failed. The selected traffic might not contain a repeated pattern with enough evidence. Check that:- The lookback window contains sufficient traffic.
- Traces include both healthy and problematic behavior.
- Agent and version identities are consistent.
- Model, tool, and workflow spans are present.
- The expected behavior occurs in more than one trace.
- Filters aren’t hiding completed Insights.
An Insight appears incorrect
On the Insights page, select Give feedback to report a result-quality issue. Classify the problem before reporting it:- False positive unsupported by the traces.
- Expected behavior presented as a problem.
- Incorrect category or severity.
- Correct symptom with an incorrect likely cause.
- Proposed action that the named owner can’t execute.
- Unrelated issues merged together.
- One issue duplicated across multiple Insights or agent versions.
- Evidence contradicted by healthy control traces.
Trace content is missing
Insights in Foundry can’t reconstruct content or spans that it didn’t capture, and it can’t read data without the required authorization. Verify instrumentation and access to:- Agent and version identity.
- User request and agent response, subject to your data policy.
- Model calls.
- Tool arguments and results.
- Workflow and subagent spans.
- Protected generative AI content tables.
Responsible use and limitations
Insights in Foundry uses AI to identify patterns, infer likely causes, and recommend actions. Results can be incomplete or incorrect.- Review the supporting traces before accepting an Insight.
- Validate proposed prompt, code, tool, workflow, or configuration changes before deployment.
- Don’t use Insights in Foundry as your only production monitoring, security, safety, or compliance control.
- Insights aren’t guaranteed to be real time.
- Insights in Foundry might miss real issues or combine unrelated behavior.
- Category, severity, ownership, likely cause, and proposed actions are decision support, not authoritative classifications.
- A valid symptom can be attributed to the wrong agent, dependency, or platform layer.
- Infrastructure outages, endpoint availability, quotas, and dependency incidents remain Azure Monitor or service-owner responsibilities.
- Insight generation depends on trace completeness, identity, permissions, model availability, and service capacity.
- An Insights run analyzes an agent’s traces over a lookback window and doesn’t support every incident-scoped investigation workflow.
- Supported agent types, models, regions, limits, prices, and UI can change during preview.
- Follow your organization’s requirements for confidentiality, privacy, security, compliance, responsible AI, and data residency.