Forum Discussion

shivannagundanavar's avatar
shivannagundanavar
Copper Contributor
Sep 24, 2026

Azure

Hi Microsoft Tech Community,

 

I have an idea around bringing Azure cloud operations into Microsoft Teams through a conversational assistant.

 

The concept is to provide a single Teams interface for Azure Monitor alerts, Log Analytics, Application Insights, Azure Cost Management, Microsoft Defender for Cloud, Resource Graph and Service Health.

 

The idea goes beyond sending Azure alerts to Teams. For example, after receiving an alert, an engineer could ask questions such as “Why did this happen?”, “Show related errors”, “Are any production resources unhealthy?” or “What caused the cost increase?”, and the assistant could retrieve the relevant Azure telemetry and provide a summarized response.

 

I would like to share the complete architecture and technical approach with the Microsoft community.

 

Could you please advise which Microsoft Tech Community, discussion space, or feedback/ideas portal would be the most appropriate place to publish this?

 

Thank you.

accessibility
Notifications

2 Replies

  • Surya_Narayana's avatar
    Surya_Narayana
    MCT
    Sep 26, 2026

    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.

    • shivannagundanavar's avatar
      shivannagundanavar
      Copper Contributor
      Sep 29, 2026

      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:

      1. 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.
      2. 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.
      3. 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.
      4. 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.
      5. 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