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

[bibinprathap]

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

How are you grounding Foundry agents today — vector RAG, GraphRAG, or hybrid?
Anyone combining knowledge graphs with MCP tools in Foundry? What worked / broke?
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.

Source code: https://github.com/bibinprathap/azure-ai-foundry-veritas-graph