2.4.3. Monitoring with Application Insights
💡 First Principle: Built-in analytics tell you what is happening in aggregate; Application Insights tells you why, event by event — because it streams the agent's raw telemetry into a queryable store your operations team already uses for every other production system.
The integration is explicit: in the agent's settings you connect an Application Insights resource by its connection string — nothing flows until you do. Once connected, conversation activity telemetry lands in Application Insights, where KQL queries answer the operational questions dashboards can't: which topics fail most for this customer segment, what preceded last Tuesday's error spike, how does latency distribute across channels. Alerts, dashboards, and export pipelines follow, because the data now lives in standard Azure Monitor infrastructure.
| Surface | What it gives you | Where it falls short |
|---|---|---|
| Built-in analytics | Sessions, engagement, resolution/escalation rates — zero setup | Aggregates only; no custom queries or alerting |
| Application Insights | Raw event telemetry, KQL, alerts, correlation with other systems | Requires Azure resource + connection string; you own retention costs |
| Agent flow run history | Per-run action results for flows (3.2.4) | Flow-scoped — not conversation telemetry |
Treat these as layers, not rivals: analytics for the product manager's questions, Application Insights for the engineer's, run history for the flow author's.
⚠️ Common Misconception: Application Insights telemetry is collected by default. The connection string wiring is a deliberate configuration act — scenarios where "no telemetry appears in Azure" are testing whether you know the resource must be connected in settings first.
Reflection Question: Support says "the agent was broken yesterday around 3 PM." Which of the three surfaces answers what happened at 3:04 PM for user X, and what must have been configured before yesterday for that answer to exist?
