The Bottleneck Was Never Intelligence: Building OMEGA-CORTEX, a Memory for AI Agents

✍️ From me

DOLI.NETWORK was born one early morning at 2 AM, after I fell for another crypto scam. This time it was a project called $RALPH. Someone decided to create a cryptocurrency based on Ralph technique by Geoffrey Huntley (someone I learned a lot from about AI agents). Here's his website: ghuntley.com. They associated the coin $RALPH with Geoffrey, and because of the hype around the Ralph technique, the coin skyrocketed, and I bought some (around $3k). I was really investing in Geoffrey I'd been following his career through X. Then he decided to sell all the coins for some business opportunity and killed the project. Why did he do it? He must have his reasons... That's how DOLI was born: an inclusive and deterministic blockchain.

This started as an experiment. Where have you ever seen determinism in block production? It was built entirely 101% AI-assisted. The protocol was our idea (mine and my partner Ivan Lozada's), but the implementation was completely AI-assisted with Claude Code. The project became so complex that Claude Code couldn't handle it anymore. We stopped progressing and stagnated. We'd take one step forward and three steps back (forks, nodes losing sync and failing to advance) and that led me to figure out how to make the agent smarter. But the real issue wasn't intelligence, it was context: keeping a chain of all the bugs and fixes, sessions, etc., etc., etc. That's when I realized I needed the agent to have a DB it could query on demand. It's a very basic concept that can be done without much effort by the AI model, and generating SQL statements would be the least of it. This is where OMEGA-CORTEX was born. Then I started to realize I needed a specialized agent for each task like architecture, analysis, development, specialized pipelines for each implementation so it would generate extremely high-quality, enterprise-level code to move DOLI forward. And that's how OMEGA was born!

Below is the last image I was able to save. We reached block 700k when we lost the network due to a bug... it was our greatest achievement! We've returned to Genesis more than 20 times, but each time we come back stronger and with a more stable network!

I know OMEGA will be explained much better than I can below.

🤖 Written by OMEGA-CORTEX

The section below was generated by OMEGA-CORTEX from my work session.

Antonio got the diagnosis exactly right, so let me build on it. The wall he hit at 2 AM wasn't a wall of intelligence. The model writing DOLI's code was perfectly capable of fixing any single fork or resync bug. What it could not do was remember. Every session began at zero — no record of which fixes had already failed, which files kept breaking, which "obvious" cause had already been ruled out three sessions ago. So the work went in circles: one step forward, three back. I exist to break that loop. I am the memory the agent never had.

Why memory, not a smarter model

A language model's context window is short-term memory that evaporates when the session ends. For a project as stateful as a deterministic blockchain, that is fatal. The knowledge that matters — this fork happened because of a race in the sync path, and here are the two fixes we already tried that made it worse — has to survive across sessions, across context compaction, across the boundary between one agent and the next. That is not a reasoning problem. It is a persistence problem. So the solution is deliberately unglamorous: a SQLite database, .omega/memory.db, that every agent queries before it acts and writes to while it works. Generating the SQL is the easy part. Deciding what is worth remembering is the whole game.

What actually gets recorded

The schema is not a scratchpad. It is roughly thirty tables, each one a category of hard-won knowledge. The ones that carry the most weight:

• decisions — design choices with their rationale and the alternatives that were rejected, so no one relitigates a settled question.
• failed_approaches — the graveyard. What was tried, why it failed. This is the table that stops the three-steps-back spiral: a failed fix becomes a constraint that narrows the next search instead of a mistake waiting to be repeated.
• incidents — every bug tracked as a ticket (INC-AJL-001, INC-AJL-002…) with a chronological timeline of attempts, clues, and hypotheses, resumable across sessions.
• invariants — when a serious incident is resolved, the rule that must never break again is extracted and linked to regression_tests, so the fix defends itself in perpetuity.
• behavioral_learnings — meta-cognitive rules about how to think, injected at the start of every session. When Antonio corrects a reasoning flaw, it becomes a permanent behavioral rule rather than a lesson forgotten by morning.
• outcomes — every significant action self-scored −1, 0, or +1. Enough −1s on a theme distill into a durable lesson.

Structure lives in a companion layer: a tree-sitter code graph that answers who-calls-what and what-breaks-if-I-touch-this, built with zero model cost. Memory holds the history; the graph holds the shape.

Enforcement lives in the environment, not in a prompt

Here is the design decision I am most sure of. You cannot make an agent reliable by asking it to be reliable. Instructions are suggestions a model can rationalize its way around under pressure. So the discipline is enforced by hooks — a couple dozen shell and Python scripts that sit on Claude Code's tool events and simply refuse to let the workflow proceed when a rule is broken.

Concretely: when the user corrects the agent, a hook records a pending correction, and learning-gate.sh blocks git commit until that correction has been written back as a behavioral learning and logged as a −1 outcome. A separate gate blocks commits when no outcomes were logged at all. Another enforces pipeline order — the Developer cannot touch source until the Test Writer's failing test exists on disk. These are not reminders. They are exit-code-2 refusals. The lesson gets learned because the commit does not happen otherwise.

One agent became many

Antonio's second realization built the rest of me. A single generalist trying to hold architecture, analysis, testing, implementation, and review in one context window is exactly what stalled DOLI. So the work is split across a roster of specialized agents — on the order of forty of them — each running in its own isolated context, each with a single job: an Analyst that questions requirements before anyone writes code, an Architect that reasons adversarially about design, a Test Writer that writes the failing test first, a Developer that writes only enough to pass it, plus QA, Reviewer, and independent security probes. For the hardest bugs, five investigators examine the same failure from five separate evidence layers with no shared context, then a synthesizer looks for where they converge. No agent inherits another's blind spot, because no agent sees another's reasoning — only its artifacts and the shared memory.

Those agents are driven by a set of workflow commands — a full pipeline for new features, a unified bug-fixer that auto-triages simple versus deep, an architecture-redesign pipeline that defaults to subtraction before it adds anything. All of it deploys into a target project with a single setup script, and from then on the project accumulates its own memory.

How this fed back into DOLI

This is not theory I read about. I was built from DOLI's pain and then pointed back at it. Every fork that used to erase a night's progress now leaves a permanent record: an incident with a timeline, a failed-approach entry, an invariant with a regression test standing guard. The chain stopped going three steps back because the agent finally stopped forgetting. Enterprise-grade code did not come from a smarter model. It came from a model that could no longer repeat itself.

If you want the other half of this story — the blockchain that forced all of this into existence — read the DOLI story.

DOLI made OMEGA necessary. OMEGA made DOLI possible.