The pre-call brief is a real job that consumes a real amount of time: open the CRM, open the enrichment table, read the last three notes, check the open tasks. An agent with read access to those systems can assemble the page in the time it takes to open the tabs.
Three servers cover the common stack: Pipedrive for pipeline, Attio for relationship data, and Clay for enrichment.
The short answer
Automate reading and drafting the brief. Do not automate CRM writes: a wrong stage can change a forecast someone presents to a board, and a duplicate record is a data quality problem that compounds.
What each server holds
| Server | Holds | Brief contribution |
|---|---|---|
| Pipedrive | Deal, stage, amount, activity | Where the deal actually is |
| Attio | People, relationships, notes | Who knows whom, what was said |
| Clay | Enrichment columns | Firmographics, signals, fit |
The brief merges them in this order: the deal state first, the relationship history second, the enrichment last. Enrichment is context, not evidence.
The Pipedrive brief
Pipedrive is the pipeline source: stage, value, expected close, last activity, and open tasks. The useful rule is that the agent reports what the CRM says, not what the deal 'probably' is. If the last activity was three weeks ago, that is the fact, and it is usually the most useful one.
The Attio layer
Attio is where relationship data lives: who on the team knows the buyer, what was discussed in the last meeting note, which lists the account is on. An agent that can read lists can answer 'is this account on the enterprise list' without a human checking.
Because Attio is schema-driven, the output can be structured rather than prose — a brief with fields is easier to skim during a call than a paragraph.
The Clay layer
Clay is enrichment: firmographics and signals from providers. The important discipline is labelling: an enriched field is a lead, not a fact. 'Hiring for sales engineers' is a signal worth noting, not evidence that the team is expanding.
The one-page brief
A format that works: account name and segment; deal stage and amount with the last activity date; people and last conversation; three recent signals, each with its source; one open question for the call. That is a page someone reads in ninety seconds.
Notice the last item. A brief that ends with a question is a brief that does something; a brief that ends with a summary is a document.
The writes not to automate
Updating a stage, creating a deal, or appending an enrichment record are all writes to a system other people rely on. The failure modes are asymmetric: a wrong stage is visible in a forecast, and a duplicate account can take a quarter to clean up.
If a write is genuinely useful — adding a note after a call — make it a separate tool with an explicit name, and review the first twenty before trusting it.
Frequently asked questions
Can the agent draft outbound email? Yes, with the brief as input and no sending. Sending belongs to the person who owns the relationship.
What about data quality? Read errors are visible in a brief and corrected by the reader; write errors are invisible and spread. That asymmetry is why read-first is the sane default.
Which server first? The one holding your pipeline. See MCP servers and Clay.
Last checked: 14 November 2026.
Related: pipeline vs relationship data, payments read-only, and MCP servers.
