Warm intro software can find possible paths. It cannot know who trusts whom. Our system shows the evidence, sends weak paths to review, and requires a person to approve each ask.
The problem
Most warm intro tools start with the wrong question: who is connected to whom?
That is easy to answer and often useless. Two people can share a company, school, city, or investor without knowing each other. A database join is not a relationship.
The useful question is narrower: what evidence would make it reasonable to ask this person for an introduction?
We built a system to answer that question. It resolves identities, maps target accounts, finds possible connectors, and shows the evidence for each path. It produces a review queue, not a list of invented friendships.
We ran the system against a deterministic public fixture and released the code. The screenshots below come from that run.
The complete workflow. Editable source:
warm-intro-automation-workflow.excalidraw
.
1. Source and storage
Put the network in one database
Start with a LinkedIn connections export. The CSV is evidence from one point in time. It is not a customer database.
Normalize profile URLs, names, employers, and dates before you merge records. Keep each source ID and alias. Later data must map back to the same person.
Write one canonical record to the customer database. Store the source URL, observation date, current snapshot, and aliases. If two sources disagree, keep the conflict. Do not guess.
The database joins these sources:
- network connections
- CRM activity and account ownership
- event attendance and form submissions
- dated employment and education history
- public appearances and community context
- explicit relationship notes or confirmed introductions
Every score can now point to a source record. When a reviewer asks why a path exists, the system has an answer.
2. Target map
Decide which accounts matter first
The fixture starts with five accounts. It keeps three. It suppresses one existing customer and removes one non-B2B company.
Run those checks first. There is no reason to search for contacts, buy data, or draft messages for an account you cannot contact.
For each remaining account, build the buying committee. We search for GTM engineering, revenue systems, RevOps, BizOps, and GTM analytics. Each output keeps the target's current title.
Fresh output from the public fixture. The run ranked five accounts, reviewed four person-level paths, and sent zero messages.
3. Evidence
A clue is not proof
The system uses weak clues to find paths. It does not use them to make strong claims.
A company match may reveal a connector. It does not prove that two people worked together. To claim work overlap, the employer must match and the employment dates must overlap.
We score two edges separately. The first is owner to connector. The second is connector to target. A strong first edge cannot repair a weak second edge.
The evidence order is:
- confirmed direct introduction
- verified dated work overlap
- school, city, community, or public appearance
- role or industry proximity
- investor context
Investor overlap stays last. Ten weak clues do not become one strong fact. Repeated evidence adds citations, not points.
The evidence review artifact. Higher scores do not bypass the human review boundary.
Four paths from the working example
| Target | Connector | Evidence | Route |
|---|---|---|---|
| Nora Imani, Head of GTM Engineering | Avery Stone | Confirmed introduction record | Strong warm intro |
| Mina Sol, Director of Revenue Systems | Casey Morgan | Dated Atlas Works overlap | Strong warm intro |
| Tariq Fen, Director of BizOps | Riley Chen | Same company, non-overlapping dates | Review |
| Elliot Vale, Director of RevOps | Parker Quinn | Investor context only | No strong path |
The third path is the most useful one. Riley and Tariq worked at the same company, but not at the same time. The system keeps the clue and blocks the "former colleagues" claim.
The fourth path has only a shared investor. It goes to direct outreach. The software does not call it a warm path.
4. Review and activation
A person must approve the ask
Only strong paths enter the draft queue. A review path needs an operator flag and a row-level override. A row with no strong path never reaches the model.
Every draft starts as unapproved. The reviewer checks the target's role, the cited fact, both identities, the current relationship, suppression state, and the cost of the favor.
Activation uses a versioned ID. It contains the campaign, owner, path, channel, and message version. A material edit creates a new version and removes the old approval.
The outbox records send intent before dispatch. A successful or uncertain attempt cannot retry on its own. An uncertain provider response creates a reconciliation task.
Most of the engineering work went into this boundary, not the copy generator. The system makes a careful operator faster. It does not send from an uncertain relationship graph on its own.
5. Run it
Reproduce the public workflow
The code is in the public GTM Engineering Skills repository.
Run the deterministic fixture from the repository root:
python3 examples/office-hours/target-account-warm-intro-campaign/pipeline.py \
--input-dir examples/office-hours/target-account-warm-intro-campaign/sample_data \
--output-dir /tmp/warm-intro-campaign \
--config examples/office-hours/target-account-warm-intro-campaign/config.example.json \
--as-of 2026-08-01
The fixture writes nine review files. It makes zero provider calls. It approves and sends zero messages.
Use these three examples in order:
- Target-account campaign ranks accounts, resolves contacts, maps buying committees, and scores paths.
- Warm-intro scoring explains the evidence hierarchy and deterministic exports.
- Ask threads handles drafting, approval, rate limits, idempotency, and reconciliation.
Replace the fictional inputs with a reviewed export from your network and customer database. Keep the contracts for identity, dated evidence, routing, manual approval, and send history.
FAQ
Does a shared employer prove that two people know each other?
No. First require overlapping dates. Then ask the connector whether they know the target before you use the claim in a message.
Should investor overlap count as a warm path?
No. It can help find a path. It cannot prove a relationship.
Why write the LinkedIn export to a customer database?
The export is one snapshot. The customer database gives each person a stable identity. It can add new evidence without hiding its source or deleting a conflict.
Can I send directly from the workflow?
Yes, after explicit approval. Run a dry test first. Store each send intent, attempt, and provider event. If the provider result is uncertain, reconcile it before you retry.