AI-First Operations: Building a Knowledge Graph for Agentic Development

What if your AI development tools understood your product as well as your best engineer? Not just the code — the domain model, the business capabilities, the relationships between systems, the reasons behind architectural decisions?

That’s the question I set out to answer by building a custom MCP server backed by a Neo4j knowledge graph. The results have changed how I think about AI-assisted development — and about what “AI-first operations” actually means.

The problem: context is everything

I’m building a complex nonprofit platform — three integrated products (CRM, granting, reporting) with a shared core. The domain model includes perpetual themes with configurable hierarchies, subledger-first financials, event-driven cross-product integration, and multi-tenant operations across a dozen countries.

When I use AI to write code in this system, context is the bottleneck. The AI can write excellent code — if it understands the domain. But “understanding the domain” means knowing that a Theme in the granting system is perpetual (never recreated annually), that allocations are tracked via journal entries (not stored balances), that reporting receives spend data via one-way domain events, and that the results framework is configurable from 1 to 6 levels per tenant.

No AI can infer that from reading source files. The information exists in PRDs, glossary definitions, architectural decision records, and — most critically — in the relationships between these artifacts. A change to how allocations work affects the subledger, which affects reporting, which affects the data intake pipeline. Those connections live in peoples’ heads, not in the code.

The solution: a queryable knowledge graph

The MCP knowledge graph server gives AI agents structured access to the entire product domain. It’s built on three layers:

The graph (Neo4j). Nodes represent everything in the product domain: entities (Theme, Grant, Payment, EngagementHousehold), documentation (PRDs, glossary terms, architecture decisions), operations (workflows, integrations, API endpoints), and ontology (business capability categories). Relationships capture how these connect: DEFINED_IN, TRACES_TO, BELONGS_TO, DEPENDS_ON, PUBLISHES, CONSUMES.

The schema (three-label design). Every node has three labels: Category (Entity, Documentation, Analysis, Ontology, Operation), Domain (PlatformCore, Granting, Reporting, Vision2, CrossProduct), and Type (Theme, GrantMemo, Workflow, GlossaryTerm, etc.). This lets queries scope precisely: “show me all Entities in the Granting domain that PUBLISH events” returns exactly what you need without scanning the full graph.

The tools (20 MCP endpoints). Six query tools (entity discovery, impact analysis, dependency chains, cross-product tracing, coverage checks, search). Six mutation tools (create, update, delete, link, export). Three ontology tools (category browsing, impact by capability, classification). Three maintenance tools (validation, statistics, history). Two search tools (full-text and fuzzy).

What changes when AI can query the domain

The shift is from sequential file reading to structured domain queries. Here are examples from actual development sessions:

“What’s the impact of changing allocation logic?” Without the graph, answering this requires reading the allocation service, finding every caller, tracing through the event system, and checking which reporting components consume allocation data. With the graph: one impact analysis query returns every entity, workflow, and cross-product dependency affected by the change. The AI gets the full picture in one tool call.

“Which business capabilities don’t have test coverage?” The graph tracks business capabilities as an ontology layer — Financial, DonorManagement, ProgramManagement, etc. Cross-referencing capabilities against the test inventory reveals which critical capabilities have gaps. This is the kind of analysis that’s impossible from source code alone because it requires business context.

“Show me every entity that crosses product boundaries.” The cross-product tracing tool follows PUBLISHES and CONSUMES relationships across domain boundaries. It reveals that SpendActualsPublished events flow from Reporting to Granting, and ActivityStatusChanged flows the opposite direction. This dependency map is essential for making changes that don’t break cross-product integration.

Building the ingestion pipeline

The graph is only as good as what’s in it. The ingestion pipeline extracts structured data from three sources:

Glossary terms from a standardized markdown file. Each term gets a GlossaryTerm node with its definition, domain classification, and automatic links to entities that reference it.

Domain entities extracted from PRD markdown files. The pipeline parses PRD sections, identifies entity definitions and their properties, and creates Entity nodes with relationships to the PRD they’re defined in.

Workflows and stories from the project management system. Each workflow becomes a node with TRACES_TO relationships back to the PRD requirements it implements, and BELONGS_TO relationships to the business capability it serves.

The bidirectional linking is automatic: when a new entity is added, the server scans for glossary terms it might reference and creates links. When a story references a workflow, the traceability chain from requirement to implementation is maintained.

Toward AI-first operations

Building this knowledge graph revealed something I hadn’t expected: the graph isn’t just a development tool. It’s the beginning of what AI-first operations looks like.

Traditional operations rely on people holding context. The senior engineer who knows why the allocation system works the way it does. The product manager who remembers which customer requirement drove a specific design decision. The architect who can trace the implications of a change across the system.

When that context lives in a queryable graph, it’s no longer dependent on specific people being available. An AI agent can query it at 2 AM. A new team member can ask questions that would normally require months of context building. An automated system can check whether a proposed change violates architectural constraints without human review.

This isn’t hypothetical. It’s how I work on this product today. The AI doesn’t just write code — it understands the domain well enough to make architectural decisions that are consistent with the existing system. Not because it’s smart, but because it has structured access to the context it needs.

The three requirements for AI-first operations

Based on this experience, I believe AI-first operations requires three things:

Structured context. Raw documentation isn’t enough. The information needs to be organized in a way that supports the queries AI agents will make — impact analysis, dependency tracing, capability mapping. A knowledge graph is one approach; others might work for simpler domains. But “here are the docs” isn’t sufficient.

Domain-specific tools. Generic AI capabilities (read file, write file, search) aren’t enough for domain-rich work. The AI needs tools that speak the language of your domain — tools that know what a “Theme” is, that can trace allocation impacts, that can classify entities by business capability. MCP makes building these tools practical.

Continuous ingestion. The graph must stay current. If the PRDs change and the graph doesn’t, the AI makes decisions based on stale context. The ingestion pipeline needs to be part of the development workflow, not a separate maintenance task.

When these three elements are in place, something interesting happens: the AI becomes a genuine participant in the development process, not just a code generation tool. It can reason about the system, identify implications, and make recommendations that reflect real domain understanding.

That’s what AI-first operations means. Not “use AI for everything” — but “build the infrastructure that lets AI operate with full context.”