From Theory to Proof: 9 Days With a Semantic Knowledge System in Production

Nine days ago, I published a post about building a semantic knowledge system — a pgvector-backed memory layer that gives every AI agent I work with persistent, searchable context across all my repositories. The architecture was clean. The idea was sound. But it was still mostly a promise.

Nine days later, I have the receipts.

In just over a week, this system powered a volume of infrastructure work that would normally take months of careful, context-heavy manual effort. Not because the AI agents got smarter — but because they never forgot anything.

Here’s what happened.

The Setup: A Semantic Knowledge System in Production

The original post described a system with three parts: an ingestion pipeline that stores code and docs as vector embeddings, an MCP server that exposes semantic search as tools, and a session workflow that keeps it all current.

Since then, two things evolved. First, I expanded the MCP integration beyond Claude Code. Claude Desktop and OpenAI’s Codex CLI now both connect to the same pgvector database through the same MCP tools. This means I can switch between agents — or run them in parallel — and they all share the same institutional memory. Second, the session logs themselves became a primary knowledge source. Every AI session I run generates a dated markdown document cataloging what happened: what changed, what decisions were made, what was deferred. Those logs get ingested into pgvector alongside the code. The result is that when an agent starts a new session, it can search not just the code but the reasoning behind the code.

That second point turned out to matter more than I expected.

Infrastructure Migration: Moving Without Breaking

The first real test was a VM migration. I needed to move my Docker-based websites and NGINX reverse proxy configurations from legacy infrastructure to new virtual machines. This is the kind of work that typically involves a lot of careful note-taking: which containers run where, what environment variables are set, what depends on what, what order things need to come up in.

I didn’t take any notes. The knowledge system took them for me.

Each session — tearing down old containers, standing up new ones, reconfiguring NGINX, verifying DNS — was logged, committed, and ingested. When I hit an issue on the new VM that looked familiar, I didn’t have to remember if I’d seen it before. I searched. The answer came back with a file path, a commit hash, and the session where it was originally diagnosed.

The migration involved multiple Claude Code sessions across multiple repos over several days. At no point did I need to re-explain the state of things. Every agent session started by checking recent activity in pgvector, saw what had been done, and picked up from there.

Multi-Agent Code Review Pipelines

This is where the system started doing things I hadn’t originally planned for.

I run production readiness reviews where Claude Code audits a codebase against a structured checklist — security, performance, error handling, configuration management. With the knowledge system, each review already built on previous ones, checking which issues had been fixed and which were still open.

But I wanted a second opinion. So I started running formal multi-agent review cycles: Claude Code performs the initial review, then I hand the findings to OpenAI’s Codex for a counter-review. Codex challenges the findings, flags false positives, and identifies issues Claude missed. Then I bring the combined results back to Claude Code for a remediation plan.

Here’s what made this work: both agents were reading from and writing to the same knowledge base. Codex didn’t need me to paste in Claude’s review — it searched pgvector and found it. When Claude Code built the remediation plan, it pulled in Codex’s counter-review findings automatically. The session logs from both agents were ingested into the same database, creating a complete audit trail: who found what, who disagreed, what was ultimately fixed, and why.

This isn’t a theoretical workflow. It ran multiple times across multiple projects during these nine days. The combined review quality was noticeably better than either agent alone, and the overhead of coordinating between them was essentially zero because the context was shared.

Production Bug Hunting Across Repo Boundaries

The cross-repo capability I described in the original post proved itself in production debugging.

One issue involved client IP resolution. My Angular application, sitting behind an NGINX reverse proxy, was logging proxy IPs instead of real client IPs. Diagnosing this required understanding the full chain: how NGINX sets X-Forwarded-For headers, how the .NET backend reads them, and how the Docker network topology affects what each layer sees.

That chain spans three repositories. In a normal workflow, I’d open each project, read the relevant config files, hold the whole model in my head, and try to trace the problem. Instead, I described the symptom to Claude Code, and it searched pgvector across all repos simultaneously. It found the NGINX proxy configuration, the .NET middleware that reads forwarded headers, and the Docker compose network settings — then correlated them to identify exactly where the IP was being lost.

The same pattern played out with CSP header issues and database query optimizations. Problems that cross repo boundaries are disproportionately expensive to debug because the context is scattered. The knowledge system collapses that cost to nearly zero.

Upgrading .NET 8 to .NET 10

Framework upgrades are tedious but not usually complex — unless you have to account for everything the project has accumulated over time. Custom middleware, nuget packages with version constraints, Docker base images, CI configurations, deployment scripts.

The knowledge system turned this from an afternoon of careful checking into a focused, fast session. Claude Code searched pgvector for every configuration file, every Docker reference, every dependency declaration across the project. It knew which packages had been recently updated (from session logs) and which had known compatibility issues (from prior code reviews). The upgrade was planned and executed in a single session with no surprises, because the agent had complete visibility into the project’s dependency landscape before writing a single line of code.

The Big One: A 17-Phase Repo Consolidation

This was the real stress test. The iching.rocks website.

I had two separate repositories for a single product: iching.rocks (the main application) and iching.rocks.admin (the admin panel). They shared models, database connections, and configuration — but lived in separate repos with separate Docker builds, separate CI, and separate deployment pipelines. It was the kind of technical debt that’s easy to accumulate and painful to unwind.

The consolidation started with planning. Claude Code searched the knowledge system for every file in both repos, every shared dependency, every Docker configuration, every deployment reference. From that, it generated a 17-phase migration plan — not a rough outline, but a sequenced, dependency-aware execution plan that accounted for build verification at each stage.

Before executing any of it, I handed the plan to Codex for review. Codex queried the same pgvector database to validate the plan against the actual codebase. It flagged two phases that had ordering issues and one that missed a shared configuration file. The plan was revised.

Then execution began. Phase by phase, Claude Code merged project files, cleaned up dead references, consolidated .csproj files, unified Docker builds, and verified that everything compiled and ran at each checkpoint. Each phase was a separate session, and each session was logged and ingested. Here’s what one of those session logs actually looked like:

# Session: 2026-02-15 - Repo Consolidation Phase 7
## What Changed
- Merged iching.rocks.admin/Models into iching.rocks/Shared/Models
- Updated 14 namespace references across 8 files
- Consolidated Docker build context to single Dockerfile
## Key Decisions
- Kept admin route prefix to avoid breaking bookmarked URLs
## Deferred
- CSP header update pending NGINX config syncCode language: Markdown (markdown)

That’s the actual artifact that makes persistent context work. Every phase produced one of these. By phase 10, the agent had the complete history of the migration — every file moved, every reference updated, every build result, every deferred decision — without me summarizing anything.

The final phases included re-ingesting the new consolidated repo into pgvector (so the knowledge system reflected the new structure), archiving the old repositories, and verifying that all MCP tools correctly resolved against the merged codebase.

Seventeen phases. Two agents. Zero lost context.

If I’d done this manually, I would have spent the first hour of every work session re-reading my notes from the previous session, trying to remember which files I’d already moved and which references I’d already updated. That re-orientation cost is the hidden tax on every complex migration. The knowledge system eliminated it entirely.

The Compound Effect

The individual accomplishments are impressive enough on their own. But the real story is the compound effect.

The infrastructure migration generated session logs. Those logs provided context for the code reviews. The code review findings informed the .NET upgrade. The upgrade validated patterns that were then applied during the repo consolidation. The consolidation itself was reviewed using the multi-agent pipeline that had been refined during earlier reviews.

Each task made the next one faster. Not because I got better at prompting — because the semantic knowledge system got richer. By day nine, the system contained a dense web of decisions, fixes, reviews, and architectural context that made every new session dramatically more productive than the first.

This is the property that distinguishes a knowledge system from a chat history. Chat history is linear and siloed. The knowledge system is a graph — everything connects to everything, and every agent can traverse it.

What This Actually Feels Like

I want to be specific about the experience, because the abstract description doesn’t capture it.

It feels like working with a team that has perfect institutional memory. You know how the best teams develop shared context over months of working together? Someone mentions “the caching issue” and everyone knows exactly which caching issue, when it happened, and what the fix was? That’s what this feels like — except it took nine days instead of nine months, and the context is searchable.

It also changes how you think about documentation. I stopped writing READMEs that explain “how to set up the project” because the knowledge system already contains that information in a form that’s more useful — not a static document that drifts out of date, but a living index of every configuration change, every environment variable, every deployment step, updated automatically every time a session closes.

The agents themselves behave differently when they have this context. They ask fewer clarifying questions. They make fewer incorrect assumptions. They propose solutions that account for constraints they discovered in the knowledge base rather than constraints I remembered to mention. The quality of the output goes up because the quality of the input — the ambient context available to the agent — is fundamentally better.

What I’d Tell You If You’re Considering This

The semantic knowledge system I described in the first post is simple in architecture. PostgreSQL, pgvector, an MCP server, a session workflow. It took a day to build and costs effectively nothing to run.

The part that takes discipline is the workflow. Every session needs to close properly: commit with a detailed message, write the session log, run the ingest. Skip that step and you create gaps in the knowledge base that degrade every future session. I’ve been strict about this for nine days and the payoff has been enormous. I suspect the payoff compounds further over weeks and months as the knowledge base deepens.

If you maintain multiple repositories that interact with each other — and most of us do — the cross-repo search alone is worth the setup. The number of times I’ve been saved by context surfaced from a different repo is already in the double digits.

And if you work with multiple AI agents or models, the shared knowledge base is transformative. Agent coordination is one of the hardest problems in AI-assisted development. A shared semantic memory doesn’t solve it completely, but it eliminates the most expensive part: re-establishing context.

The Bottom Line

Nine days ago, I had an architecture and a theory. Now I have a track record: infrastructure migrations, multi-agent review pipelines, production debugging across repo boundaries, a framework upgrade, and a 17-phase repo consolidation — all executed with persistent context that no agent ever had to re-learn.

The semantic knowledge system isn’t a productivity hack. It’s a new kind of development infrastructure. It turns AI agents from brilliant amnesiac consultants into long-term collaborators with perfect recall.

The first post was the blueprint. This is the proof.

More coding articles