CLI tool
NVIDIA-AI-Blueprints/aiq avatar
NVIDIA-AI-Blueprints/aiq

NVIDIA AI-Q Blueprint: A Self-Hosted Deep Research Backend Built on NeMo Agent Toolkit and LangChain Deep Agents

The AI-Q NVIDIA Blueprint is an open reference example for building intelligent AI agents that connect to your enterprise data, reason using state-of-the-art models, and deliver trusted business insights.

866 stars261 forksPythonApache-2.0

At a glance

What is it?
AI-Q is an Apache-2.0 reference deployment for governed research workflows, not a general coding agent. It ships a CLI, web UI, async jobs, an MCP server, and benchmark harnesses, but it assumes you already have models, API keys, and data sources to point at it.
Who is it for?
Adopt AI-Q if you need a self-hosted research backend with citation-backed reports, per-message source selection, and an evaluation harness you can run yourself, and if you already operate NeMo Agent Toolkit and LangChain Deep Agents.
Can I use it commercially?
Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 13 days ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem AI-Q targets: research that has to be cited, governed, and self-hosted

Most teams that want an AI research assistant hit the same wall. A hosted assistant answers questions well but sends queries and retrieved documents to someone else's infrastructure, offers no way to plug in internal knowledge stores, and gives no control over which sources a given answer may use. AI-Q is NVIDIA's answer to that gap: a deployable research backend where the application boundary is self-hosted and the deployment owner connects models, data sources, authentication, policy controls, storage, and observability. The README frames the intent as governed research workflows, and explicitly excludes general-purpose coding agents. That exclusion matters. If your use case is refactoring a repository, this is the wrong project. If your use case is producing a citation-backed report from a mix of web, paper, enterprise, collaboration, and knowledge-layer sources that you choose per message, the shape fits. The target audience is not stated as a single role in the material, but the prerequisites point at teams already comfortable running Python services, supplying API keys, and editing YAML configuration files.

Two research depths and one orchestration node

The mechanism starts at a single orchestration node. According to the README, that node classifies intent as meta or research, produces meta responses for things like greetings and capability questions, and sets research depth to shallow or deep. Shallow research is described as a bounded, faster researcher with tool-calling and source citation. Deep research is the heavier path: advisory source routing, structured planning, concurrent researcher workers, bounded source-tool batching, and a dedicated writer that produces citation-backed reports and other requested output shapes. The release notes for the recent versions describe this as a replacement for an earlier three-role flow, with plan ownership moved out of the clarifier. That is a real architectural change rather than a prompt tweak, and it tells you the project is still reshaping its own pipeline. A separate clarifier agent exists and, like the orchestration node, shallow researcher, and deep researcher, can run standalone or as part of the full pipeline. The modularity is the interesting part: you can exercise one agent without standing up the whole graph, which is what makes the evaluation harnesses practical.

Configuration is YAML, and that is the tuning surface

Workflow behavior lives in YAML configs that define agents, tools, LLMs, and routing. The README states the goal directly: tune workflows without code changes. In practice this means the questions you will spend time on are which model backs which agent, which tools each researcher may call, and how routing decides between shallow and deep. The data source registry is also request-scoped: UI toggles and request payloads can select web, paper, enterprise, collaboration, and knowledge-layer sources per message. That per-message granularity is a stronger control than a global allowlist, and it is the mechanism behind the governance claim. Source coverage is broad and partly third-party: paper search supports Serper, SerpAPI, and SearchAPI, You.com contributes web, contents, general-research, and finance-research tools, Nimble adds configurable web search, and focused profiles demonstrate DuckDuckGo news, Polymarket, OpenSearch, and Azure AI Search knowledge retrieval. Each of those is an external dependency with its own key and its own terms, so the number of providers listed is also the number of things that can break independently.

Getting it running: clone, automated setup, keys, environment variables

The README's Getting Started sequence is short: clone the repository, run the automated setup, obtain API keys, and set up environment variables. The default branch is develop, so a plain clone lands you on the development line rather than a tagged release. For benchmark reproduction the README is explicit that you should use the drb1 or drb2 branches for DeepResearch Bench and DeepResearch Bench II respectively, because results consistent with those leaderboards come from those branches and not from develop. That is an unusual and useful disclosure: the branch you check out changes the numbers you get. Running the agents is offered through a CLI, a web UI, async deep research jobs, an MCP server, and Jupyter notebooks, with Docker Compose and Helm assets under deploy/compose/ and deploy/helm/deployment-k8s/. The source Helm chart is noted as honoring the Helm release namespace for every namespaced resource. The material does not spell out the exact setup script name or the individual environment variable names, so treat those as things to read from the repository rather than guess.

Skills, sandboxes, and where the durability stops

Built-in research and synthesis skills are exposed as host-side, read-only definitions. Skills that invoke code run through a provider-neutral sandbox contract, and the README names Modal and OpenShell as providers that create one physical sandbox per deep-research job. Rich-file capture is opt-in and checkpointed: it records manifest-declared files after successful sandbox commands, finalizes on success or failure, stores bytes in SQL or S3-compatible storage, and delivers metadata to the Files tab live and on replay. The word opt-in is doing real work here. If you do not enable capture, you do not get the durable artifact trail, and the replay behavior described depends on that capture having been on. This is one of the clearer trade-offs in the project: durability costs you a storage backend and a configuration decision, and the failure mode of skipping it is silent until you need to reconstruct what a job produced.

The honest limits: a blueprint is not a product

The first limitation is in the README's own framing. AI-Q is an open reference example and a blueprint, which means the deployment boundary, authentication, policy controls, and observability are things you connect, not things that arrive configured. The production API and auth surface is real (REST endpoints, async job ownership, per-user OAuth-protected MCP sources, token validator entry points, provider lifecycle hooks) but each is an entry point you wire up. The second limitation is the public MCP server, which the README describes as exposing stateless research tools for trusted networks. Trusted networks is a constraint, not a default. Exposing it more widely is a decision you make against the Security Considerations section. The third is the moving pipeline: the structured concurrent deep research flow replaced an earlier three-role design in recent releases, and the benchmark branches diverge from develop. If you build against internals rather than the YAML surface, expect churn. Finally, the source list is dominated by commercial search and retrieval providers, so cost and availability track those vendors rather than the Apache-2.0 code.

How AI-Q differs from a general agent framework

The natural comparison is a general-purpose agent framework such as LangChain's own agent building blocks, which AI-Q actually sits on top of through LangChain Deep Agents and the NeMo Agent Toolkit. The difference in approach is scope. A general framework gives you the loop and leaves retrieval, citation, routing, and evaluation to you. AI-Q ships an opinionated pipeline: intent classification, a depth decision, advisory source routing, concurrent researchers, and a dedicated writer whose output is citation-backed by construction. It also ships the measurement side, with built-in benchmarks such as FreshQA and DeepResearch plus evaluation scripts, and observability through NeMo Relay, ATOF, and OTEL export. The trade is flexibility for a working starting shape. If your research workflow looks nothing like report generation, the opinionated parts become obstacles you strip out, and a thinner framework would have been less work. If it looks roughly like this, the routing and evaluation scaffolding is the part you would otherwise spend months building.

Maintenance, licensing, and what to check before committing

The code is Apache-2.0, with SPDX headers in the source and the standard warranty disclaimer. That is permissive and places no copyleft obligation on your own code, but it says nothing about the third-party search providers, model endpoints, or sandbox vendors you connect, each of which carries separate terms. The material does not include a support policy or a compatibility matrix, so the practical maintenance question is how fast the pipeline moves. Recent releases landed within weeks of each other, with a release candidate before the stable tag, and the What's New section describes a structural rewrite of deep research. Plan for configuration review on upgrade rather than assuming YAML written for one version stays valid. Before adopting, verify three things against the repository itself: that your model endpoints and API keys satisfy the stated prerequisites, that the drb1 or drb2 branch is the one you want if benchmark comparability matters, and that your intended exposure of the public MCP server is consistent with the Security Considerations section. The evaluation harnesses are the strongest reason to pick this up, because they let you measure your own prompts and agent changes instead of trusting a vendor's summary.

Editorial conclusion

Adopt AI-Q if you need a self-hosted research backend with citation-backed reports, per-message source selection, and an evaluation harness you can run yourself, and if you already operate NeMo Agent Toolkit and LangChain Deep Agents. Do not adopt it as a general coding agent or as a drop-in product: the README states plainly that it is not a general-purpose coding-agent harness, and benchmark-consistent results require checking out the drb1 or drb2 branches rather than the default develop branch. Verify first that your model endpoints and API keys match the prerequisites, and read the Security Considerations section before exposing the public MCP server beyond a trusted network.

Official sources

  1. License: Apache-2.0
  2. NVIDIA-AI-Blueprints/aiq on GitHub
  3. Project website
  4. README
  5. Releases
Community notes

Community notes