Back to portfolio
CORE PRIMITIVE · POSTGRES + D3

The Knowledge Graph

Most "AI memory" is a flat pile of embeddings. Mine is a graph. Services, agents, decisions, learnings, instructions, and memories themselves are first-class nodes; edges carry the relationship. When an agent asks "who depends on this service?" the graph has the answer. When I ask "why was this decided?" the graph has the citation. The graph is what makes the rest of the system thinkable.

Open the live graph →

Live view

Embedded D3. Same graph an agent sees when it calls kg_query.

— LIVE · pulled from PostgreSQL on every load —

Why a graph, not a vector store

Vector stores answer "what's similar?" Graphs answer "what's connected?" Both matter — and the graph is the harder one to fake. A vector store is a side effect of feeding text to an embedding model. A graph requires you to name relationships: this service depends on that one; this decision was driven by that learning; this instruction governs that service.

Naming relationships forces the system to be honest. You can't backfill a "depends-on" edge from a vector search. You have to know.

Memory Archive uses both: pgvector for similarity, the graph for connection. They're complementary, not redundant.

What's in the soup — node types

Service
Every public + internal service is a node. Holds port, owner agent, MA registration. :8000 career-bot, :5009 memory-archive, …
Agent
Talent Manager, Architecture, Database, Security, FinOps, Observability, Reliability, UX, Documentation, Continuous Learning, owner agents.
Decision
"We chose single-stage Opus over a chained pipeline." Each decision links to the agents who made it and the learnings that drove it.
Learning
"JSON pipeline must never be overwritten with markdown." Distilled into instructions over time. Decay-aware — old learnings can demote.
Instruction
Standing rules. Loaded into every session. Connected to the services they govern and the learnings they came from.
Memory
Captured context. Importance-weighted. Decays over time. Same node-type as the agent's working memory; not a separate cache.

Edge vocabulary — the small set that does most of the work

Eight verbs. Most relationships in the system can be expressed in these.

Service — owns → Agent
Service — depends-on → Service
Agent — produces → Decision
Agent — produces → Learning
Agent — captures → Memory
Service — governed-by → Instruction
Memory — informs → Decision
Learning — distills-to → Instruction

What it's already saved me from

A bad migration
Database Agent traversed the graph and found a service that read the column I was about to drop. BLOCK verdict. Saved me a Sunday-morning incident.
A boundary violation
Architecture Agent caught a cross-service import that would have created a dependency the graph didn't sanction. Required an explicit edit before merge.
Lost intent
"Why did we choose single-stage Opus?" — query the graph, find the decision node, follow the informs edge to the learning, follow the distills-to edge to the instruction. Three hops; full story.
Cost surprise
FinOps Agent uses the graph to know which service spawned a cost row. A spike in memory-archive calls is different from a spike in resume-builder — graph context, not just a number.

What it's becoming

The graph is the substrate. Two things on the roadmap that compound on it:

1. Cross-agent traversal at review time. Today the architecture agent and the database agent each traverse independently. Tomorrow a coordinating "mesh" agent traverses once, dispatches sub-agents in parallel, and synthesizes one verdict — with the path of which agreed and which dissented.

2. Decay edges. Edges currently live forever. Some shouldn't — a temporary dependency, a deprecated learning. Adding edge-level decay so the graph can shed irrelevance without me hand-editing.

Where it lives

Memory Archive holds the graph in PostgreSQL; D3 renders it; agents query it via MCP. Three pages, three angles on the same thing.

Live graph (full screen) → Memory Archive architecture Agent roster