From graph_entities to deal flow

Most “CRM add-ons” bolt a web form onto a database. Reconn2 starts from graph_entities — canonical rows keyed for dedupe — with claims that retain which automation or enrichment asserted each fact.

Where CRM rows come from

When ConstructConnect (or a future extractor) emits companies and contacts, they appear in CRM lists as soon as they exist in Postgres. Operators review Opportunities for new bids, then use Add to Deals board when they want to pursue one.

Enrichment sits beside CRM

Enrichment jobs (Apollo, Tavily, Bright Data) attach new claims and identifiers without overwriting the original portal payload. That matters when a LinkedIn scrape disagrees with a bid document — you can see both.

Pipeline

Opportunities graduate into deals on the Kanban board. Cards stay linked to underlying entities so AE and precon teams share one object graph instead of retyping company names from a CSV export.

Agents

Generate a project token, enable MCP, and let Cursor or Claude call list helpers against the same Postgres views the UI uses — useful for drafting outreach from structured context without copy-pasting sensitive portal HTML.

If you are onboarding a team, start with the in-app User Guide; it mirrors the recommended order: Automations → Opportunities → Enrichment → Deals → API tokens & MCP.