AH
Ali Hasan
← Back to Agentic AI Architecture
Research Analyst Technical Research Role: Staff Researcher

dig-deep

Multi-Source Deep Technical Research & Verification

$ invoke_subagent('dig-deep')
Trigger Scenarios (When Needed)
  • When evaluating competing frameworks, libraries, or cloud technologies for production adoption.
  • When investigating intricate technical bugs or root-cause post-mortems.
  • When researching state-of-the-art architectures, RFCs, or consensus protocols.
  • When making high-stakes technical architectural decisions that require multi-source consensus.
Activation & Guardrails

Trigger: Activated when the user requests an in-depth technical deep-dive, library comparison, or architectural investigation.

Execution Rules:
Must formulate 3-5 specific research questions and confirm with the user before executing.
Must search and cite at least 5 distinct, authoritative sources (official documentation, engineering blogs, RFCs, source code).
Never uses social media (Reddit, Twitter) as primary source anchors.
Explicitly flags knowledge gaps and single-source claims as unverified; zero hallucinations allowed.
Example Prompt: "Dig deep into NATS JetStream vs Kafka for IoT geospatial telemetry."
Technical Architecture & Data Contracts
Execution Pattern

Multi-Source Evidence Cross-Referencing & Structured Synthesis

Context Budget

100,000 token budget for clean, targeted research lookups without context bloat.

State Management

Saves structured technical reports to docs/research/[topic-slug].md.

Input Contracts
Research Topic & Operational Context Specific Evaluation Criteria or Constraints
Output Contracts
docs/research/[topic-slug].md (Audited Technical Report) Comparative Architecture & Benchmark Tables
Bundled Scripts & Reference Resources

Reference Specifications (`references/`)

source-priority.md Verification Protocol

Hierarchical source reliability ranking (RFCs/Official Docs > Engineering Blogs > Community Articles).

research-types.md Taxonomy Specification

Framework-specific focus areas for library evaluations, bug post-mortems, and architectural surveys.

report-template.md Document Template

Standardized markdown template enforcing factual claims, trade-off matrices, and actionable conclusions.

Executive Overview

Generic LLM search lookups often produce superficial summaries filled with hallucinated APIs, outdated library syntax, or regurgitated marketing fluff.

dig-deep is an evidence-backed technical research skill engineered to function like a Staff Research Engineer. It searches at least 5 distinct, authoritative sources, cross-examines conflicting engineering claims, and generates production-ready whitepapers stored in docs/research/.


3-Phase Research Protocol

[Phase 1: Research Brief]   --> Formulates 3-5 targeted research questions with user

[Phase 2: Execution]        --> Queries >= 5 distinct sources across hierarchical tiers

[Phase 3: Synthesis]        --> Formulates comparative tables & saves docs/research/*.md

1. Hierarchical Source Priority (source-priority.md)

To guarantee technical integrity, dig-deep evaluates sources in strict order of authority:

  1. Tier 1 (Primary / Authoritative): Official vendor documentation, RFC specifications, language standards (TC39, ISO C++, PEP), and open-source repository source code.
  2. Tier 2 (Enterprise Engineering Blogs): Engineering blogs of companies operating at hyperscale (e.g., Uber, Netflix, Meta, Cloudflare, Discord).
  3. Tier 3 (Peer-Reviewed / Benchmark Papers): Academic papers (arXiv), formal benchmarks, and published CVE disclosures.
  4. Disallowed as Primary Anchors: Forum posts, Reddit, or opinionated personal blogs are strictly restricted to secondary anecdotal context and can never anchor a conclusion.

Zero-Hallucination Guardrails

  • Consensus Checking: A claim is only accepted as fact if confirmed by multiple independent Tier 1 or Tier 2 sources.
  • Explicit Knowledge Gaps: If documentation is contradictory or unverified, the skill explicitly states: “Knowledge gap identified: Source A asserts X, while Source B benchmarks Y. Marked as unverified.”
  • Production Library Vetting: When evaluating dependencies, dig-deep analyzes GitHub stars, commit cadence, release frequency, open CVEs, and dependency bloat before recommending adoption.