Product Counsel - Product, Security and Privacy

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.

Easily build a knowledge graph from your existing documents with Document Intelligence. October 6, 2026 Today, Neo4j, Inc. is announcing the upcoming release to general availability (GA) of Document Intelligence in Neo4j AuraDB on the Free, Professional, and Business Critical tiers. With Document Intelligence, you can build a knowledge graph from existing documents, including plain text files, PDFs, and Microsoft Word files, without writing a single line of code. Documents that previously sat unused and unqueried can now be searched and acted upon. Documents hold the context behind many business decisions. Contracts describe obligations, reports record risks, and policy documents explain how a business operates. The connections between those documents matter. A question about a supplier may depend on a contract, an exception recorded elsewhere, and the products that the supplier provides. A knowledge graph makes those relationships explicit, so an application can follow them across documents and into the business data you already maintain. Getting started is easy. You describe what you want to extract, then refine the graph model through the canvas or built-in assistant. The resulting graph provides applications and AI agents with a cleaner signal than raw text alone, helping them retrieve related context with fewer tokens. When Neo4j, Inc. introduced Document Intelligence in preview, Neo4j, Inc. brought document processing, graph modeling, and extraction into the Aura console. GA builds on that foundation with support for larger collections, richer document content, and deeper integration with the graph you already have. Document Intelligence can now process hundreds of documents in managed background jobs, interpret information in images and tables, extend an existing graph model, and resolve extracted entities against data already in AuraDB. You can inspect and refine the graph model on the canvas or with the built-in assistant before import. What changes with the GA release? Together, these changes make document-to-graph extraction a repeatable workflow for larger, evolving collections. Larger collections and richer documents Document Intelligence now processes hundreds of documents per job. Imports run in the background, with job status available in the Aura console, and retries make longer-running jobs more resilient. A collection of contracts or reports can serve as the starting point for an entity graph that connects information across the entire collection. Neo4j, Inc. has also expanded the content that Document Intelligence can understand. Alongside text, it can interpret images and tables so their content can inform graph extraction. This brings more of a document into the resulting graph, including information that would otherwise remain inside visual elements. Build on the graph you already have New documents often add information about entities you already know. Document Intelligence can extend an existing graph model, resolve extracted entities against records already in AuraDB, and add new facts and relationships to those records. For example, contracts can add obligations to a supplier graph that already connects companies to the products they supply. Entity resolution determines when different mentions refer to the same real-world entity. Within each job, Document Intelligence normalizes entities, narrows the pairs worth comparing, scores the remaining candidates, and merges those above a similarity threshold. It then compares the results with nodes already in AuraDB. More control through the interactive assistant The assistant can generate and iteratively refine a graph model from a sample of your documents, start imports, and report job status. During the current session, it maintains the context of your conversation so you can develop the graph model through ongoing discussion. Descriptions and typed properties make the proposed model easier to review and more precise for extraction. Sampling across the collection helps the proposed model reflect recurring entities and relationships rather than the contents of a single document. You can ask the assistant to change a relationship, add information found in the sampled documents, or check whether the proposed graph model can answer your business questions. You can then inspect the result on the canvas. Conversation and direct editing work on the same graph model, keeping your extraction choices visible throughout the session. See Document Intelligence in action Here's a short walkthrough, from adding documents to starting an import. It shows the assistant proposing a graph model, helping you refine it on the canvas, and starting a background job that writes the resulting graph to AuraDB. You can follow the job's status in the Aura console while it runs. Connect the entity graph to its lexical graph Document Intelligence works in two stages. First, it samples the document collection to propose a graph model for you to review and refine. Once the model is ready, it processes the full collection, extracts entities and relationships, resolves repeated mentions, and writes the resulting graph to AuraDB. The result is one graph with connected entities and lexical layers. The lexical layer contains document and chunk nodes, with embeddings stored on chunks for similarity search. Extracted entities link back to the chunks in which they were found, while relationships between entities follow the graph model you reviewed. Applications can traverse those relationships and retrieve the source passages behind a result. Start building with your documents Document Intelligence is available in the Aura console across Free, Professional, and Business Critical. Bring your documents, describe the information you need, refine the proposed graph model, and review a sample of the extracted graph before starting the full import as a background job. The Document Intelligence documentation covers the supported sources and the workflow in detail. What comes next Next, Neo4j, Inc. is extending Document Intelligence beyond the Aura console with API, command-line, and Model Context Protocol access for pipelines and agents. Neo4j, Inc. is also exploring graph models that start from a business description, clearer job feedback and cancellation, more control over entity resolution, re-imports from updated sources, and visual tools for testing results. Broader enterprise deployment options, including customer cloud environments and self-managed Neo4j, are also on the roadmap. As you put Document Intelligence to work, use the Feedback button in the Aura console to tell Neo4j, Inc. what would make the biggest difference. Your feedback will help shape what Neo4j, Inc. build next