Open-source tools like Graphiti and Cognee, each with more than 29,000 GitHub stars, make building a context layer look like a weekend project. For a single narrow domain, it can be. AI engineer Paul Iusztin spent a year doing this and documented recurring mistakes once a graph serves multiple teams — a first-person account, not a hypothetical.
This guide covers the open-source building blocks, where DIY genuinely holds up, and the governance lifecycle most self-built context layers skip.
- Initial build is tractable. A narrow pilot takes weeks, not a multi-quarter program
- The build breaks into five parts. Unify, bootstrap, resolve, deliver, govern
- The honest cost lives in step five. Versioning, evals, and review, what every DIY tutorial skips
- Tooling maturity cuts both ways. 29,000-star repos lower the barrier and inherit fast-moving maintenance
Jump to: Why · Prerequisites · Steps · Pitfalls · Practices · FAQs
Time to complete: weeks for a narrow pilot; 6-12+ months ongoing to reach production-grade coverage. Difficulty level: Advanced. Tools needed: a graph database (Neo4j, FalkorDB, or Kuzu), an open-source framework (Graphiti, Cognee, or TrustGraph), an MCP-compatible delivery layer, and a storage layer such as Apache Iceberg.
Why would you build your own context layer?
Permalink to “Why would you build your own context layer?”Most enterprises already have the raw material scattered across 80-plus systems: SQL, BI, lineage, and docs. The plumbing looks solvable in isolation, so teams start here.
Open-source frameworks now handle much of the graph-construction work, and context engineering is a documented discipline. Anthropic’s engineering team frames it well: agents fail less because a model is weak, more because context is incomplete, stale, or contradictory.
Who should do this: a team with one stable domain and a small number of agents, willing to own platform engineering long-term.
| Signal | DIY works | DIY breaks down |
|---|---|---|
| Number of agents | 1-2, one team | 3 or more, cross-team |
| Definition stability | Stable for months | Drifts monthly as business changes |
| Governance need | None beyond the build team’s habits | Audit trail, rollback, and version history required |
| Delivery surface | One agent runtime | Multiple agent runtimes and frameworks |
| Ownership | Whoever built it, informally | A named, funded, permanent owner |
What do you need before you start building a context layer?
Permalink to “What do you need before you start building a context layer?”Skipping these checks turns a promising pilot into an abandoned repo within six months.
Organizational: tolerance for an open-ended maintenance budget; a single owning team, not a committee; agreement on which domain goes first.
Technical: access to source systems’ metadata across SQL, BI, lineage, docs; a graph database already chosen; an MCP-compatible delivery mechanism planned; a versioning layer for the context repository.
Team: a platform or ML engineer at 60-80% time for graph construction, a domain expert at 20-30% for entity resolution, and a named owner assigned after launch, distinct from the build team. Skip that role and you get manual context work nobody owns — a stopgap, not a context layer.
Time: 2-4 weeks of planning, 6-10 weeks of initial build, plus indefinite ongoing operation. A context layer for AI agents includes this operational layer; a vector database alone does not.
Get the AI Context Stack Two-Pager
See where a context layer sits in the AI stack before you build one from scratch.
Get the Two-Pager
Step 1: Unify context across your systems
Permalink to “Step 1: Unify context across your systems”This step pulls context out of scattered systems into one living structure, the foundation every later step assumes. In 2-3 weeks: inventory every system holding context (SQL, BI, lineage, docs) and confirm access; choose a storage layer, such as Apache Iceberg, so the graph isn’t locked to one framework; and define the single domain in scope for version one.
Skip this step and step three’s entity resolution has nothing coherent to resolve against — also what separates a real context layer from a data catalog with a search box: a catalog lists what exists, a context layer connects what it means.
Validation checklist: systems inventoried, access confirmed, storage layer chosen, domain boundary written down.
Step 2: Bootstrap your ontology from existing signals
Permalink to “Step 2: Bootstrap your ontology from existing signals”Here, you mine SQL, BI semantics, lineage, and docs to generate a first-draft ontology instead of hand-authoring every definition. In 3-4 weeks: start from a minimal model (Iusztin used Person/Object/Location/Event/Organization) and extend only on real collisions; pick your framework deliberately; and budget for a stronger model, since smaller LLMs often fail Graphiti’s structured-output requirements.
Per Paul Iusztin (2026), hand-authoring an ontology upfront is the single most-cited practitioner mistake, freezing projects for months.
| Tool | Stars | License | Handles | You still own |
|---|---|---|---|---|
| Graphiti | 29.1k | Apache-2.0 | Temporal context graph construction | Operating your own graph database |
| Cognee | 29.2k | Apache-2.0 | Vector and graph reasoning combined | A large, fast-moving codebase (8,900+ commits) |
| TrustGraph | 632+ | Open source | Kubernetes-native context delivery | Real infrastructure operations, not a library |
More: knowledge graph tools compared, how to build a knowledge graph for AI agents, how to build a context graph for enterprise AI. Atlan’s Context Bootstrapping mines these signals automatically.
Validation checklist: minimal ontology drafted, framework chosen, first-draft graph populated from a real source.
Step 3: Resolve entities and certify definitions
Permalink to “Step 3: Resolve entities and certify definitions”Conflicting definitions and duplicate entities get resolved here, so the graph reflects one certified reality — a finer distinction than a context graph vs knowledge graph draws. Over 2-4 weeks, ongoing after launch: set explicit merge thresholds (0.95+ auto-merge, 0.85-0.95 human review, below 0.85 becomes a new node) so “Apple the company” and “Apple the fruit” don’t merge by accident, then route ambiguous cases to a domain expert.
Naming is not identity. Confusing entity resolution with deduplication is Iusztin’s third documented mistake, corrupting retrieval silently rather than failing loudly. Miguel Otero Pedrido describes the related failure: vector-only similarity has no temporal awareness, so a user moves cities and the agent still recommends restaurants in the old one.
Validation checklist: merge thresholds documented, a human-review queue exists, at least one deliberately ambiguous test case resolved correctly.
Step 4: Deliver context to your agents at runtime
Permalink to “Step 4: Deliver context to your agents at runtime”Once certified, the graph needs to reach agents through a standard interface, not a one-off integration per framework. In 2-3 weeks: adopt the Model Context Protocol as the delivery standard so new runtimes don’t each need custom code; expose SQL or API access for non-MCP-native tools; and test with at least two agent runtimes.
Building delivery against a single framework recreates the lock-in problem this exercise was meant to avoid — a standard layer also lets enterprise memory and enterprise skills reach agents through one interface.
Validation checklist: MCP endpoint live, two agent runtimes tested, SQL or API fallback confirmed. The versioned structure behind this is what a context repository for AI agents is built to hold.
Assess Your Context Maturity
Get a quick read on how close your setup is to a governed, multi-agent context layer.
Take the AssessmentStep 5: Build the governance lifecycle that keeps it from rotting
Permalink to “Step 5: Build the governance lifecycle that keeps it from rotting”This step keeps the graph accurate as agents, teams, and data sources multiply, the ongoing cycle most DIY tutorials skip, with no end date: version every change to the repository, the discipline context versioning for AI agents is built around; build eval suites from real production queries, per context quality testing for AI agents; and require human approval before anything becomes canonical, with a tested rollback path.
Self-built context layers are common, not a fringe case. Context drift is what happens when nobody owns this step.
| Stage | DIY builds by hand | Governed platform automates |
|---|---|---|
| Build | Custom scripts per source | AI bootstraps from the data graph, dashboards, SQL, metadata |
| Test | Hand-written eval sets, manually maintained | Production queries become eval suites automatically |
| Review | Ad hoc Slack threads, tribal review | Structured review of AI drafts and failed eval traces |
| Approve | Whoever remembers to check before shipping | A named owner signs off before anything becomes canonical |
| Deploy | A custom deploy script per environment | Versioned MCP delivery with staged rollout and rollback |
| Learn | Manual notes on what went wrong | Production traces feed back into the repository automatically |
The context engineering framework behind this table is what a governed platform runs by default.
Validation checklist: versioning in place, at least one automated eval suite running, a named human owner for approvals, a rollback path tested at least once.
What goes wrong when teams build a context layer in-house?
Permalink to “What goes wrong when teams build a context layer in-house?”The mistakes below are documented, not hypothetical — drawn from practitioners who built these and kept them running.
1. Reaching for a full agent framework too early
Permalink to “1. Reaching for a full agent framework too early”Frameworks like LangGraph and CrewAI look fastest until ontology constraints force you to fight the framework instead of the problem. Start with direct graph queries and adopt a framework only when a constraint forces it.
2. Over-designing the ontology upfront
Permalink to “2. Over-designing the ontology upfront”Modeling every edge case upfront freezes projects for months. Start minimal, extend only on real collisions, and treat “complete” as a backlog item, not a blocker.
3. Confusing deduplication with entity resolution
Permalink to “3. Confusing deduplication with entity resolution”Naming similarity is not identity. Use explicit merge thresholds with a human-review band and audit for silent bad merges — the same failure mode behind multi-agent memory silos, why AI agents forget things it should have retained, and broken GraphRAG retrieval.
4. A dependency you rely on goes unmaintained under you
Permalink to “4. A dependency you rely on goes unmaintained under you”The DIY tooling ecosystem moves fast: Graphiti’s own Kuzu graph-database support is already deprecated upstream, a live example, not hypothetical. Pin dependencies deliberately and treat this as a scheduled governance event, not an emergency.
A fair counterpoint: in one Hacker News discussion, a practitioner called knowledge graphs “brittle, hard to maintain, constantly changing,” preferring to pass context directly into a model’s context window, real frustration with construction, not a reason to skip governance. How to choose an AI agent memory architecture is a reasonable next read.
What are the best practices if you’re building a context layer yourself?
Permalink to “What are the best practices if you’re building a context layer yourself?”These five practices separate a context layer that survives production from one that quietly stops being trusted.
Treat the open-source repo as a starting point, not a finished product. Atlan’s internal analysis, 2026, found 86% of open-source agent repos carry serious bugs, mostly access-control issues, not prompt injection. A security review before production is not optional.
Pick the delivery standard before the framework. Committing to MCP first, per step four, avoids re-locking context to one runtime later.
Version the context repository separately from application code. The repository is the asset that drifts; the code around it is not.
Build the eval suite before you need it. Start from agent context layer tools compared or the tools directory.
Name a permanent owner before you start. A scrappy fix, a manually maintained skill file, a weekly script, works until the builder moves on, and the team concludes a governed platform would have cost less than the labor sunk in. A memory layer built the same way inherits the identical risk.
Real stories from real customers: Governed context at enterprise scale
Permalink to “Real stories from real customers: Governed context at enterprise scale”"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server…as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
— Joe DosSantos, VP of Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
— Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
Watch Atlan in Action: Live Context Layer Demos
See the build, test, review, approve, deploy, and learn cycle running against real questions.
Watch the Demo SeriesHow a governed platform picks up where DIY breaks down
Permalink to “How a governed platform picks up where DIY breaks down”Step 5’s lifecycle and step 3’s entity resolution keep recurring by hand: a definition drifts, a new agent onboards, a dependency goes unmaintained, turning a pilot into a permanent maintenance line item.
Atlan’s Context Engineering Studio runs step five’s build, test, review, approve, deploy, and learn cycle as one governed lifecycle, not five scripts to remember. It bootstraps context from the data graph, dashboards, SQL, and metadata into versioned repositories (steps one and two), turns production queries into eval suites automatically (step five), and ships approved context to agents via MCP with staged rollout (step four).
This isn’t an argument that DIY never works. A scoped, single-domain build using Graphiti or Cognee is reasonable for a small team. The distinction: once context must be shared across teams and agents, you’re no longer building a graph, you’re operating a platform.
If you built it, step five is the ongoing work now, measured by drift caught before users hit it. If DIY doesn’t fit, context layer evaluation criteria is the practical next read. For the wider stack: what is the enterprise context layer and what harness engineering covers.
FAQs about building your own context layer
Permalink to “FAQs about building your own context layer”1. Can you build a context layer yourself without buying a platform?
Permalink to “1. Can you build a context layer yourself without buying a platform?”Yes, for a narrow scope: Graphiti and Cognee make a single-domain pilot achievable with a platform engineer and domain expert. It’s harder across multiple teams and agents.
2. How long does it take to build a context layer in-house?
Permalink to “2. How long does it take to build a context layer in-house?”A narrow pilot takes weeks: 2-4 for planning, 6-10 for build. Production-grade coverage takes 6-12 months, and governance never fully ends.
3. What open-source tools exist for building a knowledge graph for AI agents?
Permalink to “3. What open-source tools exist for building a knowledge graph for AI agents?”Graphiti and Cognee are the largest, each with 29,000+ GitHub stars. TrustGraph is Kubernetes-native; Neo4j Labs offers a scaffolding CLI. Each requires your own graph database.
4. What are the most common mistakes when building AI agent memory with knowledge graphs?
Permalink to “4. What are the most common mistakes when building AI agent memory with knowledge graphs?”Reaching for a full agent framework before you need multi-hop traversal, over-designing the ontology upfront, and confusing entity resolution with simple deduplication are the three most documented mistakes.
5. Should you build or buy a context layer for your AI agents?
Permalink to “5. Should you build or buy a context layer for your AI agents?”Build if your scope is one stable domain and a small number of agents. Buy once context spans teams, needs per-user governance, and requires testing before release.
6. What does a context layer need to work across multiple AI agents?
Permalink to “6. What does a context layer need to work across multiple AI agents?”A standard delivery protocol so runtimes don’t need custom integration code, certified definitions every agent reads from one source, and access control scoped per agent, not a prompt.
7. How do you keep a knowledge graph or context layer up to date over time?
Permalink to “7. How do you keep a knowledge graph or context layer up to date over time?”Version every change to the context repository, not just the code. Build eval suites from production queries to catch stale definitions, and require a named owner to approve changes.
8. What’s the difference between a context layer and RAG?
Permalink to “8. What’s the difference between a context layer and RAG?”RAG is a retrieval technique: fetch relevant chunks, pass them to a model. A context layer is the governed infrastructure underneath it — certified definitions, entity resolution, lineage, and access policy that any retrieval method, RAG included, draws from to avoid confidently answering from stale or conflicting facts.
Sources
Permalink to “Sources”- Anthropic Engineering, “Effective Context Engineering for AI Agents.” 2025. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
- Apache Software Foundation, “Apache Iceberg, Official Documentation.” https://iceberg.apache.org/
- Paul Iusztin, “I spent a year building agent memory on knowledge graphs. Here are my 5 mistakes.” Hacker News, 2026. https://news.ycombinator.com/item?id=48337689
- Miguel Otero Pedrido, “Building Agent Memory with Knowledge Graphs.” The Neural Maze, 2026. https://theneuralmaze.substack.com/p/building-agent-memory-with-knowledge
- Model Context Protocol, Official Documentation. https://modelcontextprotocol.io/
- Graphiti, GitHub (getzep). https://github.com/getzep/graphiti
- Cognee, GitHub (topoteretes). https://github.com/topoteretes/cognee
- TrustGraph, GitHub. https://github.com/trustgraph-ai/trustgraph
- “What are people’s experiences with knowledge graphs?” Hacker News discussion. https://news.ycombinator.com/item?id=43084073
