Neo4j Context Engine gives AI agents a shared knowledge layer, 6-layer business ontology, and graph-native memory. by Harold Fritts on October 20, 2026 Neo4j announced the Neo4j Context Engine today, a product built to give AI agents a shared, reusable knowledge layer for reasoning over enterprise data. The problem it targets is one most agent deployments hit early: an agent does not know what "customer," "account," "supplier," or "risk" means inside a particular company, because that meaning is scattered across databases, applications, documentation, and individual AI implementations. The Context Engine is available to enterprises now, and Neo4j is taking applications for design partners. "Modeling relationships, and being able to show exactly why and how those relationships exist, is absolutely essential to solving the problem of context for AI. All the other options are a band-aid on the problem that breaks as AI agents grow in complexity and system access requirements," said Sudhir Hasbe, president of technology and chief product officer at Neo4j. 6-Layer business ontology. The Context Engine centers on a predefined 6-layer graph model that maps an organization, its business processes, its data, and its AI assets into Neo4j. Neo4j built the model from patterns across hundreds of enterprise customer deployments. The ontology connects physical data sources directly to business logic, so AI and other systems can make decisions with the surrounding context attached, and it serves both design-time architecture work and run-time execution. The Context Build and Runtime component builds the ontology from existing data sources such as Databricks and Snowflake, and exposes it to AI orchestration layers that drive process-guided agents or conversational analytics agents. Teams create and operate the semantic layer through headless execution, command-line tools, or Python packages. It works across existing data platforms, data catalogs, and enterprise storage systems, carries built-in change management, and uses GraphRAG retrievers to pull context out of the semantic layer. Context Studio governance and persistent memory layer. Context Studio is the control plane for the ontology. It gives teams one place to manage and monitor the environment, a visual builder for the business ontology and the workflows that run on it, and setup tooling for AI agents, Model Context Protocol (MCP) servers, and developer tools. Context Memory is a graph-native memory layer that gives agents persistent, structured memory across short-term, long-term, and reasoning memory, along with skill distillation. It logs agent reasoning and operational paths as a permanent record of enterprise experience, runs graph algorithms over past interactions to condense repeated events into reusable knowledge, and feeds what it learns back into the core system to improve agent reasoning and accuracy over time. Neo4j frames the launch around a third consumer of enterprise data. Humans have understood the relationships between data intuitively and institutionally, and applications have done the same through hardcoded logic. AI agents are the third consumer, and the company's argument is that inferring relationships is no longer enough as agentic use cases grow more complex; the relationships have to be represented explicitly, which is what a graph does natively. Engage with StorageReview Harold Fritts. I have been in the tech industry since IBM created Selectric. My background, though, is writing. So I decided to get out of the pre-sales biz and return to my roots, doing a bit of writing but still being involved in technology.

Graph embeddings, one line of code away. Senior Product Manager, Graph Analytics, Neo4j October 16, 2026 A single account on its own tells you very little. But look at who it sends money to, who those accounts send money to, and suddenly you have got a lot to work with. That's the idea behind graph embeddings: take a node and everything around it, and compress that graph structure into a vector. Nodes with similar surroundings end up with similar vectors. You will also see these called node embeddings, the name Neo4j, Inc. use in the docs, because every node gets a vector of its own. Over the last few years, embeddings have been the fastest-growing use case for Neo4j Graph Data Science (GDS), its graph analytics and machine learning library, and Neo4j, Inc. is not surprised. Once every node is a vector, a lot of hard problems turn into ordinary ones: * A fraud team can flag accounts that look like known fraudsters. * A retailer can recommend what similar customers bought. * An analyst can segment customers by how they connect to everyone else, and a data scientist can feed the vectors to a standard model to predict churn. As more teams build AI agents on top of knowledge graphs, there is a newer one too: text embeddings tell an agent what things say, graph embeddings tell it how things connect, and retrieval that uses both can find related entities that text alone would miss. Previously, creating embeddings was a job for data scientists. Just to get started, you would first have to climb a hill of concepts: which model fits my graph, which configuration fits my use case, what does this parameter even do? Plenty of teams have made that climb, trying out models and tuning configuration until the embeddings looked right. It works, but it is a lot to ask before you see a first result. Compare that with text embeddings. You make one call, get vectors back in a few lines of code, and never need to know what happens under the hood. That bar has been set, and Neo4j, Inc. think graphs deserve the same treatment. One line, nothing to configure. Today, Neo4j, Inc. is excited to release, in preview, a new Embeddings API in the GDS Python client (version 2.2 or later), built for Aura Graph Analytics: gds.embedding.create(G) That is the whole call. G is your graph, loaded into a session of Aura Graph Analytics, the on-demand environment where GDS runs in Aura, and create gives every node in it an embedding. Under the hood, it runs FastRP, a fast and highly scalable algorithm, with defaults Neo4j, Inc. chose so you don't have to, and in most cases they work well. That means you can start without knowing how the algorithm works or how to tune it, and spend your time on what the embeddings are for, not on how to produce them. When you do want the dials, they are there. You can set the embedding size and other FastRP settings, name the property the embeddings are stored in, embed only some node labels or relationship types, and fix a random_seed to get reproducible results. What happens to your graph. Embeddings are added to your in-memory graph as a new node property, called embedding unless you choose another name, and nothing is written to your database. From there, the vectors are yours: stream them into pandas, hand them to another algorithm in the same session (kNN to find similar nodes, k-means to cluster them), or, if your session is attached to a database, write them back to it. Here it is in context, starting with the graph itself (accounts and the transfers between them): G, result = gds.graph.project.native("transfers", ["Account"], ["TRANSFERRED_TO"]) gds.embedding.create(G) And here is the same call with a few of the dials turned: an embedding size of 256, a separate property name (since the default embedding already exists now on this graph), and a fixed seed for reproducible results: gds.embedding.create( G, embedding_dimension=256, mutate_property="embedding_256", # a new name since "embedding" already exists on G random_seed=42,) create fails if the graph already has a property with the same name, so existing embeddings are never overwritten by accident. While you are experimenting, give each set of embeddings its own property name, as in the example above, so you can compare them. In production, in scheduled pipelines, or in notebook cells you want to re-run, drop the property first. With fail_if_missing=False, that step is safe: if the property doesn't exist yet, the line is simply ignored. gds.graph.node_properties.drop(G, ["embedding"], fail_if_missing=False) gds.embedding.create(G) When the default isn't enough. Of course, a general-purpose default only goes so far. It captures where each node sits in the overall shape of the graph, and that is all it looks at: whatever is stored on your nodes plays no part. If your accounts contain properties that matter, or your analysts have already classified some of them, you will want embeddings shaped by those properties. That is what gds.embedding.train is for. It trains a GraphSAGE model that learns from node properties and from the classes you already know. Once you have a model, pass its name to create and you are back to a single call. In this example, every account also carries a numeric risk_class and a features vector, so the projection brings them along: G, result = gds.graph.project.native( "labeled-transfers", ["Account"], ["TRANSFERRED_TO"], node_properties=["risk_class", "features"],) With those properties in the graph, training takes one call. You point it at the property that holds the classes you already know (target_label and target_property), the properties the model should learn from (feature_properties), and the name to save the model under: gds.embedding.train( G, model_name="account-risk-encoder", target_label="Account", target_property="risk_class", feature_properties=["features"],) Behind the scenes, a small classifier trained on your known classes teaches the encoder which patterns matter. If the defaults aren't enough, you can tune both the encoder and the classifier, along with the number of epochs and the batch size. What you keep is the encoder. Pass its name to create, and every node gets an embedding shaped by your classes and properties: gds.embedding.create( G, graph_encoder="account-risk-encoder", mutate_property="embedding_tuned", feature_properties=["features"],) One word of caution when you evaluate the results: the model has already seen your training examples, so judge it on nodes it did not train on. A model trained this way is a regular Aura Graph Analytics model, like any other you would train in a session. You can for example store it using gds.model.store to keep it in your project's model catalog, so a later session can use it by name. Try it today. Aura Graph Analytics is available on the AuraDB Free tier, so you can see this in action without paying anything. And your data does not have to live in Neo4j. Load nodes and relationships from a data warehouse, Databricks, or a CSV file into pandas DataFrames, and gds.graph.construct turns them into a graph in a standalone session. The Embeddings API documentation has the full parameter reference and a quickstart that runs on Cora, a small citation graph that ships with its GDS Python client, so you can try it before loading anything of your own. Both endpoints are in preview, which means they may change as Neo4j, Inc. learn from how you use them. The Embeddings API is available only in Aura Graph Analytics, with GDS Python client 2.2 or later. What's next. This is a first step. Neo4j, Inc. plan to keep adding to the API, with more capabilities for generating embeddings and for putting them to work once you have them, and to bring it to its Cypher API too, if Python isn't your cup of tea. Because this is a preview, your feedback shapes what comes next: tell Neo4j, Inc. which graphs you embedded, what worked, and what you wished it did. Reach out to Neo4j, Inc. on the Neo4j Community Forum or at [email protected].

Wherever you're building agents, Neo4j is already there. October 6, 2026 Want to deploy a fully functional AI agent quickly? Skip starting from scratch and tap into a repeatable infrastructure, one where context, memory, and reasoning map to your existing stack. Neo4j has built a broad library of documented, working integrations across the agent frameworks agent platforms you're already building on: AWS, Google, Microsoft, Vercel, Salesforce, and more. With architecture guidance, security setup, and code you can run today, you can get your agents pulling work from the same knowledge layer. An agent is only as good as what it can retrieve, remember, and what context it can get from tools, memory or other agents in a workflow. Get those parts wrong, and the rest of the agentic workflow doesn't matter, no matter how well you built it. Every team building an agent independently solves the same problems: how do I get a knowledge graph talking to LangGraph, AWS Strands, or Salesforce Agentforce, and how do I get an agent's memory to survive past a single session and be shared in a larger agentic system? Neo4j, Inc. did the work figuring out how the platforms, frameworks and APIs fit together, so you don't have to. These are published as Neo4j Labs integrations, so you get documented patterns, working code, and the architecture guidance to connect your agents to the same graph they can query, act on, and remember from, wherever you're already building. The question Neo4j, Inc. kept hearing. Neo4j, Inc. kept hearing different versions of the same question, just with a different framework name attached. How do I connect Neo4j to this? So Neo4j, Inc. answered it for each framework, platform, or tool that developers keep asking about. Everything from native model access and MCP servers, to GenAI frameworks. The point is to give your agents correct, graph-powered infrastructure built using the frameworks and platforms you've already chosen, so you spend your time on the agent itself instead of the wiring underneath it. Neo4j AI integrations provide pre-built, production-ready graph solutions across leading AI frameworks, giving your agents the persistent memory, contextual retrieval, and cross-platform interoperability required to deliver real business impact out of the box. What an agent actually needs from a graph. Strip away the framework-specific detail, and every agent benefits from the same two things from Neo4j: a way to retrieve and act on graph data, and a way to remember and learn. Retrieval and action is the essence of the action phase of the agent loop. An agent uses tools to query the graph, updates it, and reaches out to the APIs and databases it needs to get the job done. Memory improves planning and reasoning before taking action, and gets updated and consolidated in the observation phase. Teams tend to underestimate the memory part. Memory is more than a buzzword, it's an architectural must for any agentic workflow that has multiple agents that need to work in sync with each other and you need those agents to perform accurately. Neo4j Agent Memory adds short-term, long-term, and reasoning memory, so an agent keeps context across a conversation and gets sharper the more it works, instead of forgetting everything between sessions. That memory lives as a connected graph of typed, resolved entities, not scattered mentions: three references to the same customer collapse into one node, with facts attached to it directly. Reasoning memory goes further, storing the agent's decisions alongside the evidence behind them, so any agent with access to the graph can see why a past decision was made and build on it instead of starting cold. You can wire this in through whichever route fits your stack: * The official Neo4j MCP server, running locally or hosted * Neo4j drivers, if you want a custom connection in custom tools * Aura Agents MCP * Neo4j Agent Memory and the Neo4j Agent Memory Service (NAMS) for the memory layer specifically. A few of its favorite integrations to get started with. AWS.AWS Strands and AgentCore with a Neo4j MCP Server is making your AI agents significantly more efficient, reliable, and capable of distilling real-time learnings into long-term, transferable knowledge.By leveraging AgentCore Memory (or Neo4j Agent Memory for direct graph visualization), agents capture context, retain past outcomes, and convert experience into structured domain intelligence. While this enables seamless cross-agent handoffs, the broader advantage is continuous agent evolution: learning what works, reducing redundant computation, and sharing intelligence across your entire agent ecosystem. The setup guide is ready, walking you through connecting the AWS AgentCore Gateway to external Neo4j MCP servers hosted on AWS Fargate. Google. ADK and Gemini Enterprise integrations let an agent reason over your graph before it acts, and Genkit gives you a direct path from Google's developer tooling into Neo4j. For example, a supply chain agent built this way can trace a part shortage through complex supplier relationships and dependent orders, then recommend a solution that optimizes the entire network rather than just fixing a single broken link. Here's an ADK agent wired up with both the MCP toolset for querying the graph and a memory tool for recalling past sessions: from google.adk import Agent from google.adk.tools.mcp_tool import McpToolset, StreamableHTTPConnectionParams from google.adk.tools.preload_memory_tool import PreloadMemoryTool mcp_tools = McpToolset( connection_params=StreamableHTTPConnectionParams(url="https://your-instance/mcp"), tool_filter=["get-schema", "read-cypher"],) agent = Agent( model="gemini-3-flash", instruction="You are a supply chain research assistant.", tools=[mcp_tools, PreloadMemoryTool,) Vercel. The AI SDK integration turns Neo4j Agent Memory into a memory provider you can drop into an existing app, with NAMS Chat as a working example of what that looks like end to end. That's a natural fit for a customer-facing assistant that needs to remember a person's preferences and past requests across visits, not just within one chat session. Here's how the MCP client hands its tools straight to a single generateText call: import {generateText, stepCountIs} from 'ai'; import {createMCPClient} from '@ai-sdk/mcp'; const mcpClient = await createMCPClient({ transport: {type: 'http', url: 'https://your-instance/mcp'},}); const {text} = await generateText({ model, prompt: 'What did this customer ask about last time?', tools: await mcpClient.tools, stopWhen: stepCountIs(10),}); Salesforce Agentforce is worth a mention too. Three separate integrations ground Agentforce agents in Neo4j knowledge graphs. A native MCP client for grounding and multi-agent setups, with External Service Actions and Apex Actions available when you need a fully declarative path or full custom control, alongside a direct path to durable memory through Neo4j Agent Memory. This means that a sales support agent built this way can pull account history, relationship context, and open opportunities straight from the graph, then carry that context into the next conversation instead of starting the research over. Every framework and platform Neo4j, Inc. support lives on the agent frameworks and agent platforms pages, and the code behind all of it sits in one place: the neo4j-agent-integrations repo on GitHub. Built to run. Each integration comes ready for production, complete with platform security, straightforward deployment steps, and pre-launch tests. If you're evaluating what it takes to build this, the heavy lifting is already done. And Neo4j Agent Memory runs through nearly all of them, so no matter if you are using one integration or multiple, all agents are pulling from and contributing to the same memory. What's next. Neo4j, Inc. is not stopping here, and CrewAI and Haystack 3.0 are next on the integration roadmap, since Neo4j Agent Memory already gives CrewAI crews shared, persistent memory today and what's coming next is the same architecture guidance and runnable code this launch gives every other framework. Haystack support already exists too, through the neo4j-haystack document store, but Haystack 3.0 shipped real breaking changes, including a leaner core, a merged pipeline class, and a new agent hooks system. This post also kicks off a series that goes deeper into the integrations you just read about here. Each post takes one framework or platform from this list and walks through the full implementation, the specific decision points, MCP versus drivers, self-hosted memory versus NAMS, and the trade-offs that come with each choice, in more detail than a post like this one can cover. Ready to get started? * Pick your integration: Browse the neo4j-agent-integrations repo, find the framework or platform that matches your stack, and start from working code. * Read Agent Platform documentation: Full architecture guidance, security setup, and integration details for whichever route you pick. * Ask the community: Run into something unexpected? The Neo4j Community forum is a good place to start.