Juniper Ventures · internal

CRM review — what exists, and where the sourcing engine fits.

Reviewed the live Juniper CRM: Airtable base appbL6ewYvsnzG67e driven by the crm-updater agent (repo Juniper-Ventures/agents). Bottom line: it's an excellent backward-looking relationship tracker — and it is not a sourcing engine. That's the gap P01 fills, and they should hand off cleanly at "first contact."

Update — Aug 14, live check against the base: the base ALREADY has a rich, populated Sourcing table (26 fields) — Name, Type (pre-founder→raised), Thesis Fit (Safeguarding / Auditing / Governing / Verifying = the AIAT taxonomy), Score + Score Reasoning, Status (New→Promoted to Deal), Source Channels (incl. arXiv/Scholar), Warm Path, Draft Email, Outreach log — plus a Watchlist table (14f) and Sourcing Ops, Venture Partners, Co-Investors, Submissions, and Ref: LP-Prospects (Pitchbook). So the "build the schema" task was already done and the pipeline is actively curated. The arXiv sourcing engine now writes into the live Sourcing table (deduped, tagged) — proven with one test record. Section 4's "recommended table" below is retained only as a field-mapping reference; treat the live Sourcing table as the target.

1 · What exists today

A headless, scheduled system — not just tables:

Airtable base appbL6ewYvsnzG67e — five tables (below), a shared base every teammate writes to.
crm-updater agent — runs 00:10 daily on the Mac mini: pulls the last 24h from Granola, Gmail/Superhuman, Beeper, Google Calendar, reconciles against Airtable, writes confident records, and Telegrams one batched question for anything ambiguous (@juniper_crm_bot). A daily Sonnet sync; an always-on listener resumes on Opus for deal-stage judgment.
Multi-operator — Nick, Griff, and you each run your own instance against the same base; every interaction is stamped Logged By so the same meeting logged by two people isn't a duplicate. You'd add an operator.json with your name/email/timezone.
ops-auditor agent — a second back-office agent in the same repo.

2 · The schema (5 tables)

Table	Key fields	Role
People	Name, Type (multi: Founder/LP/Investor/Community/Philanthropy/Grantee/Donor/Funder), Last Contacted, Email, Phone, Company→Orgs, Interactions, Deals, Locations→Locations	Every human in the network
Organizations	Name, Website, Type (multi: Portco/LP Firm/VC Firm/Angel Co/Community/Philanthropy…), Contacts, Deals, Locations	Every company/institution
Interactions	Name `{Type} — {Contact} — {date}`, Type (Meeting/Email/Call/Message/Note), Date, Summary, Granola Link, Contact→People, Logged By	Every touchpoint (the activity log)
Deals	Name, Stage, Type (LP Commitment/Portfolio Investment/Angel/Grant/Philanthropic Commitment), Check, Next Step, NS Date, Close Date, Vehicle (Fund I/II/SPV/Angel/Foundation), Company, Contacts	The pipeline (invest + LP + Foundation)
Locations	Location (`City, ST`), People, Companies	Deduped geography

3 · What it does well

Zero-effort hygiene — it captures interactions from your actual comms automatically; you never hand-log a meeting.
Strong classification — the LP vs Founder vs Investor vs Philanthropy distinction is enforced on every record, and it asks rather than guesses Type.
Real dedup + multi-operator attribution — safe for the whole team on one base.
A genuine deal pipeline with stages, check sizes, and Foundation deals modeled alongside fund deals.

4 · The gap = the sourcing engine's job

The existing CRM is backward-looking: it records people you already talk to. The sourcing engine (P01) is forward-looking: a watchlist of founders you should reach — programmatically sourced from talent programs, arXiv, "fire towns" — before any comms exist. They don't overlap; they hand off.

The clean handoff: the sourcing engine populates a Watchlist of prospects with a status funnel. The moment a prospect enters real comms (a reply, a meeting), the crm-updater already picks them up as an Interaction and, if it's a pitch, a Deal. So the sourcing engine owns pre-contact; the crm-updater owns post-contact. The boundary is "first touch."

Recommended: a Watchlist table (spec for the P01 schema task)

Add one table to the same base (keeps it unified, reuses People/Orgs links):

Field	Type	Purpose
Name	text / link→People	the prospect (link if already a Person)
Source	single-select	MATS / ARENA / Apart / arXiv / LessWrong / referral / other
Program / cohort	text	e.g. "MATS 8.0", "ARENA 5"
Signal	long text	why they're worth sourcing (the paper, the demo, the exit)
Warm path	text / link→People	who can intro (the network edge)
Status	single-select	sourced → researched → outreach → meeting → passed/deal
Owner	text	who's driving it (operator)
Links	url(s)	Scholar / GitHub / X / site

The engine writes rows into sourced; you work them right; when Status hits meeting, the crm-updater's Interaction/Deal machinery takes over. The "MVP" milestone (write a check into a machine-sourced deal) is literally one row completing that funnel.

5 · One access note

I can read the CRM code (gh access as esbenkc; repo cloned locally). To let me query/build against the live Airtable base directly — count deals, prototype the Watchlist table, validate the schema — put an Airtable PAT in ~/.zshrc as AIRTABLE_PAT (the Aug-10 to-do). Until then I'm working from the committed schema in agents/crm-updater/CLAUDE.md, which is authoritative.