Shifting from platform-native AI to horizontal AI

AI has been moving into the platforms where work happens. HubSpot has Breeze. Salesforce has Agentforce. Microsoft has Copilot. CRM, marketing automation, service, data, and productivity platforms are all adding agents, assistants, and copilots.

That is useful. But it can also create a strategic trap when the question becomes: Which platform has the best AI features? The better question is: Does this AI have the right customer context for the decision it is about to recommend or execute?That context does not need to mean everything the company knows about the customer. In fact, in a serious enterprise environment, it usually should not.

The better principle is this:

AI needs the minimum sufficient, authoritative, and permitted context for the decision being made.

What that means:

• Minimum sufficient means the agent should not receive every possible customer field just because the data exists.
• Authoritative means the context should come from the system or rule that is trusted for that specific fact.
• Permitted means the data may be used by this user, agent, process, channel, purpose, and jurisdiction.
• For the decision being made means context is not a generic 360-degree customer record. It is assembled for a specific action.

For smaller companies, platform-native AI can be a very good answer. If most customer data, marketing engagement, sales activity, service history, lifecycle logic, and reporting all sit inside one CRM, it makes sense for the CRM to become the place where AI is deployed. In that environment, CRM-native AI can be genuinely valuable.

But enterprise environments are often different. Sales activity may live in Salesforce. Marketing campaigns may live in one or multiple HubSpot portals. Account ownership may be maintained in a shared spreadsheet. Financial data, margins, invoices, and credit status may live in SAP. Product usage may sit in a data warehouse. Consent may be governed somewhere else entirely.

This changes the AI question. If the CRM, or any platform for that matter, only sees part of the customer, the platform-native AI can only reason from the part of the customer it can see. That may be enough for some actions. It is not enough for all of them.

Native AI and horizontal AI are not enemies

By horizontal AI, I do not mean “one giant AI tool replacing every platform” or a general-purpose assistant where employees paste data from different systems and hope for the best. What I mean is a solution that can assemble the context and coordinate decisions across multiple systems, instead of operating only inside one application.

Platform-native AI is strongest when the platform has enough context and the action belongs inside that platform. Horizontal capability becomes important when the decision requires context, rules, and execution paths across several systems or business functions. It is not about native AI versus horizontal AI, it is about knowing which layer each should own.

The CRM is not always the context layer

A CRM is often described as the customer source of truth. Sometimes it is. More often, it is the system of engagement, the commercial activity layer, or the place where selected parts of the customer relationship are supposed to be recorded.

That is very different from containing the context required for every commercial decision. This distinction matters even more nowadays.

• Before AI, a fragmented view of the customer created reporting friction.
• With AI, fragmented context creates commercial risk.

A platform-native agent might recommend the wrong next step, enrol the wrong contact, suppress the wrong audience, send the wrong message, expose data in the wrong place, or automate a process nobody has properly governed.

That is why CRM-native AI should not be evaluated only by looking at features. Drafting emails is useful. Summarising CRM records is useful. Automatically creating tasks is useful. But those capabilities only become reliable when the agent has the right context, from the right sources, with the right permissions, for the specific action it is taking.

The problem is not native AI. The problem is native AI acting from incomplete context.

CRM-native AI works when the CRM holds enough of the decision context

I am not arguing against native AI inside CRMs, marketing platforms, service platforms, or other commercial systems. Native AI is often the fastest route to value when the platform already holds the relevant context and controls the execution path.

If a platform like HubSpot contains the contacts, companies, deals, marketing engagement, sales activities, tickets, forms, webpages, emails, workflows, and goals, then HubSpot-native AI can help teams move faster inside the platform.

For many small and mid-sized companies, that may be the right architecture. Do not overcomplicate it. But is that same platform-native AI just as valuable in a more complex business? Often, it isn't. Not because the AI is inherently bad, but because that one platform-native AI feature may not have the context it needs to work optimally.

• A sales agent can only reason from the sales context it can access.
• A marketing agent can only optimise from the marketing signals it can see.
• A service assistant can only advise from the service and customer history available to it.

If the decision crosses those boundaries, the architecture needs to cross them too.

AI needs unification before orchestration

The more complex the organisation, the more dangerous it becomes to skip the unification problem. An agent cannot make a good recommendation about an account if it cannot reliably connect the CRM record with product usage, support history, consent status, financial policy, current opportunities, campaign engagement, account ownership, and customer priority.

Without that, the agent is not reasoning from a sufficient customer context. It is reasoning from whichever slice of the customer happened to be available in the platform where the agent lives.

That is how businesses end up with confident but incomplete recommendations.

• A sales agent suggests outreach without knowing the account has an unresolved service escalation.
• A marketing agent enrols a contact in a campaign without seeing account-level suppression rules or consent restrictions.
• A CRM assistant scores a deal as inactive, while product usage shows strong buying signals.
• A campaign agent recommends a segment because the email open rates are good, without knowing the segment has very weak margins.
• A customer support agent misses the context to suggest an upsell because usage data sits in a data warehouse.

In these examples, the issue is architecture.

Before AI can help orchestrate work across the customer lifecycle, the organisation needs a coherent view of the customer for the specific decision being made. That means unification before orchestration. But unification does not have to mean centralising everything.

A better model: data, unification, decision, execution

The architecture can be explained in four layers:

1. Data
2. Unification
3. Decision and orchestration
4. Execution

Across all four layers sits governance, security, policy, and observability. Those controls are not a final checklist after the agent has acted. They need to govern what data can be retrieved, how context is assembled, which decisions can be automated, when human approval is required, and how execution is monitored.

1. Data layer

This is where the source facts and signals live.

CRM records. Marketing engagement. Sales activity. Support tickets. Product usage. Consent. Contracts. Invoices. Margin. Website behaviour. Advertising signals. Customer success notes. Finance data. Data warehouse records.

Some of that data may be clean. Some of it will not be. Some may be structured. Some may sit in emails, meeting notes, transcripts, documents, or fields nobody has standardised.

AI can help extract, classify, translate, and structure some of this raw material. But the goal of this layer is not intelligence yet. The goal is to make source data accessible, governed, traceable, and retrievable enough to be useful.

The question this layer answers, is:

What facts exist, where do they live, who owns them, who may access them, and can we retrieve them reliably when decisions need to be made?

If this layer is weak, every layer above it becomes fragile.

2. Unification layer

This is where the organisation creates account and contact views for specific purposes. The work in this layer consists of identity resolution, matching, enrichment, cleaning, deduplication, consent logic, relationships, policy signals, and assemling the context.

In plain language:

Are we sure this person, account, contract, opportunity, product signal, support issue, consent state, and commercial relationship belong together? And are we allowed to use that context for this decision?

This is where many AI strategies underinvest. It is not as sexy as an agent that helped book a meeting for an account executive. Those types of visible wins can create a false sense of success and a false sense of powerful intelligence. The agent may sound confident, but the view underneath may be incomplete, stale, conflicting, or only correct by accident.

A simple shared unique identifier helps, if it exists. However, that is rarely the whole answer. You may have global parent accounts, regional legal entities, sold-to, bill-to and ship-to accounts, distributors, end customers, contacts with multiple employer relationships, duplicate records, or separate customer numbers by business unit. AI can help suggest matches. It should not silently determine the golden record or merge high-value accounts without controls.

Sometimes the safest answer is a derived policy signal rather than exposing the underlying data. For example, a marketing agent may not need invoice details, dispute notes, or credit documentation. It may only need to know: commercial_expansion_eligible = false. That is a very different architecture from giving every agent a full customer record.

3. Decision and orchestration layer

Once the context is unified enough for the decision, the next question is: Now what? This is the decision and orchestration layer. But this does not mean the AI should make every decision.

A decision may involve business rules, eligibility policies, optimisation models, predictive models, AI recommendations, and human judgement:

• The AI may recommend.
• A policy engine may allow or block.
• A rules engine may decide which channels are available.
• An optimisation model may rank the action.
• A human may approve high-impact or irreversible steps.
• Generative AI may then personalise the execution.

That is safer than treating the agent as the single decision-maker.

The decision layer answers questions like:

• Should the account owner call?
• Should the contact enter a nurture flow?
• Should the customer be excluded from an upsell campaign because the customer state is wrong for expansion?
• Should service intervene before sales reaches out?
• Should marketing identify more stakeholders in the buying committee?
• Should the account be routed to a profitability-improvement playbook rather than another growth campaign?
• Should the system do nothing because the signal is weak or the action is not permitted?

This layer should consider more than intent. It should consider channel availability, channel effectiveness, recent performance, commercial priority, consent, risk, customer experience, local regulation, and the reversibility of the action.

4. Execution layer

This is where the work actually happens. It is also where platform-native AI can be very valuable. HubSpot-native AI can help draft content, support sales work, generate workflows, assist campaign building, improve ads or landing-page copy, and fine-tune last-mile execution.

The point is not to remove platform-native AI from the architecture. The point is to stop assuming the CRM automatically owns every layer. HubSpot may be one of the best places to activate marketing and commercial workflows. It may not be the best place to assemble the full decision context or decide the next best action across the business.

Governance is not a section at the end

The more AI can act, the closer governance needs to sit to the work. Governance should span every layer.

This is also where the European context matters. GDPR principles such as purpose limitation and data minimisation should influence the architecture. The goal is not to expose every customer fact to every agent. The goal is to retrieve or derive the minimum context needed for a permitted purpose.

The EU AI Act also pushes organisations toward a more explicit view of risk, oversight, transparency, and accountability depending on the use case. The more impact an AI-supported decision has, the more the organisation needs control, evidence, and human oversight.

That means practical controls such as:

• purpose-based access
• data minimisation
• source provenance
• freshness checks
• confidence scores
• approval thresholds
• audit trails
• retention rules for prompts, context, and logs
• separation between recommendation and autonomous execution
• monitoring for inconsistent treatment of customers or segments
• controls preventing exposing customer data without a permitted reason

This is where many organisations will struggle. They will buy AI features faster than they define operating rules.

Where HubSpot fits

HubSpot is moving toward a broader AI role; in their own words: context, orchestration, and action. That direction makes sense if HubSpot is the central customer platform, and most of the relevant data and work already live there.

But in more complex environments, that model has limits. Not because HubSpot is bad, but because reality is complex. The customer context needed for a decision may be too distributed, too sensitive, too finance-heavy, too product-specific, too regionally governed, or too dependent on systems of record that are not going away.

Trying to force all of that into the CRM can create new problems: duplicated data, brittle integrations, governance tension, object-model compromises, and operational overhead.

There may also be platform limits around custom objects, records, associations, API usage, permissions, and data modelling depending on the HubSpot edition and architecture.

But the point still holds: Not every context problem should be solved by pushing more data into the CRM. HubSpot can be essential. It is not always sufficient.

When native AI is enough, and when horizontal capability is needed

This is the practical test.

Use platform-native AI primarily when:

• the relevant context already lives in the platform
• the action is low risk and reversible
• the workflow is local to one team or function
• the platform is already the best execution environment
• the need for cross-system coordination is limited

Introduce horizontal orchestration when:

• the decision requires several authoritative systems
• the action crosses business functions or channels
• regional or legal restrictions differ
• he platform executing the action does not hold enough context to choose the action by itself

Use native AI where local context and local execution are enough. Use horizontal AI where the decision crosses system, ownership, or governance boundaries.

What this means for commercial leaders

The next CRM decision is not just a platform decision. It is an operating model decision.

If most customer context lives inside HubSpot, use HubSpot AI. But if customer context is fragmented across systems, do not expect CRM-native AI to become the brain by itself.

Use the CRM where it is strong: engagement, activation, workflow, reporting, and commercial execution. Then decide where the broader customer context should be unified, governed, and turned into action.

The label matters less than the operating principle: Data first. Unification second. Decision and orchestration third. Execution fourth.

If you skip the data layer, the system has weak facts.

If you skip unification, the agent acts from partial context.

If you skip orchestration, every platform optimises its own local workflow.

If you skip governance, experiments become risk.

If you skip execution, the intelligence never reaches the customer-facing work.

The bottom line

Platform-native AI will be useful, and in many companies, it will be enough to create real value. But in complex environments, customer context rarely lives neatly inside one platform. That is why the question should not be: Which CRM has the best AI? But it should be: Where should customer context be assembled, policy applied, decisions orchestrated, and work executed?

HubSpot, Salesforce, Microsoft, and other commercial platforms will remain important execution environments. But the next commercial operating system will not be defined by which platform has the best assistant.

It will be defined by which organisations can assemble the minimum sufficient and authoritative context for a decision, make the decision, and execute the decision through the right channels.