Architecture

Overview

The Deep Research Assistant is a governed AI research runtime built on Google ADK 2.0. It implements a staged epistemic pipeline: intent → scope → research perspectives → question graph → search plans → retrieved sources → evidence extraction → claim construction → contradiction analysis → coverage analysis → outline → section drafts → independent verification → approval → final report.

Unlike monolithic chatbot approaches, the system’s fundamental unit of quality is a supported, qualified, and traceable claim — not a polished paragraph.

Workflow Topology

The shipped runtime is a 27-node ADK 2.0 Workflow graph with branching edges for approval gates, iterative loops, repair cycles, and resumable execution.

START
  → scope_classify (Research Director)
  → perspective_generate (Perspective Planner)
  → question_graph_build (Question Architect)
  → approve_plan [Gates A/B] ←→ scope_classify (reject)
  → scheduler_select (Frontier Scheduler)
  → search_plan_create (Query Planner)
  → source_retrieve (Web Search)
  → source_policy_apply (Dedup + Classify + Filter)
  → evidence_extract (Evidence Curator)
  → claims_construct (Claim Builder)
  → knowledge_organize (Knowledge Organizer)
  → contradictions_search (Counter-Evidence Agent)
  → coverage_calculate (Info-Gain Metrics)
  → moderator (Research Moderator)
  → interventions_apply (User Interventions)
  → scope_change_apply (Queued scope changes)
  → stop_evaluate ←→ scheduler_select (continue loop)
  → outline_build (Outline Architect)
  → approve_outline [Gate C] ←→ outline_build (reject)
  → draft_generate (Section Writer)
  → verify_draft (Verification Agent)
  → repair_draft ←→ verify_draft (repair loop)
  → final_gate_check [Gate D]
  → render_output

Component Architecture

Agent Roster (14 LLM Agents)

Deterministic Nodes and Runtime Services

Data Model

Core Entities

ResearchRun
├── ResearchObjective (title, primary_question, decision_to_support)
├── ResearchScope (included/excluded topics, constraints, risk_level)
├── Perspective[] (name, purpose, required_questions, budget_weight)
├── ResearchQuestion[] (text, type, priority, parent/child edges)
├── SearchPlan[] (queries, source mix, stop conditions)
├── SourceRecord[] (canonical_uri, authority_class, independence_cluster)
├── EvidenceFragment[] (exact_excerpt, normalized_statement, confidence)
├── Claim[] (text, atomic_form, epistemic_status, evidence_ids)
├── Contradiction[] (claim_ids, type, resolution_status)
├── OutlineSection[] (title, required_claim_ids, minimum_evidence)
├── SectionDraft[] (content, cited_claim_ids)
├── VerificationFinding[] (type, severity, claim_id)
├── ApprovalDecision[] (gate, status, decided_at)
└── ResearchMetrics (coverage, confidence, cost, latency)

Durable Runtime Records

The runtime now persists more than the top-level run row:

• research_runs stores the latest materialized state plus runtime fields such as current_node, awaiting_approval_gate, resume_from_checkpoint_id, retry_count, and workflow_version.
• workflow_checkpoints stores checkpointed workflow state after key node boundaries.
• workflow_node_executions stores idempotency keys, checkpoint linkage, and cached results.
• approval_decisions stores gate state as first-class durable records.
• audit_events stores append-only, chain-verified governance events.

Trust Boundaries

1. User → API: OAuth / API key authentication
2. API → Workflow: Run-scoped identity propagation with explicit tenant_id, user_id, and delegated scopes
3. Agent → Tools: Policy engine evaluates {principal, action, stage, risk} → {allow, deny, confirm}
4. Evidence → Claims: Data/instruction channel separation (prompt injection defense)
5. Claims → Report: Citation entailment verification before rendering
6. Report → Publication: Approval Gate D for external distribution

Current Governance Behavior

• API-created runs initialize a real principal and enable strict approval enforcement.
• Required gates pause execution in awaiting_approval until /approvals/{approval_id} is called.
• Audit and checkpoint writes are durable for persisted runs and intentionally skipped for pure in-memory workflow tests.
• Resume behavior restores the latest checkpoint and continues from the checkpointed node boundary instead of replaying the full run from scratch.

Model Routing

The verifier uses a distinct system prompt and lower temperature from the section writer to enforce the independence rule.