The most important architectural decision in OutreachIQ is the deliberate separation of fast bulk AI from deep reasoning AI. These are not interchangeable.


Layer 1 — Groq (llama-3.3-70b-versatile) Inside n8n

Groq handles every task that requires speed and volume but not depth. Twenty-five prospects processed per week means twenty-five enrichment passes, ICP scoring calls, and preliminary bait finding attempts. At Claude Opus pricing this would be expensive and slow. At Groq pricing on llama-3.3-70b-versatile it is effectively zero cost.

Groq’s role: ICP scoring, enrichment summary generation, tech gap identification, preliminary UX flaw detection, founder name extraction from About page HTML, reply classification in W4, and diagnostic brief generation in W2.

Groq’s limitation: It cannot browse the web. It cannot verify what it reads. It makes confident errors — classifying a Norwegian agency as a US Healthcare company at 90/100 ICP score, naming a deceased founder as the outreach contact. Groq’s output is a hypothesis, not a conclusion.


Layer 2 — Claude Opus 4 in a Dedicated Project

Claude handles every task that requires genuine reasoning, multi-page web browsing, evidence-based analysis, and consulting-grade writing. One prospect. One session. Twenty minutes of browsing. Four findings with specific evidence. One structured JSON output.

Claude’s role: ICP validation, contact verification, website research, finding identification, severity classification, bait finding selection, service mapping, projected impact quantification, and the complete diagnostic JSON.

Claude’s strength: It catches what Groq misses. It flags the deceased founder. It identifies the Norwegian geography. It notices that the Contact page has no contact form — a finding specific enough that the firm’s own marketing team had not actioned it in sixty years of operation.


Why This Separation Matters

Using Claude for bulk enrichment would cost more, run slower, and waste the model’s reasoning depth on tasks that do not require it. Using Groq for the diagnostic would produce generic findings dressed up in confident language.

The two-layer architecture uses each model at what it is actually good at:

Task Model Reason
ICP scoring Groq Fast, cheap, deterministic enough for first-pass
Enrichment summaries Groq High volume, structured output, no web access needed
Tech gap identification Groq BuiltWith data is structured — Groq reads it cleanly
Reply classification Groq Binary categories, fast, no context needed
Contact verification Claude Requires web browsing to validate against live pages
Finding identification Claude Requires multi-page browsing and contextual reasoning
Diagnostic writing Claude Consulting-grade specificity requires genuine reasoning
ICP validation Claude Must check against live observable reality, not just data