Intent Solutions · Product Brief
Outbound prospecting that runs inside Claude Code. It researches target companies, finds and verifies contacts, and drafts personalized outreach, using your own data-provider accounts and your own model key. Every saved record passes a typed validation gate, and every campaign records what it cost.
Where it runs
On your machine, as a Claude Code plugin or a standalone command line. Run records are written to a local file you own and can audit.1
Whose accounts
Yours. Data comes from nine pluggable connectors under your own provider keys; the model runs on your own key. Claude is the default and OpenAI's gpt-4o passed the evaluation gate on 2026-08-20; further providers are admitted the same way.2
What gets stored
Validated records only. The run store accepts a record type that only the validator can produce, so unreviewed model output is rejected by the compiler and by CI, before any human sees it.3
Grounded in the repository, not drawn from memory: each box below names the file that defines it. The engine calls data connectors in a fixed order written in code, and the model is consulted at exactly two points per contact: scoring and drafting.
Also available as a standalone diagram. A standalone command line (cli.ts) drives the same engine and is omitted above for clarity. Compliance runs inside the engine before drafting: a pack-supplied gate checks do-not-call lists, TCPA quiet hours, and service area, and records blocked contacts on the run instead of drafting them (pipeline_core/compliance, pipeline_core/packs).
One system, four honest answers.
CEO
A working outbound motion without SDR headcount. The operator states an ideal customer profile and target domains; the system returns researched companies, verified contacts, and drafted messages, checkpointing with the operator between phases. Output is a saved, auditable campaign record.
CTO
Determinism where it matters. Connectors run in an order written in code; the model is consulted at two seams only. The storage invariant is enforced by the type system and re-checked in CI on every push, alongside typecheck, tests, and an offline evaluation gate.4
CISO
Keys and data stay under your control. Provider keys are read from your environment and sent only to each provider's own API. Run records live in a local file. A compliance gate screens do-not-call lists and TCPA quiet hours before any message is drafted, and it fails closed.5
CFO
A metered, usage-based cost structure with no new data-platform subscription: you pay providers directly on accounts you already govern, and each campaign records its own model spend. Figures and the arithmetic are in the one-pager below.
Ninety-second read. Every rate is cited to the repository or to the project's provider survey; the one assumed input is labeled as such.
prepared 2026-08-19 · sources at page end
| Cost line | How it is billed | Published rate |
|---|---|---|
| Data: research and enrichment | Directly to each provider, on your own account. Four of the nine shipped connectors have free tiers; unset connectors are simply skipped. | Apollo 50 credits/mo, Hunter 50 searches/mo, People Data Labs 100/mo, Exa 1,000/mo at $02 |
| Model: scoring and drafting | Two model calls per contact, metered per campaign by the built-in cost meter. Its source describes itself as "a meter, not an invoice"; rates are approximate and overridable. | Sonnet class: $3 per 1M input tokens, $15 per 1M output tokens, per the meter's table6 |
| Infrastructure | Runs on the operator's machine. Run records are a local file. There is no hosted service to procure, operate, or decommission. | $01 |
Labeled assumption: one example month
Assume 50 prospects, 2 model calls each, roughly 2,000 input and 500 output tokens per call. Model spend at the meter's Sonnet-class rates: 100 calls x ($0.006 + $0.0075) = about $1.35. At that volume the free data tiers above cover the data lines, so the variable cost of the month is the model spend. Volumes, token counts, and provider rates are assumptions and market prices; confirm current rates with each provider before budgeting.
What the CFO controls: every key can be revoked at its provider at any time, spend arrives as line items on provider accounts you already govern, and each campaign record carries its own token and dollar totals. Software licensing for Intent Outreach itself is a conversation with Intent Solutions; the figures above are the running costs.
These properties are checked on every push by the repository's workflows. If one breaks, the build fails.
Storage accepts validated records only
The run store's save path requires the validated record type, minted only by validator.ts. Checked by typecheck and a structural grep in policy.yml.
Store stays independent of the model layer
The storage module may not import the provider layer. A dedicated CI step fails the build if that separation breaks.
Lean dependency posture
CI rejects heavyweight agent frameworks in the core; the model seam is the Vercel AI SDK, and the core stays framework-free.
Build, tests, and evaluation gate
ci.yml runs typecheck, the test suite, a deterministic offline evaluation pass, the build, and verifies the committed bundle matches source.
pipeline_core/store.ts, JSONL at ~/.intent-outreach/runs.jsonl; README, "Two ways to run it".pipeline_core/connectors/ (nine adapters) and the project's provider landscape survey, 000-docs/018-DR-LAND (June 2026). Provider pricing changes; confirm current rates with each provider.pipeline_core/validator.ts mints the validated type; pipeline_core/store.ts requires it; enforced by npm run typecheck in CI..github/workflows/policy.yml (invariant checks) and .github/workflows/ci.yml (typecheck, tests, offline evals, build, bundle freshness).pipeline_core/compliance/index.ts, do-not-call scrub, TCPA quiet hours, service area; pure, clock-injected, fail-closed; wired ahead of drafting in pipeline_core/pipeline.ts.pipeline_core/cost.ts, per-model pricing table and per-campaign token and USD totals.