create-context-graph: a Neo4j Labs scaffolder for graph-backed agent memory
AI agents with graph based reasoning memory, scaffolded in seconds
At a glance
- What is it?
- The CLI generates a full FastAPI, Next.js and Neo4j application around a domain ontology in one command. It is a starting point, not a runtime, and the NAMS write path is narrower than the bolt one.
- Who is it for?
- Adopt it if you need a working reference application for graph-based agent memory and you are willing to read the generated code: the self-hosted path with --demo gives you a seeded Neo4j instance, a FastAPI backend and a Next.js frontend in one scaffold. Skip it if you already have a memory layer or a frontend you intend to keep, because you would be throwing most of the output away.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 10 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap it fills: agent memory that is a graph, not a vector index
Most agent memory examples stop at embedding a conversation and retrieving the nearest chunks. That gives you recall without structure: you can find a sentence you stored, but you cannot ask which entities it connects, or follow a relationship two hops out. create-context-graph takes the opposite position. It scaffolds an application whose memory is a Neo4j property graph, populated by automatic entity extraction during multi-turn conversation, and it wraps that in a working three-panel UI so you can see the graph grow as you talk to the agent.
The audience is narrow and specific. This is for engineers who have already decided that graph-shaped memory fits their problem (healthcare records, personal knowledge management, support tickets with dependencies) and who want the plumbing done. It is also for people evaluating neo4j-agent-memory v0.4 who want a runnable app rather than a library README. It is not for someone who wants a memory library to drop into an existing service. The output is a whole application, and adopting it means adopting that application's shape.
What the generator actually produces
The scaffold is a full-stack project, and the README is explicit about the parts. On the backend: a FastAPI service with an agent configured for the chosen domain, built on neo4j-agent-memory v0.4 for multi-turn conversation with automatic entity extraction. On the frontend: Next.js with Chakra UI v3, streaming chat over Server-Sent Events, a timeline that shows tool calls with live spinners, an interactive graph visualization with schema view, double-click expand, drag and zoom, a property panel, an entity detail panel, a document browser and a decision trace viewer.
Underneath, the generator writes a Neo4j schema with domain-specific constraints, indexes and GDS projections (self-hosted mode only), plus agent tools containing Cypher queries tailored to the industry. The wizard's own progress output lists six stages: generating the domain ontology, creating the project scaffold, configuring agent tools and system prompt, generating synthetic documents, writing fixture data, and bundling the project. That ordering matters. The ontology is generated first and everything downstream is derived from it, which is why a custom domain described in plain English can produce a coherent app rather than a generic template with renamed labels.
Two memory backends, and the write-path difference between them
The default backend is NAMS, Neo4j's hosted memory service. The self-hosted path (--self-hosted) uses a bolt Neo4j instance you run yourself, on Aura, Docker or a local install. The choice changes more than the connection string.
The README states plainly that the NAMS REST API has a narrower write surface than bolt Cypher. The CLI and the generated import_data.py work around this with what the documentation calls a hybrid write shape: relationships are encoded as ccg-edges YAML blocks inside each record rather than written as direct Cypher relationship statements. That is a real constraint, not a footnote. If your domain depends on precise control over relationship properties at write time, the NAMS path will not give you the same expressiveness as bolt, and you should read the generated import_data.py before assuming otherwise.
The trade-off runs the other way too. NAMS means no Neo4j to install or operate, and the graph starts empty and fills as you chat. Self-hosted means you own the database, and you get the demo fixtures: roughly 85 entities, 180 relationships, 25 documents and decision traces, loaded via make seed. If you want to see what a populated graph looks like before writing any data, self-hosted is the path that shows you.
Getting a project running: the commands that matter
The tool runs through uvx or npx, so there is no install step for the scaffolder itself. The NAMS path is the shortest:
uvx create-context-graph my-app --domain healthcare --framework strands --nams-api-key sk-nams-...
Then cd my-app, append ANTHROPIC_API_KEY to .env (the README notes Strands needs Anthropic), and run make install followed by make start. The app comes up on localhost:3000 with an empty graph.
The self-hosted path adds two steps:
uvx create-context-graph my-app --domain healthcare --framework pydanticai --self-hosted --demo
After make install, you run make docker-up (or make neo4j-start for a local install) and then make seed before make start. Prerequisites are Python 3.11+, Node.js 18+, Neo4j 5+ for self-hosted, and an LLM key for the agent: ANTHROPIC_API_KEY, OPENAI_API_KEY or GOOGLE_API_KEY depending on framework.
Two flags are worth knowing about. --with-mcp generates an MCP server config so Claude Desktop can query the same knowledge graph, and it works on either backend. --memory-llm and --memory-embedding let you point the memory layer's entity extraction at a different provider than the agent, for example --memory-llm bedrock/anthropic.claude-3-haiku-20240307-v1:0. The README notes that native adapters resolve first and everything else routes through LiteLLM. There is also a --custom-domain flag that takes a plain-English description instead of a preset domain, and --connector flags (github, slack, gmail, jira, notion, google calendar, salesforce, linear, google workspace, claude code, claude ai, chatgpt, local files) for importing real data.
Where the generated app will not fit
The most important limitation is stated by the project itself: this is a Neo4j Labs project. It is maintained by Neo4j staff and the community, but not officially supported, and the README directs you to GitHub Issues or the Neo4j Community Forum for help. That is a different support posture from a product, and it should shape how you plan around it. There are no releases retrieved for this repository, so you cannot pin to a versioned artifact in the usual way.
The second limitation is architectural. The generator produces a complete application with its own frontend, its own API surface and its own agent configuration. If you already have a chat interface, or a backend that owns your authentication and routing, most of the output is dead weight. You would be extracting the Neo4j schema and the agent tools and discarding the rest, at which point you are using the project as documentation rather than as a scaffold.
The third is the NAMS write surface described above. It is a genuine capability difference between the two backends, and it is the kind of thing that surfaces late, after you have built a domain model that assumes direct relationship writes.
There is also a domain-fit question. The demo fixtures are described as LLM-generated professional documents: discharge summaries, trade confirmations, lab reports. That is a useful demonstration, but synthetic data validates the pipeline, not the ontology. A generated ontology for a domain you have not modeled before is a starting hypothesis, and it will need review against how your data actually connects.
The alternative: wiring neo4j-agent-memory into your own service
The obvious alternative is to skip the scaffolder and use neo4j-agent-memory v0.4 directly, which is the library the generated backend is built on. The difference in approach is real. create-context-graph makes decisions for you: FastAPI for the backend, Next.js and Chakra UI v3 for the frontend, Server-Sent Events for streaming, a specific three-panel layout, a specific set of agent tools generated from an ontology. Using the library directly makes none of those decisions. You bring your own HTTP framework, your own UI, your own streaming transport, and you write the Cypher for your domain yourself.
That is more work and more control. If your application already has an agent loop, the scaffolder's value drops sharply, because the interesting part (entity extraction into a graph, multi-turn memory) is the library's job, not the generator's. The generator's contribution is the assembly: the ontology, the tools, the schema, the fixtures and the UI. If you want the assembly, use the generator. If you want the memory layer only, use the library and read the generated code as a reference implementation for how the pieces connect.
A second alternative is to stay with a vector store and skip graph memory entirely. That is the right call when your retrieval questions are similarity questions (find me passages like this one) rather than relationship questions (what connects this entity to that one, and through what). The project's premise is that the second kind of question matters for your domain. If it does not, the added schema and extraction cost buys you nothing.
Maintenance, licensing and what to check before you commit
The repository is Apache-2.0 licensed. That permissive licence covers the code the scaffolder generates, but it does not automatically cover what you connect it to: NAMS is a hosted service at memory.neo4jlabs.com with its own terms, and Neo4j itself has separate licensing depending on whether you run Community, Enterprise or Aura. The README does not address licence interaction between the generated code and these services, and this is not legal advice; if the distinction matters to your organisation, check it before you build on it.
On maintenance cost, the honest position is that the generated project is yours. The scaffolder runs once. After that you own a FastAPI app, a Next.js app and a Neo4j schema, and upgrading neo4j-agent-memory from v0.4 to a later version is your problem, not the generator's. Re-running the generator over an existing project is not described in the README as an upgrade path, so treat the output as a fork point rather than a managed dependency.
The last push recorded for the repository is 2026-09-06, which tells you the project is active but says nothing about how quickly the generated templates track changes in the underlying library. The thing to verify first is concrete: run the self-hosted --demo flow end to end, confirm make seed populates the graph you expect, then open the generated import_data.py and read the ccg-edges handling. If that write shape is compatible with the relationships your domain needs, the rest of the scaffold is a reasonable place to start.
Editorial conclusion
Adopt it if you need a working reference application for graph-based agent memory and you are willing to read the generated code: the self-hosted path with --demo gives you a seeded Neo4j instance, a FastAPI backend and a Next.js frontend in one scaffold. Skip it if you already have a memory layer or a frontend you intend to keep, because you would be throwing most of the output away. Before committing, run the self-hosted --demo flow once, then read the generated import_data.py to see how the ccg-edges YAML workaround shapes your writes.
Community notes