Field Notes
Wind on the Wire
qortex was a library. Now it’s a service: knowledge graph, learning store, and vector index, off localhost and onto the network.
From Library to Service
This is not what we set out to do.
Originally, we were building a language app to make it easier to study the sagas. The app part went well; the understanding-the-sagas bit…Not so much. As you might imagine, Old Norse morphosyntax is not well-represented in the training data.
This led to a litany of mistakes. Forgivable ones: Claude’s classical Scandinavian is about as fluent as my Binary. I get it. I can let domain errors slide: That’s why we calmly forked an Icelandic dictionary and added a reverse direction to help.
But it wasn’t the pardonable domain errors that led to qortex.
No. It was the in-excusables: Putting things in the wrong config file, after a dozen reminders. Invoking the wrong API. Picking up yesterday’s handoff document from the wrong folder. Again.
The Problem
Somehow, still, in 2026, duplicating database tables it had already created; using context from CLAUDE.md and SKILL.md only when it felt like it; suggesting the same fix it had already tried and abandoned ten minutes prior…You know the drill.
Ófyrirgefanlegur , not that Claude would know, even, to a Viking of proper principle.
That’s why we built qortex: a knowledge graph with a learning layer that does not forget.
The Fix
If the agent can’t remember what works and what doesn’t, give it a system that remembers for it.
The graph tracks which paths lead to useful answers , and which ones are dead ends.
It finds structural connections that cosine similarity alone can’t reach . And retrieval quality improves from usage: accept a result, the edges that led to it strengthen; ignore it, they weaken. This aspect remains early, as we’re focusing on using the learning layer as a direct “RL-lite”-style harness in, for instance, LinWheel…But learning over retrieval is wired.
It started as a Python library: you imported it, it ran in-process. If you wanted to use it from a Next.js/TS app, you talked to it over MCP stdio: spawn a subprocess, pipe JSON, hope for the best.
The best typically worked, and did fine for proving the point.
Over the Wire
Trouble is, MCP stdio only works when everything lives in one process on one machine. It’s a reasonable place to start when first figuring out the learning loop.
But the moment you need a TypeScript frontend to talk to a Python backend, or two services to share the same knowledge graph, this obviously breaks.
Instead, we put core behind a REST API. Any client, any host, over HTTP: classic service setup.
Now, we back devtools like buildlog with the library solution, and products like LinWheel (TypeScript) and Swae (Python) with the same learning-enabled, vec-and-graph-backed backend.
What This Buys
The rest of the world is busy dropping markdown files in a folder and calling it engineering.
Take Context Hub, for example. Note this excerpt:
Chub is designed for your coding agent to use (not for you to use!). You can prompt your agent to use it (e.g., “Use the CLI command chub to get the latest API documentation for calling OpenAI. Run ‘chub help’ to understand how it works.”) Or by creating an agent skill to use Chub using SKILL.md, and ideally prompting your agent to remember to use this skill. (If you are using Claude Code, create the directory ~/.claude/skills/get-api-docs and put SKILL.md there.)
The problem with “prompt your agent to remember to use this skill” is that there’s no feedback signal. You write a markdown file, the agent reads it, maybe, and you have no way to know whether it changed anything.
Did retrieval improve? Did the agent make fewer mistakes? You can’t answer those questions because the system doesn’t measure anything. It’s a sticky note on a monitor.
Maybe someone reads it. Maybe they don’t. You’ll never know. And every claim to the contrary is either a bold-faced lie, or a starry-eyed script kiddy with half-assed, barely working definitions of memory and learning.
Harsh? Maybe. But only just as maybe as everyone’s lack of evidence.
I’m not even claiming we have the solution: qortex might very well be wrong. The learning curve might be too slow, the graph structure might not generalize, the convergence might stall, our PPR variant might be too heavy…All possible.
But we can show you the numbers: Precision, recall, posterior distributions, retrieval paths chosen, those rejected…If it fails? I can tell you how. I can tell you where. I can tell you by how much.
That’s the difference between engineering and pretending dumping sentences into a README that says “ideally prompting your agent to remember” actually counts.
It doesn’t. That’s called writing. An entire industry of people who’ve never read a real book rediscovering words and rebranding “using them” as “context engineering” does not make a rose any less a rose.
For most things? This is fine. If your agent’s sending emails, updating Notion, and otherwise doing nothing more than typing for you, sure. Markdown files are the correct answer: All you’re doing is moving bits from one to the other, anyway.
But for reasoning about novel causality in unstructured domains? Stable assistant personalities? That silly “Jarvis” fantasy people can’t shut the fuck up about?
If we collectively accept “markdown” = “memory”, that whole fever dream is cooked.
Qortex, or something like it, is what the agents need to wake up.