The call that starts this
A revenue lead opens a pipeline review and finds four opportunities with nothing in the activity timeline since the first discovery call. The reps are not idle. Ask one of them what happened on the Northwind renewal and you get three paragraphs: accurate, dated, with the procurement contact's objection quoted. It is in a ChatGPT thread. They pasted the call transcript in, asked for a summary, kept the summary, and moved on. Sales notes outside the CRM AI threads are the shape of shadow AI that revenue leaders meet first: not a leak, a bypass.
Nothing was stolen and nothing broke. But the forecast now rests on records months behind what the team knows. The knowledge lives in threads nobody else can read. The leak version, where customer data gets pasted into an assistant, is a different problem with a different fix.
Claude, ChatGPT and Cursor reach tools over MCP. MCP (Model Context Protocol) is the standard way an AI assistant calls tools in other apps. It matters here because it is the only route by which a chat thread writes back to Salesforce under rules you set.
Why do sales notes outside the CRM AI threads pile up?
Because the thread already holds the context and Salesforce does not. A rep who has just had the assistant summarize a call has the summary in front of them. Putting it into Salesforce means switching apps and finding the right opportunity. Then opening the right activity type, pasting, and picking fields the assistant already knows the answers to.
That is five steps against zero. Reps are not avoiding the CRM out of defiance. They take the cheaper path, which is what people do under quota. Support teams reach for the same shortcut, and the reasons support agents paste tickets into an assistant are close to identical.
There is a second reason. Some reps keep notes out of the CRM on purpose, because a note in Salesforce is visible to their manager and a note in a thread is not. If that is what is happening on your team, no tooling fixes it. The fix is a conversation about what gets logged and why.
Diagnose from one rep's actual workflow
Start with a single rep and one deal, and walk the day with them. Do not start with a policy.
Ask where the raw material comes from: a call recording, a meeting transcript, an email thread, their own typed notes. Ask what they do with it in the assistant: summarize, draft a follow-up, pull out next steps. Ask what, of that output, ends up in Salesforce, and which part of putting it there they skip.
The answer is usually specific. Somewhere the activity form asks for a subject line every time. Somewhere else the rep cannot tell which opportunity the note belongs to and would rather not guess. Elsewhere the rep logs the call but never the next step, because the next-step field sits on a different page.
Write down the exact step where the rep stops. That step is the whole diagnosis, and it decides which of the two forks below you take.
Fork one: fix the CRM, not the assistant
If the rep stops because the Salesforce form is slow, the honest answer is that you do not need an MCP endpoint. You need a shorter form.
This is the fork most teams should take first, and it is cheap. Cut required fields on the activity object. Put the next-step field on the same page as the note. Give reps a mobile path to log a call in the parking lot. If a rep's objection is "it takes too long", test whether making it take less time solves it. Do that before you add a second vendor to the stack.
Fixing the form also has a property the other fork does not: it works whether or not anyone is using an assistant. A team that logs properly in Salesforce today will still log properly when it switches assistants next year.
Take this fork when the friction is form design, or when few reps use an assistant at all. Take it too when your Salesforce admin has capacity this quarter. Elaichi has a post on when an MCP gateway is premature that makes the same argument more generally.
Fork two: let the assistant write back through a governed endpoint
Take this fork when the rep's bottleneck is the app switch itself, not the form. The context is in the thread and the thread is where the rep is working. Moving the write to where the work happens is the only thing that removes the step.
Elaichi serves MCP at one endpoint, https://api.elaichi.ai/mcp, the same address for every organization. Claude, ChatGPT and Cursor all sign into it with OAuth. Which organization, which person and which tools a client reaches comes from the OAuth grant behind its token, not from the URL. There is no per-rep address to hand out and no per-team address to maintain.
Salesforce is a connector in Elaichi's catalog. Each rep connects their own Salesforce account with their own sign-in. Every call Elaichi runs acts as the person who approved the grant. Their permissions are looked up on each request rather than stored in the token. A rep's assistant writes to Salesforce as that rep, with that rep's own Salesforce access. Salesforce's own sharing rules and record ownership still decide what they can touch. A rep who cannot edit an account in Salesforce cannot edit it through their assistant either.
The client adds a check of its own. Before a supported write action runs, ChatGPT may show an approval card. Whether it does depends on the app's permission setting and the action's context (OpenAI's app permissions article, checked October 2026). Claude's connector tool permissions take one of three settings: Always allow, Needs approval or Blocked (Anthropic's connectors article, checked October 2026). Each applies to a whole connector, a category of its tools or a single tool. Cursor asks for approval before using MCP tools by default (Cursor's MCP docs, checked October 2026).
Those client controls act on Elaichi's tool list, where connected tools run through one tool named execute_tool rather than appearing one by one. A client setting cannot single out one connected app that way. Per-app limits belong in Elaichi, as restrictions.
That is the governed part. The useful part is that the note is one sentence away: the rep asks the assistant to log what it just summarized, and it lands on the record.
Freeze the owner field so the note lands correctly
The failure mode of an assistant writing to a CRM is not malice. It is the model picking the wrong value for a field it has no business choosing.
Elaichi has frozen parameters for this. A toolbox entry can carry argument values written into the entry that a caller cannot override when the call runs through that entry. Frozen keys are removed from the tool's advertised input schema, from its properties and its required list. The AI client cannot set them. At execution, frozen values are merged over the caller's arguments, so passing a frozen key as an argument cannot change it. Argument precedence for a toolbox entry runs: entry defaults, then the caller's arguments, then frozen parameters. Frozen values win.
For a sales write-back, freeze the fields that identify who owns the work: the owner id, the record type, the activity source. Leave the note body and the subject to the rep.
Two honest limits. First, the model can see what is frozen, and often the values. Elaichi prefixes the tool's advertised description with a note such as "(frozen: source=assistant)". An MCP client that calls the toolbox read operation reads every frozen value in full. Frozen means the AI cannot change it, not that the AI cannot see it.
Second, a freeze holds only on calls that run through the entry that carries it. A rep who can use the Salesforce connection themselves also has the unfrozen tool in their All tools toolbox. To hold a team to the frozen path, the connection's owner keeps the connection unshared. They pin it into a toolbox entry with the frozen value, then share the toolbox rather than the connection, at use. Elaichi's post on locking tool arguments works through that distinction in detail.
Decide what the write-back is allowed to touch
A rep logging notes needs to create activity records. It does not need to delete opportunities or change close dates in bulk. Restrictions are where you draw that line.
In Elaichi, restriction targets are role or user only; the organization default is the absence of a rule, which means allow everything. To hold a sales team to a set of Salesforce tools, write the rule on their role. A rule has a mode, allow or block, and names whole connectors or single tools.
Two traps to know before you write one. An allow rule turns on the allowlist for its layer just by existing, whatever it names. So an allow rule that names nothing blocks every connector and tool for its target. A layer with only block rules has no allowlist, so anything it does not name passes. Blocking a few Salesforce write tools leaves every write tool you did not name reachable. If you want a rep role held to a short list of Salesforce tools, write allow rules naming those tools. Add whole-connector allow rules for every other app that role uses.
When a restriction changes, it reaches every surface within about two minutes. Grant revocation, member removal and suspension are different: those stop a client on its next call.
What the pipeline review looks like afterwards
Every connected-tool call that reaches execution is written to the audit log with the person, the connector, the connection and the MCP client. A note logged from a thread carries the rep's name, the Salesforce connection it ran on, and which client made the call. The console's summary reads like a sentence: using ChatGPT, this rep updated this record through this connection.
That is the second thing the revenue lead wanted and did not say out loud. Not just that the notes exist, but that they can be attributed when someone asks six months later who logged what.
Two things it does not give you. Elaichi keeps 90 days of audit history. For a longer history, forwarding to your own log service comes with the Black plan, which is launching soon. And the audit log records the tool call, not the content of the note. The record of what was written sits in Salesforce, where it belongs.
Where to go from here
If the diagnosis landed on the CRM form, stop here and go fix the form. If it landed on the app switch, the next step is per-rep Salesforce access from a chat client. Elaichi covers that in giving each rep their own Salesforce access in ChatGPT. For the wider question of what a rep may reach in which app, start with MCP governance. For Salesforce itself, see the connector catalog and the sales use cases.
