The Context Graph: Why Your Agents Are Only as Good as Their Memory

There is a quiet consensus forming in enterprise AI that agents are the future of how organisations operate. The conversation has moved past whether agentic AI will matter to how quickly it can be deployed. But in the rush to stand up agents, most organisations are making the same mistake: they are starting with the agents and hoping the data will sort itself out.

It will not.

We build an operational intelligence platform for professional services firms and private equity funds. We have spent the past eighteen months constructing what we call the Context Graph, the structured, semantically rich representation of how a business actually operates: its people, clients, engagements, decisions, and the relationships between them. This work has taught us something that feels increasingly important to say plainly: the quality of your agents is bounded by the quality of the context they operate on. Not the quality of the model. Not the sophistication of the orchestration. The context.

This article is about why the Context Graph is the real foundation for progress with agentic AI, and why the most overlooked step in the agent loop, the update step, is where the compounding value actually lives.

The Problem with Starting from Agents

The typical enterprise AI project starts with a use case. Automate this workflow. Summarise these documents. Draft this report. A team connects an LLM to some APIs, builds a prompt chain, and demonstrates something that works impressively in a demo and inconsistently in production.

The failure mode is predictable. The agent does not know that "Acme Ltd" in the CRM and "ACME Limited" in the finance system are the same client. It cannot tell you that the last three engagements for this client were delivered by the same team, or that the partner who manages the relationship is on leave next week, or that a similar proposal was rejected eighteen months ago for reasons documented in a meeting note. The agent is fluent but ignorant. It can talk about the business but it does not understand it.

This is not a model problem. It is a data problem, and more specifically, it is an identity and relationship problem. The knowledge an agent needs to be genuinely useful exists, but it is scattered across half a dozen systems, duplicated under slightly different names, and connected only in the heads of the people who happen to remember.

What the Context Graph Actually Is

When we talk about the Context Graph, we mean the structured, resolved, semantically connected representation of a firm's operational reality. It is not a single technology. It is what emerges when you do three things properly.

First, canonical entities. Every client, every person, every engagement, every deal gets a single authoritative identity, resolved across every source system. The same company that appears as a pipeline opportunity in Pipedrive, an active engagement in Forecast, and a revenue line in Xero becomes one entity with one identity and a full map of where its data originates. We maintain roughly 2,200 source mappings across seventeen canonical entity types for a single firm. This is not glamorous work, but it is the work that makes everything else trustworthy.

Second, the relationship layer. Once entities are resolved, the connections between them become explicit and queryable. Who introduced which deals, and what happened to them. Which team members have worked together across multiple engagements. Which service lines are delivered by which teams at which rate cards. This is the intelligence that currently lives distributed across partners' inboxes, contact books, and memory. Making it explicit, persistent, and traversable is arguably the single highest-value capability a data platform can deliver. In our graph, twelve node types are connected by twenty-four relationship types, each carrying temporal metadata (when the relationship started, when it ended) so the graph represents how the business has evolved, not just how it looks today.

Third, the knowledge layer. Alongside the structured entity graph sits a semantic search layer over unstructured content: documents, meeting transcripts, notes, proposals. This is where the qualitative context lives. The investment thesis. The client's unspoken preferences. The reasoning behind a staffing decision. We index this content with vector embeddings and a hybrid search approach (semantic similarity, keyword matching, and document metadata) so that both humans and agents can surface relevant knowledge without knowing exactly where to look.

Together, these three layers form the Context Graph. It is what gives an agent (or a human, for that matter) the ability to answer the question: "Tell me everything we know about this client, this person, or this situation."

The Agent Loop and the Step Everyone Skips

Every agent, regardless of framework or implementation, follows some version of the same loop: observe the current state, plan what to do, act on that plan, and update the system with what was learned.

Most of the industry's attention is on the first three steps. Better planning, more sophisticated tool use, more reliable action execution. These matter. But the step that creates durable value is the fourth: update.

When an agent prepares a meeting briefing, it does not just read context and produce output. It captures what it assembled and why, creating a record that the next briefing can build on. When a pipeline monitoring agent flags a stalled deal, it records the observation, the evidence it considered, and the recommendation it made. When a human makes a decision informed by agent analysis, the decision itself, its rationale, its context, and its outcome can be written back into the graph as a structured decision trace.

We implemented this as a first-class entity in our ontology. A Decision node records what was decided, who made it (and whether a human or an agent initiated it), what knowledge informed it, and which entities it affects. These traces are connected to the rest of the graph through typed relationships: MADE_BY links to the person, MADE_AT links to the event where it happened, INFORMED_BY links to the documents or data that supported it, and AFFECTS links to the clients, engagements, or deals it touches.

This is not logging. Logging tells you what happened. Decision traces tell you why it happened, what was considered, and how the outcome connects to everything else the firm knows.

The Compounding Effect

The update step is where the Context Graph transitions from a static asset to a compounding one.

Consider the trajectory. In month one, an agent preparing a client meeting briefing draws on CRM records, recent invoices, and team allocation data. It produces a useful but generic summary. In month six, that same agent also draws on the decision traces from five previous meetings: what was discussed, what was agreed, what the client's concerns were, and how the firm responded. The briefing is now meaningfully better, not because the model improved, but because the context did.

In year two, a new partner takes over a client relationship. In a traditional firm, this would trigger a scramble to capture institutional knowledge before the departing partner leaves, recovering only a fraction of what they know. With a Context Graph that has been accumulating decision traces, engagement history, and relationship context as a by-product of daily operations, the new partner inherits the collective intelligence of everyone who managed that relationship before them.

This is the architectural bet: a system that captures decisions and makes them retrievable will compound in value faster than one that merely reports on transactions. Memory is what turns data into intelligence.

Professional services firms are acutely vulnerable here. Research suggests that 42% of institutional knowledge resides solely with individual employees. When a senior consultant who managed key client relationships for five years moves on, the successor inherits the accounts but not the context. The Context Graph changes that equation. It does not replace human judgement, but it ensures that judgement is informed by the full history of the firm's experience, not just what the current team happens to remember.

Why This Cannot Be Bolted On

There is a tempting alternative that avoids the hard work of building a Context Graph. Connect your business systems via APIs, point an LLM at the live data, and let the model figure out the rest at query time. Several products on the market take exactly this approach, and for simple questions they work surprisingly well.

The limitations become apparent quickly. When the agent queries Pipedrive and Xero for the same client, it relies on the LLM to recognise that slightly different company names refer to the same entity. This works in straightforward cases and fails unpredictably in complex ones. There is no canonical identity, no source mapping, no deterministic resolution chain.

More fundamentally, the query-at-runtime approach cannot support multi-hop relationship traversals. A question like "Which of our team members have previously worked with contacts at organisations that invest in companies using our due diligence service?" is trivial to answer when you have a resolved entity graph with typed relationships. It is structurally impossible when you are querying source APIs in real time.

And the update step? It does not exist. Each query starts from scratch. The system does not get structurally smarter over time. There is no place to write a decision trace, no way to surface precedents, no mechanism for institutional memory to accumulate. The agent may be fast, but it is amnesic.

Our Experience Building It

We run our own consultancy on the Attercop Platform. Everything described in this article reflects what we have designed, built, and operate daily. This is not a theoretical architecture; it is the system our team uses to manage clients, prepare for meetings, track pipeline health, and make staffing decisions.

Building the Context Graph is the hardest part of the work, and the most valuable. The entity resolution alone, ensuring that "the same client" means the same thing across every system, took months of careful engineering. Deterministic matching handles the majority of cases (same email address, same company registration number). Ambiguous cases go through structured human review, because confidently wrong resolution is worse than no resolution at all.

The ontology, the schema that defines what entities exist and how they relate to one another, went through six phases of refinement before we were satisfied. We unified people across systems (a contact in the CRM and a resource in the planning tool are the same person, with different roles). We modelled events as first-class entities so that meeting context is connected to the clients and engagements discussed. We added temporal metadata to relationships so the graph captures how the business has evolved, not just its current state.

None of this is AI work in the fashionable sense. It is data engineering, ontology design, and identity resolution. It is the foundation that makes AI work actually work.

The reward is that when we deploy an agent on top of this foundation, it starts with a genuine understanding of the business. Our meeting briefing agent does not just pull calendar entries. It assembles client history, engagement status, outstanding invoices, team utilisation, recent deliverables, and relevant decision context into a briefing that a partner can scan in three minutes before walking into a meeting. The agent can do this because the Context Graph gives it the connected, resolved, temporally aware representation of the firm that no single source system contains.

The Replicability Thesis

The good news for professional services firms is that the ontology, the schema of entities and relationships that defines the Context Graph, is remarkably consistent across firms of similar structure. Clients, engagements, service lines, teams, billing roles, rate cards, pipeline deals: these are universal concepts in professional services, even if the terminology varies. One firm's "project" is another's "engagement." One firm's "practice area" is another's "service line." The underlying structure is the same.

This means the Context Graph does not need to be designed from scratch for each firm. The canonical ontology can be adapted and extended rather than reinvented. The mapping between source systems and canonical entities is where the per-firm customisation lives, handled in the transformation layer rather than in the ontology itself. A three-layer vocabulary model (canonical terms, ontology aliases, tenant display preferences) allows each firm to see its own language while the platform operates on a shared semantic foundation.

For private equity funds, the same principle applies but the entity model shifts. Deals, funds, portfolio companies, LP commitments, co-investors, and board relationships replace engagements and service lines. The structural pattern is identical: resolve entities, connect them with typed relationships, layer knowledge on top, and let the graph compound.

Where to Start

The instinct with any new technology is to start with the most visible capability. In the case of agentic AI, that means standing up an agent and demonstrating a workflow. This is understandable but backwards.

The sequence that delivers durable value is:

First, unify your data. Connect your core operational systems and build a single, trustworthy view of your business. Resolve entity identities so that "the same client" means the same thing everywhere. This phase typically takes two to four months and delivers immediate value: reliable cross-system reporting, a unified dashboard, and the elimination of manual data reconciliation. No agent required.

Second, make it queryable. Layer a conversational interface over the unified data. This transforms access to operational knowledge from a technical skill to a conversation. Partners and managers can ask questions in plain language and get answers drawn from structured records, semantic search across documents, and the entity graph, without needing to know which system holds the answer.

Third, deploy agents on the foundation. With a Context Graph in place, agents start from a position of genuine understanding. They can observe, plan, and act with awareness of the full operational context. And critically, they can write structured updates back into the graph, closing the loop that makes the system compound.

Each phase delivers standalone value. The first is valuable without the second. The second is valuable without the third. But the third, the agentic layer, is only as good as the foundation beneath it.

The Real Competitive Advantage

The firms that will benefit most from agentic AI are not those that deploy agents fastest. They are those that build the richest Context Graph. An agent operating on a comprehensive, well-resolved, decision-trace-enriched graph will outperform a more sophisticated agent operating on fragmented, unresolved data, every time.

This is a defensible advantage. The Context Graph compounds with use. Every resolved entity, every connected relationship, every indexed document, every recorded decision trace makes the system more valuable. A firm that has been operating on a Context Graph for two years has an institutional memory that a competitor starting from scratch cannot replicate quickly. The graph is not just a technical asset. It is the encoded operational wisdom of the firm.

The technology to build this exists today. The models are capable. The infrastructure is mature. The question is not whether your firm will need a Context Graph, but whether you will have one when your competitors do.