LeadGrow GTM · Internal Architecture Review · 2026-06-12

How GTM Orchestrator stacks up against the reference designs

Two source-verified comparisons of the Orchestrator against the kkrlstrm reference repos — built on three independent recon passes over cloned source, deep on observability, cost, agents, durability, feedback loops, quality gates, and storage.

Report 01 · Pipeline

Orchestrator vs. gtm-pipeline

18-stage production pipeline vs. a 7-stage provider-agnostic reference. Verified carry-overs, our real advantages, and three corrected errors from the first-pass audit.

Read the comparison →

Report 02 · Research · PRD

gtm-research → Orchestrator

A cost-optimized, source-verified research engine compared on cost and outcome — with a phased PRD for integrating its cache + verify patterns without inheriting its risks.

Read the PRD →

Headline findings

The first-pass audit had cross-run learning backwards — we already run a live Nexus feedback loop; neither reference repo has one. It's our advantage, not a gap.
Three verified carry-overs from gtm-pipeline: role/title expansion as a frozen artifact, a declarative provider-manifest seam, and model-routing by stage economics (a 3–5× cost lever).
gtm-research is worth adopting as patterns, not as a repo — its free-first cost waterfall, shared web cache, and two-agent verify pass are excellent; its un-pooled DB layer would re-trigger our 2026-05-21 Railway incident.
Internal bug surfaced: the TS harness cost tracker writes costUsd: 0 on every call — TS-native runs report $0.00.

Source-verified · 3 recon agents · gtm-pipeline @ public · gtm-research @ 479f65c · gtm-orchestrator @ local