Making Azure AI Foundry Agents Explainable — Knowledge Graphs + Source Attribution

90% of Azure AI demos work on stage — most never ship. The gap is architecture, not the model. I wrote up a field guide on taking Azure AI Foundry agents from POC to production, with knowledge graphs (GraphRAG) doing the grounding and source attribution.

What the post covers

• Grounding with a knowledge graph — multi-hop retrieval + inline citations so every answer is traceable to a source (critical for regulated/medical use cases).
• Externalized state — keeping agent memory and session state outside the model.
• Identity at the boundary — Entra ID / RBAC instead of trusting the prompt.
• Observability & compliance — tracing, evaluation, and auditability.
• The stack — Azure AI Foundry + Model Context Protocol (MCP) + Azure Functions (Flex Consumption) + Azure OpenAI, from a real build (VeritasGraph medical MCP server).

📖 Full write-up:  https://bibinprathap.com/blog/azure-ai-proof-of-concept-to-production

▶️ 6-min walkthrough: https://youtu.be/z-CPS5WUvyw?si=fmpo1RN28Bh9KbIb

Questions for the community

1. How are you grounding Foundry agents today — vector RAG, GraphRAG, or hybrid?
2. Anyone combining knowledge graphs with MCP tools in Foundry? What worked / broke?
3. For regulated domains, how are you handling source attribution and audit trails?

Curious to compare notes — happy to share more detail on the GraphRAG retrieval design if useful.