Forum Discussion
Azure
hi shivannagundanavar This sounds like an interesting use case, especially because it goes beyond simply pushing Azure alerts into Teams and uses Teams as a conversational interface for investigation and operations.
For sharing the architecture with the community, the Azure discussion space would probably be the best place to start. Your scenario touches Azure Monitor, Log Analytics, Application Insights, Cost Management, Defender for Cloud, Resource Graph, and Service Health, so it fits well within the broader Azure operations/management discussion.
If you're planning to share a more detailed architecture/design article rather than asking a specific troubleshooting question, the Azure Architecture Blog could be an even better fit. There are already recent community posts there around AI agents, observability, MCP, and Azure architecture patterns.
For the actual feedback/idea side, it would depend on what you want Microsoft to consider. If you're proposing a new capability for an existing Azure service, the relevant product's feedback channel would generally be more appropriate than a general Tech Community discussion.
For the community post itself, a good approach would be to share the architecture diagram, explain the end-to-end flow, and then ask for feedback on areas such as security/RBAC, data access, agent orchestration, cost, and how the different Azure telemetry sources could be correlated.
The concept is definitely worth sharing. The combination of Teams + conversational AI + Azure operational telemetry is broad enough to generate some useful discussion from the Azure community.
Hi Surya_Narayana,
Thank you for the detailed guidance. I'll write up the full design for the Azure Architecture Blog and start a thread in the Azure discussion space, so people can comment on specific parts of it.
To give some context on where the design is heading, here is the core approach I'm planning to document:
- Alert as the starting context, not the end of the flow
When an Azure Monitor alert lands in Teams through an action group, the assistant keeps the alert's resource ID, subscription, and fired time as session context. A follow-up question like "Why did this happen?" is automatically scoped to that resource and a time window around the alert. The engineer doesn't have to re-explain anything. - Each telemetry source exposed as an MCP tool
Log Analytics, Application Insights, Resource Graph, Cost Management, Defender for Cloud, and Service Health each sit behind a separate MCP tool with a narrow, well-defined contract. The orchestrator decides which tools to call, and the tools stay independently testable and replaceable. Your mention of the recent MCP posts is timely, because this is the part I most want the community to challenge. - Grounded KQL instead of free-form generation
KQL queries are built against the actual workspace schema, then validated and limited to read-only operations with row and time caps before they run. That keeps answers accurate and prevents expensive or runaway queries. - Correlation across sources
Resource ID and timestamp are the join keys. For example, "What caused the cost increase?" can combine the Cost Management delta with Resource Graph change history, then check for scale events or new deployments in the same window. - Security built around the user's identity
The bot uses on-behalf-of (OBO) flow, so every query runs under the engineer's own RBAC. The assistant can never show someone data they couldn't already see in the portal. It is read-only by default, and any remediation action would require explicit approval in Teams.
The areas where I'd especially value input:
- Whether OBO or a managed identity with scoped permissions scales better across multiple subscriptions and tenants
- How to handle Log Analytics query cost when an assistant makes investigation cheap and frequent
- Ways to express confidence or uncertainty in root-cause summaries so engineers don't over-trust them
I'll share the link here once the architecture post is published, along with the diagram and the end-to-end flow. Thanks again for pointing me in the right direction.
Regards
Shivanna Gundanavar