AI acquisition systems · Amy Wilkinson

The AI acquisition engine that learns before it sends.

Most AI sales tools start by writing and sending. This one starts by proving who matters, why now and the best evidenced way in—then keeps every external action under human control.

The acquisition engine: signals become identities, paths, cases, approved actions, provider receipts and learning.

One system, not six disconnected tools.

01 · FindSource real timingRaises, launches, expansion, conversations and owned operational data.
02 · ResolveBuild exact identityEmail, LinkedIn, CRM and community receipts without unsafe fuzzy merges.
03 · RouteProve the pathDirect owners, trusted connectors and lateral links, ranked by provenance and recency.
04 · QualifyOpen the caseFit, budget, timing, appetite and the real route-to-pitch gap.
05 · ActReview one next moveApprove, edit or drop. Client outreach is always human-sent.
06 · LearnOwn what followsProvider receipt, exact-thread reply watch, follow-up and CRM progression.

The Alice → Bob test.

Cross-platform route intelligence
Owner → Alice → Bob

Bob has just raised. Mailchimp proves Alice is already known. Gmail proves a relationship owner and Alice have exchanged messages. LinkedIn proves Alice is directly connected to Bob. Three systems become one possible route, with every claim and date attached.

The engine does not merge two Alices because their names look similar, call a newsletter signup a friendship, or call the route warm until its named owner confirms the depth. Every new candidate triggers the scan. Every new message, network import, CRM change or piece of feedback queues it again.

One identity, with receipts—not a pile of contacts.

The graph keeps exact identifiers and identity evidence separate. Email addresses, platform handles, profile URLs and provider IDs can resolve to one person when the evidence is strong. A name alone cannot. Ambiguous observations stay pending instead of being silently merged, because a false intro path is more expensive than a missing one.

Each connector has an honest state: live, snapshot, blocked or errored. An unread source never becomes “zero contacts”. That distinction is operationally important. A static LinkedIn export may still be useful historical evidence, while live Gmail can add recency and conversation depth. The engine can use both without claiming they are equally current.

The Daily Five is calibration, not the final product.

During learning week, the system surfaces five relationships a day with the same four questions attached: why now, why it fits, the best evidenced route and what still needs qualifying. A Keep or Remove in Slack and the same decision in the dashboard write to one canonical record. Feedback changes tomorrow’s ordering; it does not disappear into a presentation.

At the end of calibration, the system does not wake up because a date arrived. A readiness check confirms the reviewed sample, exact sender mailboxes, approved sender voices, route-to-pitch rules and provider connection. A named operator then records the cutover. From its effective date, the five-a-day ritual stops and the live pipeline becomes the operating surface: a small focus cohort plus the replies, route checks, follow-ups, reconnects, meetings, proposals and commitments already moving around it.

A target date is never permission.
The switch is durable, attributable and blocked by missing product gates. It can open research, drafting and one-click handoff. It cannot change a human-send-only tenant into an autonomous sender.

Keep is the start, not the send button.

A Keep verdict opens an accountable relationship case. The graph ranks routes. The named owner confirms, corrects or rejects the relationship. The engine then checks the commercial gap, current moment and route-to-pitch rules.

Provider-confirmed sent messages can become candidate voice examples for the exact sender, but reading a mailbox is not permission to impersonate them. The profile needs a durable approval before a drafter can use it.

The dashboard and the drafter use the same gate.
There is no state where the interface claims a sender is ready while generation quietly falls back to a generic company voice.

The CRM starts after reality happens.

A prospect does not become “contacted” because a draft exists or somebody clicked approve. The provider must return the message id, thread id, contact and timestamp. That receipt advances the sequence, opens the exact-thread reply watch and schedules the next action.

A matching inbound reply stops silence follow-ups immediately. It opens the next human decision and feeds the outcome back into targeting, routes and message strategy.

The route-to-pitch changes the message.

A route is not merely the name of somebody who could introduce you. It changes who should speak, what they can credibly reference and which next step is proportionate. A close relationship can begin with shared context. A weak route may justify a context check before any pitch. A genuinely cold but well-timed target needs a different plan entirely.

The engine therefore carries a route brief and a qualification gap beside every draft. It knows whether the relationship is direct or lateral, who owns it, how recent the evidence is and which fact still needs confirmation. It can recommend an introduction, a reconnect, a useful observation, a soft pitch or no action. “No evidenced path” is a valid result, not an invitation to invent warmth.

Voice is a permissioned data product.

Generic brand voice is not a substitute for a person. The system assembles candidate examples from provider-confirmed sent messages for the exact sender, strips quoted history and signatures, and presents the examples for approval. Only approved examples can ground that sender’s draft. If the named route owner has no approved voice, the case stops at a visible voice action.

This prevents a common failure mode: a dashboard saying “ready” while the generation layer quietly falls back to somebody else’s voice. The same gate is read by the interface and the drafter. Edit re-runs the voice process but stays unapproved. Drop is terminal for that exact artifact. Approve acts on the record the person actually reviewed.

The refusals are the product.

do-not-contact wallno unsafe identity mergeno invented warmthexact sender voicehuman approvalprovider receiptreply stops follow-up

A figure that cannot be traced holds. An attributed quotation nobody said holds. A new source that cannot be read shows as blocked, never as empty. A live conversation is never evicted because a stranger scored four points higher.

Why this compounds.

The database and the human workspace are two synchronised representations of one operating system. Feedback in Slack and decisions in the dashboard converge on the same records. A real reply changes the ranking. A corrected route changes future pathway scans. A successful angle changes the next plan.

The point is not what the machinery can theoretically do. The holy-shit moment is how a team uses it: open one queue, understand why now, see the best evidenced route and take the next action without losing the relationship two weeks later.

The operating loop in practice.

Monday may contain a route confirmation, two approved first touches and one reply that needs an answer. Tuesday may contain no new outreach at all, because the valuable work is moving a warm conversation forward. The Today queue shows at most three decisions now and one next deadline; the full pipeline holds everything else with dates, owners, evidence and stage locks.

As work progresses, the candidate workspace accumulates the useful record: trigger history, fit reasoning, paths considered, relationship context, messages, provider receipts, reply state, next action, meeting notes, proposal, SOW and delivery handoff. The database remains machine-readable while the client workspace remains pleasant to navigate. They are synchronised views of one state, so handover does not mean exporting a dashboard-shaped screenshot and losing the operating memory behind it.

Build once. Deploy as a real operating system.

FounderGrowthOS combines repeatable acquisition, content, SEO, ads and relationship engines with the strategy and data of the business using them.

Talk to Amy →