On May 20, 2026, NVIDIA published a technical article explaining how to package AI-Q’s deep-research capability as a “specialized skill” callable by agent harnesses such as Claude Code, Codex, and OpenCode. The key point is not merely that another AI tool exists, but that the design proposes a clearer separation for enterprise Agents: a general-purpose agent harness manages conversation, tool orchestration, code execution, and user interaction, while a specialized research backend handles multisource retrieval, planning, synthesis, citations, evaluation, and enterprise data governance. (NVIDIA Developer)

1. Background: Why Shouldn’t a General-Purpose Agent Perform Deep Research Directly?

Harnesses such as Claude Code, Codex, and LangChain Deep Agents are effective interaction entry points for developers. They maintain conversations, invoke tools, execute code, and turn user intent into action chains. But when the task becomes “generate a cited research report from multiple enterprise documents, internal databases, external materials, and regulated data sources,” the complexity quickly grows from “call several tools” into “build a complete research pipeline.” NVIDIA explicitly notes that enterprise teams must address data access, authentication, query routing, prompt tuning, output evaluation, and citation fidelity, and that these concerns should not be reimplemented in every harness. (NVIDIA Developer)

That is the role of the AI-Q Skill: package Deep Research as a portable agent skill. A harness submits a research task to a local or hosted AI-Q server and waits for a structured, cited report. The research pipeline itself remains inside an enterprise-controlled environment, so sensitive raw data does not need to be exposed to the external agent harness. (NVIDIA Developer)

This design rests on an important engineering judgment: Deep Research is not “a longer prompt”; it is a systems-engineering problem. It requires task classification, clarification, retrieval, planning, iteration, synthesis, citation verification, access control, asynchronous job management, observability, and an evaluation loop. Treating it as a specialized backend, rather than asking a general Agent to assemble it ad hoc, is a more robust path to enterprise deployment.

2. Core Concepts: Responsibility Boundaries Between Harness, Skill, and Research Backend

In this architecture, the agent harness is the entry layer. It serves developers or business users, understands requests, manages context, calls tools, and presents results. A Skill is the capability-declaration layer, usually composed of SKILL.md and helper scripts, and tells the harness when and how to invoke a capability. The research backend is the execution layer that performs the research flow, accesses data, and generates the report.

NVIDIA AI-Q’s skill package lives under .agents/skills/aiq-research/. Its installation root must contain SKILL.md, and it includes a scripts/aiq.py helper that routes /chat requests, submits asynchronous deep-research jobs, polls status, and retrieves reports. The AI-Q documentation also gives installation-path examples for Claude Code, Codex, and OpenCode. (GitHub)

The separation has several benefits. First, the harness does not need to know the details of enterprise retrieval, RAG, MCP, authentication, and citation verification. Second, one AI-Q server can be reused by multiple harnesses. Third, the enterprise can centralize data access, auditing, and model routing in a controlled backend instead of scattering them across developer tools and IDE plugins.

The call chain can be understood as follows:

User / Developer
    ↓
Agent Harness: Claude Code / Codex / OpenCode / Deep Agents
    ↓
AI-Q Research Skill: SKILL.md + scripts/aiq.py
    ↓
AI-Q Server: /chat + asynchronous deep-research jobs
    ↓
Research Pipeline: intent → clarify → shallow/deep research → citation-backed report
    ↓
Structured report with citations

3. The AI-Q Research Pipeline: Not One Agent, but a Set of Evaluatable Agents

AI-Q does not simply attach a large model to a search tool. It is a multistage research system. NVIDIA’s AI-Q Blueprint states that it is based on NVIDIA NeMo Agent Toolkit and uses LangChain Deep Agents. It can produce both quick cited answers and deeper report-style research, and includes benchmark and evaluation harnesses so teams can measure quality continuously. (GitHub)

Architecturally, AI-Q uses a LangGraph-based state machine whose core components include an intent classifier, shallow researcher, and deep researcher. The intent classifier decides whether a request is a meta question or a research question and whether research should be shallow or deep. The shallow researcher suits fast, bounded, tool-augmented retrieval; the deep researcher handles multistage, long-running work with planning and citation management. (GitHub)

More specifically, the architecture documentation describes an Intent Classifier, Clarifier Agent, Shallow Researcher, and Deep Researcher, coordinated by a Chat Researcher Orchestrator. The Clarifier Agent is particularly valuable: before deep research begins, it generates a plan and asks for human confirmation, preventing an agent from starting expensive retrieval and long-form report generation while the question remains unclear. (GitHub)

Inside the Deep Researcher, AI-Q further uses an orchestrator, planner, and researcher subagents. NVIDIA describes a flow in which the orchestrator asks the planner for a research plan; the planner searches and builds an evidence-backed outline; then, in two research loops by default, the orchestrator dispatches researchers to query sources, synthesize relevant material, update the draft, and identify gaps, before producing a citation catalog and final report. (NVIDIA Docs)

AI-Q’s “deep research” therefore resembles a small research team. One role classifies the task, another clarifies the request, another performs quick verification, another creates a systematic plan, others conduct topic-specific searches, and another integrates the report and citations. This structure makes quality control and failure localization easier than “one Agent + a search tool + a long context.”

4. The Key Innovation: Exposing Deep Research as an Agent Skill

The most important innovation in the NVIDIA article is exposing AI-Q’s complete research pipeline as a portable agent skill. The skill lets Claude Code, Codex, and other general agents submit research tasks to a running AI-Q server and receive formatted, detailed, cited reports. It contains SKILL.md and a helper script that handles request routing, job submission, polling, and result retrieval. (NVIDIA Developer)

This goes beyond a plain REST API. A REST API is designed for programmers; a skill is designed for an agent harness. SKILL.md is not merely interface documentation. It is a capability specification that tells the Agent when to use the capability, how to call it, what it returns, and which limitations apply. AI-Q can therefore be triggered with natural language such as “research a regulatory topic and generate a memo from our internal policy documents.” The harness delegates the task to AI-Q instead of assembling search and report generation itself. (NVIDIA Developer)

From an engineering perspective, a skill is a lightweight but important capability-governance boundary. An enterprise can require every task involving internal knowledge bases, multisource verification, compliance citations, and long-form report generation to pass through the AI-Q research skill rather than allowing arbitrary agents to read raw sources directly. Permissions, audits, cost controls, and quality evaluation can then be centralized.

5. Enterprise Data Access: MCP Connects AI-Q to Existing Systems

NVIDIA particularly emphasizes MCP integration. The new AI-Q version acts as an MCP client that connects to authenticated MCP servers, exposing existing enterprise systems as data sources for the research pipeline instead of requiring a parallel retrieval stack built only for AI-Q. The article identifies three authentication modes: MCP servers without per-user authentication, MCP servers using backend or application credentials, and custom AI-Q tools whose downstream APIs trust the AI-Q user’s bearer token. (NVIDIA Developer)

MCP, the Model Context Protocol, is an open standard for connecting AI applications to external systems such as local files, databases, search engines, tools, and workflows. Its official documentation compares MCP to “USB-C for AI applications,” intended to reduce integration complexity between AI applications and external systems. (Model Context Protocol)

MCP currently defines two standard transports: stdio and Streamable HTTP. Streamable HTTP is better suited to remote services, authentication, and multiclient connections in enterprise settings. The MCP specification requires Streamable HTTP implementations to validate the Origin header, recommends binding local services to localhost, and requires appropriate authentication to reduce risks such as DNS rebinding. (Model Context Protocol)

For authentication, MCP’s HTTP authorization specification is based on OAuth 2.1, OAuth 2.0 Authorization Server Metadata, Dynamic Client Registration, and Protected Resource Metadata. Protected MCP servers must use Protected Resource Metadata to declare the location of their authorization server, and clients should use the metadata to discover it. (Model Context Protocol)

The NVIDIA article also notes an easily overlooked but practical limitation. When AI-Q forwards a logged-in user’s bearer token to a downstream API or MCP gateway, it captures the token when the job is submitted and restores it inside the asynchronous Dask worker. The current version does not refresh the token while the job runs. If a research task outlives the access token’s TTL, later authenticated tool calls fail. (NVIDIA Developer)

This is important in enterprise deployment. Deep Research is often long-running and may take several minutes or more. If access-token TTLs are short, the design must address token refresh, job timeouts, retries, permission degradation, and user reauthorization, or the system will become unstable during the most critical asynchronous stage.

6. Deployment: Run the Research System Where the Data Lives

Another focus of NVIDIA’s article is “researcher deployed where your data lives.” AI-Q Blueprint provides Docker Compose and Helm charts, so the same blueprint can run on a developer laptop, a local or cloud Kubernetes cluster, or even an air-gapped data center. (NVIDIA Developer)

This is especially important in healthcare, finance, government, and manufacturing. Raw documents and enterprise data can remain in a controlled environment, where AI-Q retrieves, synthesizes, and generates reports internally. The agent harness receives only a cited output instead of direct access to raw data. The article also notes that open models such as Nemotron can be deployed locally through NVIDIA NIM while cloud frontier models remain configurable, letting enterprises choose a model path according to cost, compliance, and performance. (NVIDIA Developer)

AI-Q’s GitHub documentation shows support for CLI, Web UI, and asynchronous jobs. Web mode starts a backend API server and frontend UI, while Docker Compose supports a local no-auth setup. (GitHub)

The AI-Q API also offers asynchronous job handling with job tracking, Dask scheduling, SQLite or PostgreSQL job stores, SSE streaming, event replay, cancellation, and final-report retrieval. Routes include /v1/jobs/async/submit, /v1/jobs/async/job/{id}/stream, /v1/jobs/async/job/{id}/cancel, and /v1/jobs/async/job/{id}/report. (GitHub)

These capabilities show that AI-Q is not a demo chatbot but a backend service designed for product integration. Long-running tasks, asynchronous execution, event streams, durable results, and production-database support are essential to enterprise agent workflows.

7. Relationship to LangChain Deep Agents

AI-Q does not replace LangChain Deep Agents; it uses that framework inside a more specialized research backend. The official LangChain documentation describes deepagents as a harness for long-running agents with built-in task planning, filesystem-based context management, subagent spawning, and long-term memory, while its LangGraph runtime provides durable execution, streaming, and human-in-the-loop support. (LangChain Docs)

AI-Q’s Deep Researcher documentation explicitly says it constructs an agent with create_deep_agent and uses the deepagents library for subagent coordination. In other words, LangChain Deep Agents supplies composable agent-runtime capabilities, while AI-Q places them inside a complete blueprint for enterprise Deep Research. (NVIDIA Docs)

The lesson is not to conflate an agent framework, an agent harness, and a business capability. LangGraph, Deep Agents, and NeMo Agent Toolkit solve how to build and run agent workflows. AI-Q Research Skill solves how to expose enterprise Deep Research as a reusable capability to other agents.

8. A Minimal AI-Q Skill Integration

The following simplified process is suitable for a proof of concept. Use the official repository as the authority for exact commands.

First, prepare the AI-Q server:

git clone https://github.com/NVIDIA-AI-Blueprints/aiq.git
cd aiq

./scripts/setup.sh

cp deploy/.env.example deploy/.env
# 编辑 deploy/.env，填入 NVIDIA_API_KEY、TAVILY_API_KEY、SERPER_API_KEY 等

./scripts/start_e2e.sh

The AI-Q README explains that ./scripts/setup.sh creates a Python virtual environment and installs core dependencies, frontends, benchmarks, and data sources. Web UI mode starts the backend API server and frontend UI with ./scripts/start_e2e.sh. (GitHub)

Next, install the AI-Q skill in the harness’s skills directory. For a repo-local Claude Code skill:

mkdir -p .claude/skills
ln -s ../../.agents/skills/aiq-research .claude/skills/aiq-research

For OpenCode, the user-level directory is:

mkdir -p ~/.config/opencode/skills
cp -R .agents/skills/aiq-research ~/.config/opencode/skills/aiq-research

The AI-Q agent-skills documentation states that Claude Code supports .claude/skills/, OpenCode uses ~/.config/opencode/skills/, and Codex or another Agent Skills-compatible tool requires installing aiq-research in the appropriate runtime skills directory, with SKILL.md and scripts/aiq.py inside. (GitHub)

To test a deep-research job directly through the API, use a call like:

curl -X POST http://localhost:8000/v1/jobs/async/submit \
  -H "Content-Type: application/json" \
  -d '{
    "agent_type": "deep_researcher",
    "input": "Research the regulatory landscape for AI agents in financial services and produce a cited executive memo."
  }'

curl http://localhost:8000/v1/jobs/async/job/{job_id}/stream

curl http://localhost:8000/v1/jobs/async/job/{job_id}/report

The AI-Q API documentation says deep_researcher performs comprehensive multiloop deep research and shallow_researcher performs quick single-turn research. The job stream emits events such as job.status, workflow.start, llm.chunk, tool.start, artifact.update, and job.error. (GitHub)

9. Engineering Extension: How Should an Enterprise Productize It?

First, establish a unified Research Skill Gateway. Do not connect each team’s Claude Code, Cursor, internal chatbot, or Slack bot directly to different data sources. Route every deep-research task requiring enterprise data through one gateway. The Gateway handles authentication, permission mapping, tenant isolation, rate limiting, audits, model routing, and cost records, while AI-Q server serves as the core research runtime.

Second, establish a Data Source Registry. AI-Q already supports a data-source registry, and request payloads can select web, paper, enterprise, collaboration, and knowledge-layer sources. Knowledge Layer also provides pluggable abstractions for document ingestion and retrieval, allowing backends to change without application-code changes. (GitHub)

Third, treat MCP servers as the enterprise’s controlled tool layer. MCP is well suited to connecting issue trackers, wikis, repositories, document stores, CRM and BI systems, and internal APIs. But do not place every tool description in model context at once. MCP client best practices note that when a host connects to many servers and hundreds or thousands of tools, naively loading all definitions at startup wastes tokens, increases latency, and lowers model performance. Progressive discovery and programmatic tool calling are more scalable. (Model Context Protocol)

Fourth, integrate evaluation into CI/CD. The AI-Q README mentions built-in evaluation pipelines such as Deep Research Bench and FreshQA, while the Deep Researcher documentation says reports are evaluated with Deep Research Bench’s RACE and FACT metrics. (GitHub)

An enterprise can add a domain-specific golden set: summaries of regulatory changes in the past 12 months, analysis of a competitor’s prospectus, internal incident reviews, and customer SLA risk assessments. Metrics should include not only model scores but source recall, citation precision, unsupported-claim ratio, freshness, latency, cost, authentication-failure rate, and human-override rate.

Fifth, prioritize observability. NVIDIA notes that NeMo Agent Toolkit emits OpenTelemetry traces, allowing compliance teams to inspect which sources were retrieved, how they were used, and how the final answer was generated. OpenTelemetry defines itself as an open-source observability framework for cloud-native software that collects traces, metrics, and logs. (NVIDIA Developer)

For Agent systems, traces are not only a debugging tool but the basis of governance. A deep-research run should at minimum identify the user, task, whether routing was shallow or deep, which MCP servers were called, which credentials were used, which documents were read, which sources entered the citations and which were rejected, token use and latency for each planner/researcher round, and whether the final report passed citation validation.

10. Common Risks and Design Recommendations

The first risk is permission leakage. AI-Q keeps raw data inside the enterprise environment, but an overly broad MCP server, a service account unable to distinguish users, or a downstream API that ignores row-level security can still let the agent access unauthorized data. Production systems should prefer per-user authorization or tightly scoped service accounts and filter fields before returning data to the model.

The second risk is citation hallucination. AI-Q emphasizes citation management and citation-backed reports, but enterprises should still implement post-processing checks: whether each citation came from retrieved results, whether the cited paragraph supports the claim, whether the model generated a fake URL, and whether a cited document is stale. AI-Q’s architecture documentation says research responses pass through a deterministic post-processing pipeline that validates citations against actual retrieved sources and generates an audit trail. (GitHub)

The third risk is instability in long-running work. Deep Research is asynchronous, long-running, and tool-intensive, making it vulnerable to token expiration, network timeouts, search-API throttling, transient model failures, and worker restarts. AI-Q’s job status, SSE stream, event replay, cancellation, and final-report endpoints provide a foundation, but enterprises must add job idempotency, checkpoint restoration, dead-letter queues, retry budgets, and user-facing progress summaries. (GitHub)

The fourth risk is uncontrolled cost. Deep Research may trigger multiple search rounds, several model calls, long-context synthesis, and citation verification. Configure task class, maximum loops, tool-call budget, source allowlist, model-routing policy, and a cost ceiling at the request layer. At the evaluation layer, monitor the average cost per acceptable report instead of only per-call token use.

The fifth risk is tool and context growth. As the number of MCP servers and tools grows, the Agent faces an increasingly complex action surface. The answer is not more context, but layered tools, on-demand discovery, task routing, and skills that explicitly encode when to use a capability in Skill or Gateway policy.

Phase 1 is a local proof of concept. The goal is not to connect all enterprise data, but to validate the AI-Q server, skill invocation, shallow/deep routing, asynchronous jobs, report generation, and citation display. Begin with web search, paper search, and a small number of redacted documents.

Phase 2 is controlled data access. Select a low-risk but real business knowledge base, such as public policies, product documents, historical FAQs, or engineering RFCs. Connect it through Knowledge Layer or an MCP server and validate permissions, citations, update frequency, and retrieval quality.

Phase 3 is the evaluation loop. Create 50–200 representative tasks covering factual QA, comparisons, trend summaries, compliance memos, and synthesis of internal documents. Run evaluation after every prompt, model, retriever, or source change, recording quality, latency, cost, and failure type.

Phase 4 is productionization. Add Kubernetes and Helm, a PostgreSQL job store, centralized logs, OpenTelemetry traces, secret management, tenant isolation, RBAC, DLP, audit reports, and human approval. AI-Q is then no longer a research demo but an internal Research Capability Service.

Phase 5 is reuse across harnesses. Let Claude Code, Codex, OpenCode, internal web chat, Slack bots, and IDE plugins call AI-Q through the same Research Skill Gateway. The enterprise governs Deep Research once and reuses it through multiple development and business entry points.

Conclusion: The Future of Agents Is Not “One Omnipotent Brain,” but “A Governable Capability Network”

The value of NVIDIA’s article is that it does not describe Deep Research as a stronger chatbot. It decomposes it into a reusable, deployable, authenticated, auditable, and evaluatable enterprise capability. A general agent harness handles interaction and orchestration, the AI-Q skill exposes the capability, the AI-Q server runs the deep-research pipeline, MCP connects enterprise sources, and OpenTelemetry plus the evaluation harness closes the governance loop.

For engineering teams, the most important lesson is not to rebuild an incomplete research pipeline inside every Agent project. Package Deep Research as a specialized backend skill and expose it through standardized skills, MCP, asynchronous APIs, and a unified governance layer. That direction is much closer to a production-grade Agent system.