GitHub Blog

How we built an internal data analytics agent

GitHub's data and analytics organization built Qubot, an internal Copilot-powered analytics agent that allows employees to ask questions about data models in natural language and get answers within seconds. Qubot consists of three main components: a user interface available through Slack, VS Code, and Copilot CLI; a context layer that enriches Copilot's reasoning with curated documentation; and a query engine that connects to Kusto and Trino. The context layer proved critical for accuracy and speed, and Qubot reduced strain on the data team while enabling self-service analytics across the company.

Statesummarized
Snapshots1
AI Outputs2
Open issues0

validated summary

English

How we built an internal data analytics agent

GitHub's data and analytics organization built Qubot, an internal Copilot-powered analytics agent that allows employees to ask questions about data models in natural language and get answers within seconds. Qubot consists of three main components: a user interface available through Slack, VS Code, and Copilot CLI; a context layer that enriches Copilot's reasoning with curated documentation; and a query engine that connects to Kusto and Trino. The context layer proved critical for accuracy and speed, and Qubot reduced strain on the data team while enabling self-service analytics across the company.

  • Qubot is a Copilot-powered analytics agent that answers natural language queries about GitHub's data warehouse.
  • It has three components: user interface (Slack, VS Code, CLI), context layer (federated documentation), and query engine (Kusto and Trino).
  • The context layer enriches Copilot's reasoning and improves accuracy and speed by three times.
  • An evaluation framework with test cases, automated runs, and stats aggregation ensures quality.
  • Qubot reduced queries in data analytics Slack channels and enabled self-service for non-experts.
  • Multiple interfaces lower barriers: no configuration needed in Slack, integrated in VS Code and CLI.
  • Federated context contribution incentivizes teams to share knowledge in a single tool.

Chinese

我们如何构建内部数据分析代理

GitHub的数据与分析团队构建了Qubot,一个由Copilot驱动的内部分析代理,让员工能用自然语言提问数据模型相关问题,并在几秒内获得答案。Qubot包含三个主要组件:通过Slack、VS Code和Copilot CLI访问的用户界面;用精选文档丰富Copilot推理的上下文层;以及连接Kusto和Trino的查询引擎。上下文层对准确性和速度至关重要,Qubot减轻了数据团队负担,实现了全公司的自助分析。

  • Qubot是一个由Copilot驱动的分析代理,能用自然语言回答关于GitHub数据仓库的问题。
  • 它有三个组件:用户界面(Slack、VS Code、CLI)、上下文层(联邦文档)和查询引擎(Kusto和Trino)。
  • 上下文层丰富了Copilot的推理,将准确性和速度提升了三倍。
  • 评估框架包括测试用例、自动运行和统计聚合,确保质量。
  • Qubot减少了数据分析Slack频道中的查询量,使非专家也能自助分析。
  • 多种界面降低了门槛:Slack无需配置,VS Code和CLI集成度高。
  • 联邦上下文贡献激励团队在单一工具中共享知识。

AI agents / GitHub Copilot / analytics agent / data analytics / self-service analytics / context layer / evaluation framework / Kusto / Trino / Slack / VS Code / Copilot CLI

Full Article

Matteo Vasirani & Cynthia Joseph

June 19, 2026|

6 minutes

Share:Large data and analytics organizations often struggle to make access to data and insights truly self-serve. The industry tried to solve this problem, quite unsuccessfully, for decades, but now AI is giving us a credible way to do just that.At GitHub scale, providing dedicated analytics support to dozens of product teams is challenging, and therefore many teams are left to solve this problem on their own. Though there is a lot of valuable product telemetry that product and engineering teams can use to make decisions, figuring out which data model, which grain, which filter, and then write the query and validate the result has always been difficult without the support of a data analyst.Enter Qubot, our internal GitHub Copilot-powered analytics agent. Qubot allows any Hubber (that’s what we call GitHub employees) to ask questions about any data model in GitHub’s data warehouse in plain language and get an answer within seconds.Qubot is not a reporting tool or a dashboard replacement. Instead, it’s intended for exploratory questions like “Which cohort of users has the highest retention on this feature?” or “What product contributed to move this metric the most last week?” Qubot has zero cost maintenance and helps teams ramp up quickly on datasets they may be unfamiliar with.In this blog post, we’ll go over how we built Qubot, how it’s changed, and what we learned.How Qubot worksThe architecture has three main components: user interface, context layer, and query engine.User interfaceQubot is accessible through Slack, VS Code, and the Copilot CLI. The Slack interface doesn’t require any configuration, and it is the preferred collaboration tool of Hubbers. When someone posts a question in the Qubot Slack channel, a Qubot instance is spawned as a Copilot Cloud Agent running on github.com. The answer is provided directly in Slack, allowing the user to share the result with others, but also iterate in the thread to evolve or refine the question. All the results are also stored as a markdown report in a pull request that the user can reference to fine tune the query or use it in a dashboard.Qubot is also available in VS Code and the Copilot CLI, for users that want an experience more integrated with their workflows. Qubot can be installed with one command as a plugin, and it becomes available in any agent session in VS Code or Copilot CLI alongside any other custom agents, skills, and tools configured by the user.Context layerOur data warehouse contains data at different stages of curation: raw events (bronze), conformed facts and dimensions (silver), and curated datasets designed for specific business use cases (gold). The context layer is built in a federated way, with knowledge that is tailored to the type of data.For bronze data, we have telemetry context contributed by product teams, with schema information and metadata.For silver data, we have examples of queries, usage guidance, mandatory filters etc, maintained by the data and analytics team.For gold data, we have business rules and metric definitions, contributed by teams owning those datasets.We also leverage our ETL pipelines to systematically enrich the context layer with additional signals and derived metadata. The context is loaded at runtime via the GitHub MCP Server, fetching it from the context layer.Context agentThe context layer is constantly enriched with new knowledge persisted across multiple repositories. At GitHub, we primarily use markdown for documentation, so we don’t need to interface with multiple different tools.We’ve streamlined federated context contribution through a context agent. Teams can contribute via a standardized template or by referencing a repository containing relevant context. The agent then ingests, organizes, and normalizes this information into a structured format that has proven effective for Qubot based on our evaluations.Evaluation frameworkEvery change to the context layer or agent configuration gets evaluated before it ships. When someone wants to enrich the context layer with new knowledge, they can open a pull request. The new context goes through an offline eval framework that measures accuracy of the response, latency in finding the right answer, and catches regressions before they reach users.The benchmarking framework for evaluating Qubot across structured test cases has three components:Test cases : A curated dataset of prompts with known correct answers, ground-truth SQL, and metadata (domain, difficulty).Automated run orchestration : A script that automates launching each test case as an agent task with the GitHub CLI gh agent-task create , runs multiple parallel trials, polls for completion, and saves detailed JSON results.Stats aggregation : A reporting script that reads the saved results and computes per-test-case metrics: completion rate, accuracy, and duration (avg/min/max).The end-to-end flow is: define test cases → run Qubot N times per case → collect results → aggregate stats → compare configurations.Query engineQubot connects to both Kusto and Trino, the two query engines that power most of GitHub’s analytics workloads, via a MCP server. We developed a custom implementation of the Trino MCP server, while for Kusto we deployed a local version of the Fabric RTI MCP Server . Kusto is fast and well-suited to exploratory questions over recent event data. Trino handles complex joins and deeper historical analysis.Rather than forcing users to know which to use, Qubot defaults to Kusto and switches to Trino automatically when the question requires it.What changed, and what we learnedQubot has been widely adopted at GitHub, with hundreds of enthusiastic users running thousands of queries. The number of questions that Hubbers ask in the data and analytics Slack channels has reduced dramatically, because now they can explore the data with greater autonomy and reach out only for complicated questions. It also allows Hubbers that never dared to dip into the data warehouse to access the data they need to drive their decision making. That is one of the reasons for offering multiple interfaces like Slack, Copilot CLI, and VS Code; Hubbers are very technical, but we wanted to offer an option with no barrier to entry and zero configuration.We quickly discovered that the context layer is key to enriching the reasoning capabilities of Copilot and to create an expert analytics agent. In our experiments we found that structured and well curated context not only makes Qubot more accurate, but also three times faster at returning the right answer. This has profound implications on the analytics engineering discipline, because it makes this type of artifact a first class citizen in how data is modeled, rather than an afterthought.Qubot has been a rare example of successful hub-and-spoke execution. It removes strain from the data and analytics team, as product teams own the telemetry for their surfaces and business teams own the definition of their gold data. Qubot acted as a gravitational force to centralize all this distributed knowledge into a single tool that can benefit all GitHub, providing incentives to partner teams to contribute to Qubot, instead of creating multiple tools limited to their own domains.AcknowledgementsQubot engineering team : Weijie Tan, Tobias Tschuemperlin, Vamsi AnamaneniSpecial thanks : Yaswanth AnantharajuTags:

AI agents

GitHub Copilot

GitHub Copilot CLIWritten byAs a staff manager of software engineering, Matteo Vasirani leads product analytics and data science at GitHub.Cynthia Joseph is senior product manager for the Data team.Related postsAI & ML

Getting more from each token: How Copilot improves context handling and model routingHow GitHub Copilot is making more of each session go toward useful work, so your credits go further.AI & ML

What are git worktrees, and why should I use them?Git worktrees have been around since 2015, but it wasn’t until recently they became popular. Learn what they are, how to use them, and why you might.AI & ML

GitHub Copilot CLI for Beginners: Overview of common slash commandsGitHub Copilot CLI for Beginners: Learn how to use slash commands to control your terminal AI agent.We do newsletters, tooDiscover tips, technical guides, and best practices in our biweekly newsletter just for devs.Your email address

Snapshots

Fetch evidence retained for parsing and audit.

200 · text/html; charset=UTF-8

06/20/2026, 08:01 AM

ba30424c617005fde443899cd7e8114ec60d62524810f7bd14b1206ab05d1502

AI Outputs

Structured model outputs with validation status.

article.summarize

deepseek-v4-flash · valid

{"tags":["AI agents","GitHub Copilot","analytics agent","data analytics","self-service analytics","context layer","evaluation framework","Kusto","Trino","Slack","VS Code","Copilot CLI"],"titleEn":"How we built an internal data analytics agent","titleZh":"我们如何构建内部数据分析代理","summaryE...
article.classify

deepseek-v4-flash · valid

{"relevant":true,"confidence":0.95,"primaryTopic":"agent-engineering","secondaryTopics":["ai-engineering","software-engineering"]}

Quality And Digest Links

Open and resolved issues, plus daily digest appearances.

digest

Signal Hub 2026-06-20

本文描述了一个内部分析AI代理的实践实现,强调了上下文层的关键作用,对考虑类似工具的数据和工程团队直接有用。 (score: 0.90)

position 106/20/2026, 12:00 AMdraft