Dmitriy Kononov.
Let’s talkContact

News and analysis

AI for CRM: who owns the company context?

Merge, HubSpot and OpenAI with Atlassian discuss different context layers. Check sources, freshness and permissions before a CRM action.

A salesperson asks AI to prepare a customer reply. The CRM holds the latest meeting, a document contains an old offer, and the team’s decision lives in a task. A well-written prompt does not establish which facts are current. Three October publications help treat context as a maintained part of the workflow rather than a collection of chat attachments.

Give information an owner and a freshness boundary

On 12 October, Merge described context engineering through instructions, company knowledge, tools, memory and task state. It contrasts individual setup with shared organizational context and emphasizes access permissions. This describes an approach and a vendor offering, not a system already connected to your company.

For CRM work, begin with one question: what information does the employee need for the next action? A reply may depend on the last agreed terms and an open support request. The agent does not necessarily need the whole archive. It does need an authoritative source for each fact and a way to recognize changes.

Data connections and workflows are different

On 7 October, HubSpot compared sales plugins and CRM connectors by tasks and sources. Meeting preparation, pipeline analysis and record updates need different capabilities. The vendor review does not establish compatibility between every tool and every CRM.

On 6 October, OpenAI and Atlassian announced an expanded partnership, discussing Rovo and Teamwork Graph as connections between people, projects, documents and decisions. Appropriate permissions govern access to context; deeper Jira agent workflows remain under exploration. Treat those plans separately from completed integrations.

A central hub connects to customer cards, documents, an audio waveform and a calendar through separate ports.
Conceptual AI illustration of context for CRM work.

Verify an answer separately from a write permission

The comparison suggests a design boundary: assess context and action independently. A useful summary may require only read access. Updating a deal needs a separate permission decision and verification that the operation is supported.

For a pilot, create a fictional customer with a document, CRM record and task. Specify the authoritative source when information conflicts. Change a term in the source system and repeat the request: the answer should reflect current information or expose its limitation. Repeat the exercise as an employee with narrower access.

Ask for sources supporting key conclusions and leave unconfirmed values unresolved. Before enabling CRM writes, agree the output format, action permission and correction path. Discussing three products together does not imply a ready-made joint integration.

Our AI data processing guide explains this boundary. The archived GoHighLevel design describes CRM workflows without claiming their current automation through these tools. For your CRM integration, discuss sources and allowed actions before adding another connector.

Sources