Keep the list you send to separate from the list you sold to

The Data Bank page is a pool, not a second CRM. You import a CSV, or a source pushes rows in, and they sit there as raw records with whatever the source gave you. You query the pool, decide what is worth working, and publish those rows into contacts and companies. Publishing fills gaps rather than clobbering: if a record already exists with a phone number, an imported row without one does not erase it. That single rule is why a pool is worth having at all.

Sources today are a CSV import, the Apollo provider for import and enrichment, a generic webhook that any scraper or vendor can post to, and an S3 CSV drop for bulk loads. Each source is registered, so a published row keeps its provenance and you can tell six months later where an address came from. Import is a straight CSV mapping today; the guided import wizard, duplicate detection and merge are on the roadmap.

On top of the pool sit ICPs and segments. An ICP is the definition of a good-fit account: the filters that describe who you sell to. A segment is a saved query that returns the rows matching a filter set right now. When you freeze a segment into an audience for a cadence or campaign, the suppression list runs against it and the suppressed rows drop out. Unsubscribes, hard bounces and anything you add by hand all live on that one list, and it is global across every cadence rather than per-campaign.

The MCP twins cover the whole pool. data_bank_query reads it, data_bank_publish promotes rows into the CRM, icp_create and icp_list manage ICPs, segment_create and segment_list manage segments, and suppression_add, suppression_list and suppression_remove work the suppression list. contact_search, contact_create and contact_update handle published records. Sourcing runs are driven with sourcing_start and sourcing_list.