The GTM Identity Graph: Who Your Agents Need to Know Before They Act

Illustration generated with AI.

Part of a series on building enterprise agentic AI. Companion to The GTM Semantic Layer. A practitioner’s reading list — the second of two durable foundations your agents stand on.

A note on process: I wrote this with AI assistance. The thesis, argument, and judgment are mine; I used an AI tool to help draft and refine prose, and independently verified every source and statistic cited.

Disclosure: I work at Atlassian, whose Teamwork Graph is one of the examples below.

The Forecast That Was Wrong for a Reason Nobody Checked

The number was governed. It was still wrong.

Picture a revenue-operations agent asked for committed pipeline this quarter. It knows exactly what “committed” means — the definition is pinned in the semantic layer, code-reviewed, identical for every team. It runs the query and returns a number.

The number is too high. Not because the math is wrong, but because “Acme Corp” in the CRM and “Acme, Inc.” in the marketing platform are the same company, and the agent counted the deal twice. The follow-up sequence it queues then emails the same buying committee from two “different” accounts. A perfect definition, applied to an entity the agent never actually resolved.

This is the failure the current conversation keeps missing. Everyone is rushing to define their terms. Almost nobody checked whether the agent can tell its own accounts apart.

Two Foundations, Not One

An agent reasoning over go-to-market data needs two things that do not change per request. The industry has named one of them and keeps forgetting the other.

• The semantic layer is the shared language — what “opportunity,” “committed pipeline,” “active account” mean, defined once so every agent, dashboard, and rep gets the same answer. It makes an agent correct.
• The identity graph is who and what is real, and how they relate — which records are the same account, which contacts form one buying committee, who actually owns the deal. It makes an agent’s correctness land on the right thing.

Definitions without resolved entities means knowing the word but not the referent. You can define “net new revenue” flawlessly and still sum it across three duplicate account records. The semantic-layer piece in this series gave agents the what. Identity is the other half.

What a GTM Identity Graph Actually Does

Strip away the branding and an identity graph does three concrete things. Each maps to a go-to-market failure you have already seen.

• Entity resolution. Decide that “Acme Corp,” “Acme, Inc.,” and acme.com are one account — across CRM, marketing automation, product telemetry, and support.
• Relationship mapping. Stitch contacts into a buying committee, the committee to an opportunity, the opportunity to an account — and surface the true deal owner, not just the record owner.
• Temporal state. Know what was true when — the account’s tier at renewal, the segment at the moment the deal closed, not just today’s value.

It is the substrate that turns disconnected facts into something an agent can traverse without guessing.

Isn’t This Just Ontology?

Fair challenge — so draw the line cleanly. A taxonomy says an account is a kind of company; an ontology says an account has contacts and opportunities and defines which relationships are legal. Both are structure — a blueprint of types, empty of records. The identity graph is that blueprint populated and deduplicated: it says these three records are the same account, and that step — entity resolution — is the load-bearing one your agent is actually skipping. An ontology with unresolved entities is a perfect schema wrapped around a broken graph: “Acme Corp” and “Acme, Inc.” still sit as two nodes, and the agent still double-counts.

The Pattern Is Already Built

Atlassian Teamwork Graph. The clearest agent-native example. Every item — a Jira work item, a Confluence page, a Slack message, a GitHub PR — becomes an object with a defined type, connected by typed, directional relationships. Over 150 billion objects and relationships, reachable by agents over MCP. It resolves the true owners of a project and its decision trails — who owns it now, what broke last time — not static watchers. Grounding an agent in the graph delivered 44% more accurate answers with 48% fewer tokens in Atlassian’s own benchmarks. A note on vocabulary: Atlassian describes Teamwork Graph as a “context engine,” which fits — the graph is the durable context an agent reasons over. The next piece in this series untangles how that shared term, “context,” gets used in two different ways across the industry.

Microsoft Graph. Proof this is a pattern, not one vendor’s bet. A single endpoint over a people-centric graph, with typed relationships — manager, memberOf, people, trending — and permissions that ride along with every query. The canonical example is meeting prep: resolve the attendees, get their profiles, traverse to their manager and the documents they are working on. Swap the entities for accounts and buying committees and you have the go-to-market version, unchanged in shape.

Palantir Foundry Ontology. The structural anchor for the whole argument. Palantir states plainly that its Ontology “is not a semantic layer.” It is a fourfold integration of data, logic, action, and security — modeling decisions with nouns and verbs, not just definitions. That line does the work: the industry’s most serious “agent brain” treats identity, relationships, and action as a layer distinct from meaning. Which is the entire thesis: two foundations, not one.

The GTM-Native Ones

Salesforce Data Cloud — Unified Profiles. The cleanest go-to-market walkthrough of entity resolution there is. “Rachel” appears across Commerce, Service, and Sales with different emails and a misspelled “Rochelle.” Match rules plus reconciliation rules link them into one unified profile. The unified profile is a key ring, not a golden record — it links records without overwriting source data, so lineage stays intact. And resolution is mutable: fix the misspelling and the profile re-links on the next run. Identity is a living thing, not a one-time cleanup.

LiveRamp — the customer identity graph. The category leader for resolving a person across the fragmented outside world. RampID and AbiliTec combine deterministic and probabilistic matching across the largest deterministic graph on the open internet — 250M+ US consumers. Whirlpool eliminated 200,000 duplicate audiences; Tailored Brands lifted ROAS 26% by resolving in-store and online to one identifier. One caution: LiveRamp frames identity as the path to “relevance” — relevance is the next piece’s word for the context layer. Resolving who someone is sits upstream of deciding what is relevant to them right now. Keep the two straight.

Why Identity Comes First

An unresolved graph is not knowledge — it is disconnected facts. In a table, a duplicate record is a nuisance. In a graph, a duplicate is a false node, which means false edges, which means the agent is navigating a structure that does not reflect reality.

In go-to-market terms, a duplicate account does not just miscount pipeline. It corrupts routing — two reps work “different” accounts that are one. It corrupts attribution — the journey splits across phantom entities. It corrupts forecasting — every roll-up inherits the error. If your graph has messy entities, your agent retrieves messy context, and no better definition rescues it.

So resolving who is upstream of computing what. Hand a brilliant model a perfect definition and an unresolved graph, and it produces a confident, governed, wrong number — faster than before.

The semantic layer tells the agent what “the account” means. The identity graph tells it which account you meant. Skip the second and the first just computes the wrong answer with confidence.

The Counterargument That Keeps Me Honest

The sharpest pushback is that none of this is new. Sanjeev Mohan lays out the full stack — metadata, semantics, taxonomy, ontology, knowledge graph, context — as clean layers, and opens with a pet peeve aimed squarely at pieces like this one: people take the well-known techniques of semantics, call them something fresh, and declare a brand-new field.

In his framing, identity resolution lives inside the ontology layer, and the knowledge graph is just “persistent context” — a nested ladder, not two co-equal foundations. He is right that entity resolution is decades old and that much of this is rebranding.

That sharpens the case rather than weakening it. The technique is old; the cost of skipping it is new. When a human read the report, a duplicate account was an annoyance someone caught in a meeting. When an autonomous agent acts on it — routing deals, sending sequences, updating the CRM — the duplicate becomes an operational error with no human in the loop. Treating identity as a co-equal foundation, not a sublayer, is what forces teams to actually resolve it before the agent acts.⁠

Where This Heads

Meaning and identity are both durable — governed, shared, unchanging per request. But an agent doesn’t only need to know what your terms mean and which entities are real. It needs to remember what happened last time. The next piece is the third foundation: memory — what the agent carries across conversations, and, just as important, what it should forget. Meaning and identity are stable; memory is what accumulates.

It also threads back through the rest of the series. Your spec has to name entities, not just metrics. Your evals have to test whether the agent resolved the right account, not just whether it calculated the right formula. You need both durable foundations — and then you need the layer that changes over time.

The Reading List

The graphs that prove the pattern

• What is Teamwork Graph — Atlassian — objects, typed relationships, and an agent-native graph reachable over MCP.
• Microsoft Graph overview — Microsoft — the meeting-prep traversal that shows identity-graph reasoning in one move.
• The Ontology system — Palantir — “not a semantic layer”: data, logic, action, security as a layer distinct from meaning.

Identity resolution for go-to-market

• Get to Know Unified Profiles — Salesforce — match and reconciliation rules, unified profile vs. golden record, the key-ring model.
• Identity Resolution: What It Is, How It Works — LiveRamp — deterministic vs. probabilistic matching across the customer identity graph.

Why resolution comes first

• Entity Resolved Knowledge Graphs — ODSC / Clair Sullivan — a graph is only as good as the entities it contains; unresolved graphs give confident wrong answers.
• Entity Resolution in Knowledge Graphs — Dhruv Thanawala — the math of “same entity”: scoring, thresholds, and why messy entities mean messy context.

The counterargument

• FAQ on Metadata, Semantics, Ontology, Knowledge Graphs, and Context — Sanjeev Mohan — the layered-stack view, and the “old wine in a new bottle” challenge worth answering honestly.

**The semantic layer tells your agent what your terms mean. The identity graph tells it which entity you meant. Skip the second and the first just computes the wrong answer with confidence — governed, fluent, and pointed at the wrong account.

Two foundations, not one. Resolve who before you compute what, or every number your agent produces inherits a duplicate it never saw.**