There’s been an important development in the Agentic RAG & Foundry IQ space that caught my attention, and I wanted to break it down — not just what was announced, but why it matters and how it fits into the bigger picture.
What’s New
Software may be written in programming languages, but human language is at the heart of developer collaboration. Developers explain how projects work in READMEs. They ask for help in issues. They review, debate, and improve code in pull requests. That collaboration often happens in English—but not always. As AI becomes a bigger part of how developers build software, multilingual developer content matters more than ever.
Today, GitHub is publishing theGitHub Multilingual Repositories Dataset, a repository-level metadata dataset designed to help researchers and developers discover public GitHub repositories with evidence of non-English natural-language content. When building the dataset, we found that language distribution differs across READMEs, issues and pull requests: Korean is the most common non-English language in issue text, but only the fifth-most common in READMEs. Portuguese tops the non-English README list with more than 3 million repositories.
The dataset is now available onGitHubunder CC0-1.0. It follows through on a commitment we made in 2025, as part ofMicrosoft’s European Digital Commitments,to make multilingual data more accessible, including to open source AI developers.
What’s in the dataset
The GitHub Multilingual Repositories Dataset is intentionally not a dump of repository content. Instead, it is a metadata dataset that helps developers and researchers find repositories where multilingual collaboration may be happening. The dataset coversover 80 million classification rows across more than 40 million repositories. For each public repository, we provide:
Language classifications of the README, the most-commented issue, and the most-commented pull request, with the first 150 characters of each used as the input sample. We exclude texts under 20 characters.
Classifications for each text source, fromfastText,gcld3, andlingua-py, each with a confidence score. The dataset only includes classifications with >0.5 confidence.
Repository metadata: creation timestamp, disk usage, stars, forks, primary programming language, SPDX license, issue and pull request counts, and the snapshot date.
What you can build with it
The dataset is designed for the kind of work that’s hard to do with general web text:
Discoverrepositories likely to contain developer documentation or collaboration in specific languages.
Studyhow non-English developer communities use issues, pull requests, and READMEs.
Buildevaluation sets for AI coding tools, doc generators, or review assistants that need to behave well across languages.
Key Takeaways
- Software may be written in programming languages, but human language is at the heart of developer collaboration.
- Today, GitHub is publishing theGitHub Multilingual Repositories Dataset, a repository-level metadata dataset designed to help researchers and developers discover public GitHub repositories with evidence of non-English natural-language content.
- The dataset is now available onGitHubunder CC0-1.0.
- The GitHub Multilingual Repositories Dataset is intentionally not a dump of repository content.
- We deliberately did not collapse the three classifiers into a single label.
Why This Matters
Traditional RAG is a static pipeline: query → retrieve → generate. Agentic RAG flips this — the agent decides when to retrieve, what to retrieve, and how many steps of retrieval to perform based on the complexity of the question. Foundry IQ (alongside Fabric IQ and Work IQ) provides the enterprise intelligence backbone that makes this context engineering practical at scale.
This development is particularly significant because it reflects the broader industry shift toward making AI more accessible, enterprise-ready, and integrated into existing workflows. For teams already invested in the Microsoft ecosystem, this is a clear signal of where the platform is heading.
My Take
The shift from static RAG to Agentic RAG is architecturally significant. Three patterns define the new state of the art: (1) Agent-driven retrieval planning — instead of a fixed retrieval step, the agent evaluates query complexity and dynamically decides whether to do single-hop retrieval, multi-hop reasoning across documents, or decompose into parallel sub-queries. (2) Foundry IQ as context layer — a unified intelligence surface that combines knowledge indices, enterprise memory, and organizational graph into a single query plane that agents can access through standard tool interfaces. (3) Context engineering over prompt engineering — the focus shifts from crafting clever prompts to building robust knowledge pipelines that deliver the right context at the right time. What’s technically compelling is how Foundry IQ integrates with Azure AI Search’s agentic retrieval mode — the search service itself becomes an agent that can re-rank, filter, and synthesize across heterogeneous data sources. Combined with AI Citadel’s governance controls, you get enterprise-grade knowledge access with full auditability.
Business Translation
For the C-Suite: Agentic RAG with Foundry IQ transforms your enterprise knowledge from a cost center into a revenue-generating intelligence asset. Traditional search gives you documents; Agentic RAG gives you answers grounded in your entire organizational memory. The ROI case: 80-90% reduction in knowledge worker research time, 3-5x improvement in decision quality (measured by accuracy and completeness vs. manual research). Foundry IQ’s enterprise intelligence layer means every AI agent you deploy gets smarter because it draws from the same organizational knowledge graph — creating compounding returns as your data and context grow. Organizations without this intelligence layer are building agents that operate in isolation, repeatedly solving problems your organization has already solved.
📖 Read the original article for the full details and official documentation.
Written by Cyril Bou-Harb — Solution Engineer, Cloud & AI at Microsoft. Opinions and analysis are my own and do not represent Microsoft’s official position.