Stop Connecting Salesforce Directly to Claude. Build a Context Layer First.
By Pouyan Salehi, CEO and Co-founder at Scratchpad (building Clearskies) ·
Almost every revenue team now has Claude or ChatGPT. A live poll during this session found 16 of 18 revenue teams have reps using it daily. So why do the AI briefs still hallucinate, and why does the pipeline analysis feel like guesswork? Pouyan Salehi, who has spent over a decade building sales tech across PersistIQ and Scratchpad, argues the bottleneck is no longer the model. It is context. This recap covers his case for "context infrastructure," why connecting data sources straight into an LLM breaks at scale, and how his team is building a customer context graph that any model can plug into.
What is the "context problem" in revenue AI?
Salehi's thesis is that the intelligence of the model is no longer the constraint. Models have become extremely capable, roughly "PhD level" in his words. But a brilliant new hire still produces bad work without the right context: they need to know the project, the teammates, the business strategy, and the process. An LLM is no different.
The way most teams give an LLM that context today is connectors. Salesforce has an MCP, Gong has one, and everyone is racing to publish one so you can wire the tool into Claude. For narrow tasks like "summarize my last call," connectors work fine. The wall appears when the question gets bigger.
When you ask an LLM to analyze every deal in the quarter, it does not actually read every deal. It samples. The answer sounds confident, but it was built on a fraction of the data, and you cannot see the error because the system never flags it. As Salehi put it, you are using a probabilistic system to get a deterministic answer.
Why do connectors break at scale?
Salehi laid out four failure modes that show up once a team tries to do real work through raw connectors.
| Problem | What happens |
|---|---|
| Compound error | The model samples instead of reading everything. Small errors stack across steps. Illustrated as 95% right across 5 steps equals 77% reliability. |
| Cost | Every question rebuilds context from scratch, re-spending tokens on work that was already done. He expects a hard cost reckoning in the next 6 to 12 months. |
| Sensitive data | A raw connector has no idea it should skip board-level emails, termination discussions, or investor updates. It syncs everything. |
| Lock-in | Build all your context into one model's harness and you are locked into that ecosystem. If it goes down or a better model appears, you are stuck. |
The lock-in point drew real agreement in the room. One practitioner had a webinar go down that week because a single AI provider was unavailable, with no fallback. The lesson folded into the discussion: portability is not a nice-to-have. If your context lives inside one model's wiring, an outage or a model shift takes your workflows with it.
What is context infrastructure, and how does it work?
Instead of pointing a model at raw sources and asking it to reconstruct the customer story every time, Salehi's approach builds that story once, in advance, and keeps it current. He calls the result a context layer, or an "AI system of record."
Before any LLM ever touches the data, the system does the heavy lifting:
- Unifies data across every source into one place
- Resolves identities so "Acme Inc" in Salesforce, "Acme" in Slack, and "ACME Corporation" in an email thread all map to one account, and the same person across a CRM record, a call, and an email resolves to one identity
- Maps activities and relationships between calls, emails, calendar events, and tickets
- Builds timelines so every interaction sits in order
The payoff is that you stop telling the model which source to check. You do not say "look in Gong, then Salesforce, then Slack." You say "look at this account," and the pre-mapped graph traverses every related contact, support ticket, email, and call on its own. When a rep, a manager, and a VP all ask about the same account, they point at the same resolved context and get consistent answers.
What database powers it?
Salehi confirmed the context graph runs primarily on a graph database, Neo4j, which is well suited to navigating relationships. It is not graph-only: the team uses Postgres where a graph model is the wrong fit. Data warehouses like Snowflake and Databricks are not the store here, because they are built for analytics rather than real-time retrieval. Those are on the roadmap as connectors, both to ingest data and eventually to push resolved context back out so a team can own the infrastructure itself.
What can you actually build on top of it?
Salehi demoed the product, Clearskies, with dummy data. The pattern across every use case is the same: describe what you want in natural language, the system turns it into logic you can refine, you test it against a real call before shipping, then push it live. Here are the three use cases he walked through.
| Use case | What it does | Where it runs |
|---|---|---|
| AI CRM updates | After a call, decides whether anything is worth logging, then updates fields like Next Step or MEDDPICC. You can name exact fields deterministically, or let the model choose. Build in roughly 15 minutes, test in 5 to 10. | Workflow (fires automatically) |
| Pre-call brief | 10 to 60 minutes before a meeting, pulls prior calls, emails, CRM entries from other people, support tickets, and calendar events into one brief and sends it to Slack. | Workflow to Slack |
| QBR / deep research | Generates a QBR or win-loss analysis, pulling customer context from the graph and also searching the web, 10-Ks, or public sources as the task needs. | Claude (via a skill) |
That third case answers a question that came up about control: do reps stay inside the workflow, or can they go broader? The answer is both. A locked workflow handles the repeatable job deterministically, and a skill in Claude lets someone go wider, combining the context graph with web search and other tooling. The context layer feeds all of it.
How do you govern what goes into the graph?
A natural worry is that pulling everything in creates noise and risk. Salehi's answer is a control layer that sits between the data source and the context graph, letting an admin decide what is even allowed in.
Much of this is deterministic. Domain exclusion and inclusion rules mean that if you exclude a domain, data touching that domain never enters the graph, across any source. You probably do not want board emails or investor updates sitting in a customer QBR. Some rules are deterministic in intent but probabilistic in execution, like "exclude any email with a specific phrase in the subject line," where the system has to read and match. The point is that you set the rules up front, rather than hoping the LLM behaves at query time.
How do you handle conflicting information and different takes?
This was one of the sharper threads in the discussion, since a rep, an account manager, and a CEO will read the same call three different ways. Salehi split the problem in two.
First, the context. Whatever the interpretation, everyone has to be working from the same call. The danger with letting an LLM find its own context is that it may not even retrieve the right call, and the confident-wrong problem compounds when you ask across many deals. Owning your context fixes the retrieval half.
Second, the model. Even with the context fixed, different models give different takes, and that is expected. His view is that teams will use more models over time, not fewer, matching the right model to each use case and locking that choice into a deterministic workflow the whole team shares. He was candid that his own usage had recently shifted more toward OpenAI's Codex for some work, while still using Claude, which is exactly why a portable context layer that connects to any model matters.
Is this a "build vs buy" decision?
Salehi was direct that very few companies should build this in-house. The ones who do tend to have a dedicated engineering team pointed at go-to-market, which is rare. More often it is RevOps, at the direction of a CRO, fighting for engineering resources, building a V1, and then never getting the resources to maintain it as APIs change and the sales process evolves. His pitch is that buying it gets you running in about 30 minutes at a fraction of the build-and-maintain cost, though he was honest that the harder challenge right now is simply that most teams do not yet realize they have hit the context wall.
He was also clear that connectors are not the enemy. It is a coexistence story. Connectors are how you take action: draft an email, write back to the CRM, create a draft in your inbox. Context infrastructure is how you read the full picture. You need to know which is which.
Key Takeaways for GTM Teams
- The model is not your bottleneck. Context is. Access to Claude or ChatGPT is table stakes now. The differentiator is whether the model can see the full, resolved customer picture.
- Raw connectors sample; they do not read everything. For big questions like win-loss or pipeline analysis, that produces confident, invisible errors. Build context before the model, not during the query.
- Resolve context once, reuse it everywhere. Entity resolution, activity mapping, and timelines done up front cut token cost and keep answers consistent across everyone who asks.
- Keep context portable. Do not wire your entire context into one model's harness. Outages happen and better models appear. A model-agnostic layer protects you.
- Govern the intake, deterministically. Use exclusion and inclusion rules to keep sensitive data out of the graph rather than trusting the LLM to be careful at runtime.
- Match the model to the use case, then lock it in. The best teams pick the right model per job and ship it as a deterministic workflow, reserving experimentation for the edges.
- Connectors and context coexist. Context reads the full picture; connectors take action. Use each where it shines.
Want to Attend the Next Session?
The GTM Clawllective is a community of go-to-market leaders sharing exactly how they use AI in their day-to-day work, one practical build at a time. Sessions are not recorded, so these recaps are the written record. The next session kicks off a new series on deal execution and forecasting, with a speaker from Gong. If you want to be in the room, join the community.
About the Speaker
Pouyan Salehi is the CEO and co-founder of Scratchpad, and has spent over a decade building software for B2B sales teams. He previously co-founded PersistIQ, an outbound sales tool that went through Y Combinator, before starting Scratchpad, the workspace for sellers that made Salesforce easier to work with and earned strong bottoms-up adoption among reps.
His team is now building Clearskies, a customer context graph that unifies CRM, calls, email, calendar, and Slack into a single context layer for revenue AI, connected to Claude, ChatGPT, or any model over MCP.
- LinkedIn: pouyansalehi
- Clearskies: clearskies.cc