EDN, Linked Data, and the Knowledge Graph CMS: Why Agentic Websites Need a Brain

The Problem with Flat Content

A WordPress wp_posts row knows three things: its title, its body, and its publish date. It doesn't know that the service it describes is offered at two locations. It doesn't know that a related FAQ answers the question a visitor actually asked. It doesn't know that the provider mentioned in paragraph three also has a bio page, or that the outcome described in bullet point five has a dedicated testimonial.

Flat content is legible to humans but opaque to machines. An AI agent asked to "update the hearing aids page to mention the new Louisville office" would need to understand the site's taxonomy, resolve entity relationships across tables, and know which other pages should cross-link. In a relational CMS, that context doesn't exist — it lives in the developer's head.

This is the fundamental gap: the data model of traditional CMS platforms does not encode the relationships that make content meaningful. And without those relationships, AI agents are flying blind.

What Personal Knowledge Tools Got Right

While the web publishing world was building bigger and bigger CMS dashboards, a parallel movement was happening in personal knowledge management. Tools like Obsidian, Logseq, Roam Research, and Athens converged on a set of primitives that turned out to be quietly revolutionary:

These tools were designed to help individuals think. But the underlying data structures — a knowledge graph with typed nodes, bidirectional edges, and block-level granularity — turn out to be exactly what agentic websites need. The same architecture that helps a researcher connect ideas across notes is what helps an AI agent reason about a business's content across an entire site.

EDN: The Data Format That Preserves Meaning

EDN (Extensible Data Notation) is a Clojure-derived data format that occupies a unique niche: it's as portable as JSON but richer in type semantics. Where JSON gives you strings, numbers, arrays, and objects, EDN adds keywords, sets, UUIDs, dates, and tagged literals as first-class types.

This matters for knowledge graphs because meaning survives the serialization boundary. Consider a page entity:

{:block/title "Hearing Aids"
 :block/tags #{:tag/Service :tag/WebPage}
 :block/uuid #uuid "a1b2c3d4-..."
 :property/slug "hearing-aids"
 :property/route "/hearing-aids/"
 :property/status :status/published}

In JSON, :tag/Service would be a string — indistinguishable from a label. In EDN, it's a namespaced keyword: a typed, internable symbol that an agent can match, filter, and reason about without parsing. Tags are sets (not arrays), so order doesn't matter and duplicates are impossible. UUIDs are actual UUIDs, not strings that happen to look like UUIDs.

EDN is the native export format of the knowledge graph databases used in personal knowledge tools. When we chose it as our interchange format, we weren't making an esoteric choice — we were preserving the semantic richness that makes the graph queryable by agents.

Bidirectional Links as the Fabric of Agentic Content

In the personal knowledge world, bidirectional links are a thinking tool. You write [[Hearing Loss]] in your note about tinnitus, and your hearing loss note automatically shows the backlink. The graph emerges from the act of writing.

For websites, the same mechanism creates something more powerful: a navigable content topology that agents can traverse. When every internal reference is a bidirectional edge in a graph, the site's structure becomes queryable:

• "Which services are offered at the Louisville location?" — Follow edges from the Location node to all Service nodes that reference it. No SQL JOIN, no taxonomy table — just graph traversal.
• "What content mentions Dr. Smith?" — Find all blocks that contain an entity reference to the Provider node. Bidirectional links mean the Provider page already has a list of every page that mentions it.
• "Generate the sitemap with relationship context" — Walk the graph. Every node knows its neighbors, its type, and its properties. An agent can describe the entire site topology without reading every page.

This is the difference between a website as a bag of pages and a website as a connected knowledge base. AI agents don't read pages sequentially — they need to traverse relationships. Bidirectional links make that traversal native, not reconstructed.

Datalog: Querying the Graph

Having a graph is only useful if you can ask it questions. Knowledge graph databases typically support Datalog, a declarative query language designed for graph traversal. Where SQL asks "which rows match these conditions?", Datalog asks "which entities satisfy these relationships?":

; Find all Services offered at Louisville
[:find ?title
 :where
 [?service :block/tags :tag/Service]
 [?service :block/title ?title]
 [?service :block/refs ?location]
 [?location :property/slug "louisville"]]

This query is readable, composable, and — critically — expressible by an AI agent. An LLM can generate Datalog queries from natural language far more reliably than it can generate complex SQL JOINs across a CMS's non-obvious schema. The query language matches the data's shape.

In our production system, this is exposed as a query bridge: an AI agent (or a human admin) can send Datalog queries to the graph and get structured results. This enables everything from "count all published Service pages" to "find pages with no outbound links" to "which entities are referenced by more than five other pages?".

The "Brand Brain" Pattern

We call a client's knowledge graph their Brand Brain. It's the same concept as a personal knowledge graph — Obsidian calls it a "vault", Logseq calls it a "graph" — but scoped to a business entity. A Brand Brain contains:

The Brand Brain isn't a database schema designed by a developer — it's a domain model that emerges from the content. Add a new entity type (say, "Insurance" or "Event") and it immediately participates in the graph's link structure. No migration, no schema change, no plugin.

From Knowledge Graph to Agentic Website

The architecture we've described — typed entities, bidirectional links, EDN interchange, Datalog queries — creates a content layer that AI agents can natively work with. Here's how it becomes a website:

1. 1. The graph is the source of truth — Structure, taxonomy, and entity relationships live in the knowledge graph. Each client gets their own graph, derived from their domain — complete isolation with no shared tables to partition.
2. 2. An editorial layer handles content — Editors write in markdown. They don't need to know HTML, the design system, or the graph's query language. A sidecar file stores their edits alongside the graph data, keeping the knowledge structure and the editorial prose separate but mergeable.
3. 3. AI generates the presentation — When content is queued for deployment, an AI agent receives the markdown, the page's metadata (type, route, description), and the full site's structural context from the graph. It generates design-system-compliant HTML — semantic, accessible, consistent. The graph gives the AI something a flat CMS never could: awareness of the entire site's topology while generating a single page.
4. 4. Edge delivery finishes the loop — The generated HTML is deployed to edge workers (we use Cloudflare Workers). API routes let the worker resolve any URL path to a page entity, fetch its blocks, and render the template. Content that lives in a graph, gets transformed by AI, and is served from 300+ edge locations worldwide.

The Model Context Protocol: Giving Agents Hands

Reading the graph is half the story. Agents also need to write. The Model Context Protocol (MCP) has emerged as a standard for giving AI models structured access to tools and data. In a knowledge graph CMS, MCP becomes the interface through which agents create and modify content:

• List entities by type — "Show me all Service pages" is a single tool call
• Inspect schema — The agent can discover what properties exist, what tags are defined, what the taxonomy looks like
• Create entities — Add a new page with typed properties and block content in one operation
• Query relationships — Datalog queries let agents ask arbitrary questions about the graph

The key insight: MCP + knowledge graph means the agent doesn't need to understand your CMS's proprietary API. It works with universal primitives — entities, properties, links, queries. The same agent that can reason about an Obsidian vault can reason about a brand's website, because the underlying data model is the same.

Knowledge Graph Visualization as an Editorial Tool

A side effect of graph-based content: you can see the site's structure. Force-directed visualizations render entities as nodes and relationships as edges. Clusters form around entity types — service pages gravitating toward the services they describe, locations grouping with the providers at those offices.

This isn't decorative. It's an editorial tool with real utility:

• Content gaps — A service page with no connected outcomes means missing social proof. An orphaned location means missing internal links.
• Structural balance — If one entity type dominates the graph visually, the site's content is unbalanced. Too many resources, not enough services? The graph shows it at a glance.
• Impact analysis — Before deleting or restructuring a page, see how many other pages reference it. In a flat CMS, this requires a full-text search and guessing.

Why Not Just Use WordPress with a Plugin?

Fair question. WordPress has taxonomy systems, custom post types, and relationship plugins like ACF or Pods. You can approximate a knowledge graph. But there are structural limitations:

The difference isn't about features you can bolt on — it's about what the native data model supports. A knowledge graph makes relationships first-class. A relational CMS makes tables first-class and requires you to reconstruct relationships via JOINs, plugins, and conventions.

DAPP: Our Production Implementation

DAPP (Digital Asset & Publishing Platform) is where these ideas run in production. It manages real client websites — not as a proof-of-concept, but as the daily publishing workflow for businesses. The architecture:

The system uses the same graph primitives as personal knowledge tools — bidirectional links, typed entities, block content, EDN interchange — but applied to multi-tenant website management. An agency managing 50 client sites has 50 independent Brand Brains, each one a self-contained knowledge graph that AI agents can reason about.

The Agentic Future of CMS

We think the CMS of the next decade will look less like a page editor and more like a knowledge base with agent access. The trajectory:

• Content as entities, not documents — A "page" is a node in a graph, with typed properties, relationships to other nodes, and block-level content that can be individually queried and composed.
• AI as a first-class collaborator — The graph gives agents the context they need: site topology, entity relationships, property schemas. Write markdown; the agent handles design, cross-linking, and consistency.
• EDN (or equivalent) as interchange — As AI agents move between systems, they need data formats that preserve semantic richness. JSON is the floor; typed, linked data formats are the ceiling.
• MCP as the standard interface — Instead of every CMS having a proprietary API, the Model Context Protocol gives agents a universal way to read, query, and write content — regardless of the underlying storage engine.
• Local-first, edge-delivered — Knowledge graphs backed by SQLite are portable, fast, and infrastructure-light. Edge workers serve the content globally. No running database servers to scale, no cloud vendor lock-in for the content itself.