The Knowledge Graph Tool Inside Our AI Accelerator
Enterprise data is relational in the truest sense of the word. Customers sit inside accounts, suppliers feed products, transactions link counterparties, and risk travels along chains of ownership. Most of that data nevertheless lives in systems that flatten relationships into rows, so every meaningful question becomes a chain of joins that somebody has to know how to write. When we began giving AI agents access to enterprise data inside our AI Accelerator, our agent orchestration platform, we noticed the pattern our clients describe everywhere. Models retrieve individual facts comfortably, but the questions that carry commercial weight are almost always questions about connections.
That observation led to one of the most productive architectural decisions in the platform. We gave our agents a knowledge graph built on Neo4j, we exposed it through the Model Context Protocol, and we surrounded it with the guardrails that enterprise deployment demands. This article explains how the three pieces fit together, and why the combination behaves as an accelerator rather than as yet another integration to maintain.
Why a graph belongs in an agent platform
A knowledge graph stores entities and the relationships between them as first-class citizens rather than as foreign keys to be reassembled at query time. The question of which suppliers are exposed to a given counterparty through any path of ownership is a single traversal in a graph, where the equivalent SQL demands recursive joins that few analysts would attempt. For AI agents the fit is even stronger than it is for people, because large language models write the Cypher query language fluently once they are shown the shape of the graph, and a graph schema of labels, relationship types and properties is compact enough to sit comfortably inside a model's working context.
Inside the accelerator the first tool an agent reaches for is schema introspection. The platform returns the node labels, relationship types, property keys and record counts of the connected graph, and the agent's own guidance instructs it to look before it writes. That single behaviour removes the most common failure mode we see in text-to-query systems, which is a model guessing at structure it has never seen.
One protocol, a whole estate of integrations
The second piece is the Model Context Protocol, the open standard that lets a model call external tools through a uniform interface. It runs a single MCP gateway that mounts our integration servers in one process, covering Slack, GitHub, Google Drive, SharePoint, Jira and Confluence, Snowflake and Neo4j among others, alongside a sandboxed code execution service that powers our document skills. Each integration is discovered as a plugin, so adding a new server requires no changes to the gateway at all. Every server presents the same surface for health, tool listing and invocation, sits behind the same authentication, throttling and observability machinery, and can be switched off per deployment when a client wants a narrower surface.
The consequence for delivery is easy to underestimate. Because every integration speaks the same protocol, capabilities stack without additional plumbing. The same agent that reads a warehouse through the Snowflake server can build a graph through the Neo4j server and share its findings through the Slack server, and none of those pairings required us to write pairing-specific code.
A graph the agent can be trusted with
The Neo4j server exposes four tools. One introspects the schema, one runs read-only queries, one performs writes, and one returns a graph payload for interactive visualisation. Keeping reads and writes on separate tools is a deliberate safety decision rather than a stylistic one. The read path rejects any statement containing write operations, strips string literals and comments before checking so that legitimate values cannot be misclassified, and refuses multi-statement submissions outright. The write path returns transaction counters so the agent knows precisely what changed, and any deletion that is not bounded by a predicate, a label or an identifier is refused until it is resubmitted with an explicit confirmation flag. A model can be a capable graph engineer and still never be one keystroke away from emptying a database.
Results are shaped for a model's context rather than for a terminal. Queries are capped at a sensible row limit, and large result sets are replaced by a statistical summary of every column together with a small representative sample, accompanied by a note telling the agent to narrow its filters if it needs specific rows. Visualisation takes the opposite route, because the full graph payload never enters the model's context at all. It travels through a side channel to the front end, where users explore it as an interactive force-directed view in two or three dimensions, while the model sees only a short summary of what it produced.
From warehouse rows to a working ontology
The piece that turns all of this into an accelerator arrives when two integrations are active at once. When an agent holds both the Snowflake and the Neo4j tools, it injects a cross-tool method that teaches the model how to translate relational data into a graph ontology. The method insists on understanding the data before writing anything, and then maps relational shapes onto graph constructs. Tables with their own identity become nodes, junction tables become relationships, small lookup tables collapse into properties, and foreign keys become relationships only when their cardinality makes them meaningful. Writes are idempotent by construction, so a re-run converges instead of duplicating, and endpoint nodes are always created together with the relationship that joins them, which means the result can never be a cloud of disconnected points.
An ontology exercise of this kind has traditionally been a workshop-heavy engagement measured in weeks. Inside the accelerator it has become a working session rather than a project. An analyst connects a schema, asks the agent to propose a graph model, inspects the visualisation, corrects the parts that only a domain expert would know, and finishes with a queryable knowledge graph the same day.
What used to be a bespoke integration project for every client and every data source is now configuration on a platform that already knows how to behave.
Tenancy, isolation and the two lives of a graph
Our AI Accelerator is multi-tenant, so the graph layer has to be as well. By default the platform runs the graph as a governed scratch pad. Every node an agent writes is tagged to a session derived from the tenant and the workflow, reads are filtered so that one tenant's session can never surface another's data, and a background sweep retires expired sessions on a schedule. Re-running the same workflow for the same tenant deterministically reuses its own subgraph, which makes iteration cheap and cross-tenant contamination structurally impossible.
Some clients need the opposite posture, a durable graph that behaves as a long-lived asset. For those deployments the platform supports a hardened topology with encrypted storage, scheduled snapshots, logical backups and monitored recovery, switched on through infrastructure configuration rather than code changes. During any graph downtime the rest of the platform is unaffected, since tool calls fail cleanly, health checks report the true state of the backend, and every other integration continues to serve.
What this accelerates in practice
The pattern is already supporting live use cases. One deployment pairs an operational document store with a graph ontology for risk intelligence, where approved risk events are registered on the knowledge graph together with their proposed relationships and supporting evidence, and the graph write is treated as an enrichment that can be disabled without ever threatening the system of record. Elsewhere the same tools serve exploratory work, letting analysts interrogate warehouse data through relationship-aware questions that would otherwise wait in a business intelligence backlog.
Neo4j supplies the structure, the Model Context Protocol supplies a uniform way to reach it, and the platform supplies the isolation and the guardrails that make it safe to hand to an autonomous agent. What used to be a bespoke integration project for every client and every data source is now configuration on a platform that already knows how to behave. That is what we mean when we describe our solution as an accelerator, and it is the same posture we apply to every capability we add. If you would like to see a knowledge graph built from your own data in a single working session, we would be glad to show you.
