Your CRM Is Feeding AI Agents Mutually Exclusive Truths

[Pratik Thakker]

Consider a hypothetical revenue agent instructed to follow up with an account that returned to the pricing page three times. The CRM says the deal is active. Product analytics says intent is high. Billing says the customer is current. Support shows an unresolved severity-one escalation. The consent service prohibits marketing outreach. A territory table assigns a different owner.

Each system may be accurate. The danger appears when an agent compresses the claims into one answer: "This is a high-intent account, so send the message."

That is not a hallucination in the usual sense. It is a resolution failure.

Disclosure: I am the founder and CEO of INSIDEA, an Elite HubSpot Partner. This article reflects practical experience and independent research. It is not sponsored by HubSpot or any other company mentioned.

Enterprise teams need a control layer between retrieved context and agent action. I call it the Assertion Conflict Graph.

A field is not a fact​

Most CRM architectures expose a record as a collection of current values:

{
  "company_id": "co_4821",
  "deal_stage": "contract_sent",
  "account_status": "active",
  "owner_id": "user_17",
  "contactable": true
}

This representation works for interfaces and reporting. It is incomplete for autonomous action because the final value hides the path that produced it.

HubSpot's object APIs can return selected current and historical property values through propertiesWithHistory. HubSpot also supports custom properties with unique values. Those capabilities provide raw material, but do not decide which assertion should govern an action.

An assertion is more specific than a field value. It is a claim made by a source about an entity at a point in time, under a defined authority and policy context.

{
  "assertion_id": "asrt_01J8Y7M5",
  "entity_id": "company:co_4821",
  "predicate": "outreach_permitted",
  "value": false,
  "source": "consent-service",
  "observed_at": "2026-08-31T14:03:22Z",
  "recorded_at": "2026-08-31T14:03:22Z",
  "effective_from": "2026-08-31T14:03:22Z",
  "authority_tier": 1,
  "confidence": 1.0,
  "policy_basis": "contact-opt-out",
  "derived_from": ["consent-event:evt_9918"]
}

A boolean says no. An assertion explains whose no it is, when it became effective, what policy created it, and which event supports it.

The Assertion Conflict Graph​

The graph has two primary elements:

• Assertion nodes represent claims about an entity.
• Typed edges represent relationships between claims.

The minimum useful edge vocabulary is small:

Edge	Meaning	Example
same_entity	Two assertions concern the same resolved entity	CRM company and billing account map to the same legal customer
contradicts	Both assertions cannot govern the proposed action	outreach_permitted: true conflicts with a current opt-out
supersedes	One assertion validly replaces another	A signed renewal replaces an earlier pending status
derived_from	A claim depends on another claim or event	Health score derives from usage and support signals
allowed_by	A policy or approval authorizes the claim's use	Discount action is allowed by a current approval record

Unlike a general enterprise context graph, the Assertion Conflict Graph has one narrow job: detect incompatible claims for a proposed action and produce a controlled resolution before execution.

The model has a standards foundation. W3C PROV covers entities, attribution, processing, derivation, and provenance validation. SHACL defines shapes and constraints for validating graph data. An implementation need not use RDF, PROV, or SHACL, but should preserve identity, attribution, derivation, constraints, and validation.

Image credit: Original AI-assisted illustration created for this article.

Six conflicts a record-level view will miss​

Conflict	What the record hides	Required control
Identity	A parent, subsidiary, billing account, and domain may be related without being interchangeable	Resolve durable cross-system keys and retain source identifiers before comparing values
Temporal	A deal can be active Monday and closed-lost Thursday; consent can be granted in January and withdrawn in August	Distinguish recorded, observed, and effective time because events may arrive late
Authority	A system may write a property without owning its business meaning	Define authority by predicate and context, such as CRM for deal stage and consent service for contactability
Policy or consent	An accurate signal may still be unusable for the proposed action	Evaluate permission before optimization; a denial is a constraint, not a score
Lifecycle	"Active" can describe a subscription, opportunity, onboarding project, or support entitlement	Attach object type, state machine, and valid transition rules
Derived metric	Health, intent, lead, and forecast scores can use different windows, weights, and missing-data rules	Preserve derivation so confidence does not hide a definition conflict

A weak identity join, ambiguous lifecycle, or hidden derivation should never authorize a high-consequence action.

Deterministic resolution before probabilistic reasoning​

Do not ask a language model to choose whichever assertion sounds most convincing. Send each conflict set through ordered gates.

Gate	Decision	Fail-closed response
Identity	Do the claims refer to the same entity, object, and relationship?	Narrow the action or ask for clarification
Authority	Which source is authorized to make this type of claim?	Exclude non-authoritative claims
Freshness	Which assertion is effective at action time under a predicate-specific window?	Reject stale action-critical evidence
Policy	Is the data permitted for this action?	Stop when policy denies use
Consequence	What happens if the resolution is wrong?	Require higher certainty or human review for higher-risk actions

An authoritative consent assertion outranks a marketing inference about contactability. A page view may decay in hours while a signed contract remains effective for years. A policy denial is never another signal to average.

Only after these gates should a model rank remaining alternatives:

deterministic constraints
        ↓
eligible assertions
        ↓
probabilistic interpretation
        ↓
consequence-aware action gate

Confidence is evidence about uncertainty. It is not permission, provenance, authority, or truth.

A minimal fail-closed resolver​

The resolution layer does not need to begin as a graph database or a model prompt. It can start as a small deterministic service that validates assertions, rejects non-authoritative or stale claims, and refuses to act when critical evidence is missing.

The order matters:

function resolveAction(assertions, proposedAction, now) {
  validateRequiredFields(assertions);
  requireOneResolvedEntity(assertions, 0.95);

  const eligible = assertions
    .filter((claim) => sourceOwnsPredicate(claim.source, claim.predicate))
    .filter((claim) => isFreshForPredicate(claim, now));

  requireCriticalEvidence(eligible, proposedAction);

  if (policyBlocks(eligible, proposedAction)) {
    return stopWithEvidence(eligible);
  }

  if (consequenceRequiresReview(eligible, proposedAction)) {
    return escalateWithDecisionTrace(eligible);
  }

  return actWithinDeclaredAuthority(eligible);
}

This is intentionally not a confidence-weighted vote. A high-confidence page-view inference cannot outvote a current consent denial. A stale authoritative claim is not made current by assigning it more weight. Missing action-critical evidence results in escalation, not optimistic completion.


The resolver above is pseudocode, not a production implementation. A real deployment needs tested identity matching, authority rules, policy semantics, timing, logging, and review paths. Passing isolated fixtures would not establish legal compliance, production safety, or business correctness.

A worked revenue scenario​

Assume an agent is deciding whether to send a renewal-expansion message.

Assertion	Source	Status
Account has high product usage	Product analytics	Current, high confidence
Expansion opportunity is open	CRM	Current, sales-authoritative
Invoice is paid	Billing	Current, finance-authoritative
Severity-one case is unresolved	Support	Current, support-authoritative
Contact opted out of marketing	Consent service	Current, policy-authoritative
CRM owner is user_17	CRM	Current
Territory assignment is user_42	Territory service	Newer, territory-authoritative

A retrieval-only agent may summarize the buying signals and send from the CRM owner. The conflict graph produces a different result:

1. The identity gate confirms that the usage account, billing account, opportunity, and support case belong to the same customer.
2. The authority gate accepts billing for payment status, support for escalation state, consent for contactability, and the territory service for assignment.
3. The freshness gate identifies the territory record as newer than the CRM owner field.
4. The policy gate blocks marketing outreach because of the opt-out.
5. The consequence gate recognizes that an external message can create customer and compliance risk.

The correct output is not "low confidence." It is a structured decision:

{
  "decision": "stop_external_outreach",
  "allowed_actions": [
    "create_private_review_task",
    "notify_current_territory_owner"
  ],
  "blocking_assertions": [
    "contact-opt-out",
    "open-severity-one-case"
  ],
  "owner_conflict": {
    "resolved_to": "user_42",
    "reason": "territory-service-authority-and-freshness"
  },
  "review_required": true
}

The agent prepares the internal task, attaches evidence, and routes it correctly without converting conflicting context into unauthorized outreach.

An implementation path that does not require replacing the CRM​

The graph can begin as a control service beside the existing CRM.

1. Ingest and identify. Capture source IDs, property history, timestamps, and events, then map CRM records, billing accounts, product workspaces, and support organizations to durable entity keys.
2. Attach provenance. Record source, authority, observation time, effective time, derivation, and policy basis.
3. Detect conflicts. Apply predicate rules and graph constraints to find contradictions, invalid states, and missing evidence.
4. Resolve or escalate. Run deterministic gates and preserve unresolved conflicts instead of overwriting them.
5. Issue and trace. Return eligible assertions, blocked actions, approvals, and the resolution trace, then store what the agent saw and which rules fired.
6. Learn without erasing disagreement. Update rules from reviewed outcomes while retaining original assertions and decision traces.

NIST's Generative AI Profile includes actions for tracing the origins and modifications of digital content, using provenance and anomaly-analysis tools, documenting how provenance data interacts with privacy and security, testing systems in real-world scenarios, and monitoring human overrides. Applying those controls to CRM business assertions is an architectural inference, not a claim that NIST prescribes this graph.

Metrics that reveal whether resolution is working​

Measure the control layer, not only agent task completion.

Metric	What it reveals
Unresolved conflict rate	Share of action requests that reach no safe resolution
Stale assertion rate	Share of decision-critical assertions outside their freshness window
Conflicting-authority rate	Frequency of competing claims from sources with overlapping authority
Agent actions blocked by conflict	Volume and type of unsafe actions prevented
Human resolution time	Time required to resolve escalated conflict sets
Repeated conflict rate	Conflicts recurring after a prior resolution, indicating a system-design issue
Post-action contradiction rate	Actions later shown to conflict with authoritative evidence available at decision time

The last metric separates unforeseeable change from preventable resolution failure.

The source of truth is not enough​

"Choose one source of truth" works for a narrow property. It does not solve a decision combining sales, billing, customer health, consent, ownership, and policy.

One source may govern each predicate, but no system owns every meaning. The goal is a governed way to compose authoritative assertions without hiding conflicts.

An agent needs more than context. It needs admissible context, provenance, constraints, and a reasoned path from evidence to action.

Frequently asked questions​

What is a CRM assertion conflict?​

A CRM assertion conflict occurs when claims about the same entity cannot safely govern one action. It may concern identity, time, authority, policy, lifecycle state, or derivation.

Why is more context not always better for an AI agent?​

Additional context can introduce incompatible claims. Without provenance and resolution rules, an agent may blend them instead of recognizing a block or review requirement.

How should an AI agent resolve conflicting CRM data?​

Use identity, source authority, predicate-specific freshness, policy or consent, then action consequence. Apply probabilistic reasoning only after removing ineligible assertions.

The control layer agents are missing​

Enterprise AI agents act across systems built by different teams, timelines, and definitions of truth.

Do not flatten every system into one oversized record. Preserve claims, provenance, and conflicts long enough to make a governed decision.

When the Assertion Conflict Graph is in place, the agent does not need to pretend that the business has one perfectly clean reality. It can recognize disagreement, apply explicit rules, and choose the safest useful outcome: act, narrow, ask, escalate, or stop.

That is a more credible foundation for enterprise autonomy than a larger context window.

Vested-interest disclosure: INSIDEA is linked because I lead the company and its work includes HubSpot, CRM, RevOps, and AI services. The framework and recommendations in this article are independent analysis, not sponsored content.

Sources​

1. HubSpot, Properties API
2. HubSpot, Using Object APIs, including property history
3. W3C, PROV Overview
4. W3C, Shapes Constraint Language (SHACL)
5. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
6. HackerNoon, Context Graphs: Building Production World Models for the Age of AI Agents