CodexMCP Did Not Die
It Became Helix.
If you browse back through this blog, you will find quite a bit of writing about a project I was working on before I disappeared into my seven-month AI experiment run.
That project was CodexMCP.
CodexMCP was my attempt to build an intelligence layer for complex systems. Not generative AI. Not a chatbot. Not a dashboard with a text box bolted onto it.
It was closer to an expert system.
The idea was to take logs, events, API data, alarms, state changes, and other operational information from multiple systems, normalize all of it, correlate it, and begin answering three basic questions:
What is happening?
Why is it happening?
What should we do about it?
I built a virtual ISP around it as a proving ground.
That environment included DHCP, DNS, SIP, billing, access systems, monitoring, log collection, and a pile of virtual machines that could be launched together in a few minutes. The virtual ISP was never really the point. It was just a way to generate activity and give CodexMCP something to watch.
And technically, it worked.
The problem was the data.
I could generate logs. I could simulate failures. I could make services start, stop, timeout, reject requests, lose connectivity, recover, and throw alarms.
What I could not generate was convincing human behavior.
You really cannot fake that at scale.
Humans are strange.
They do things out of order. They retry at odd times. They click the wrong thing, wait twenty minutes, try again, then call support and describe something completely different from what actually happened.
They unplug equipment, move cables, reboot the wrong device, ignore alarms, create new problems while trying to fix the first one, and occasionally stumble into a solution without knowing what they did.
Live networks are not much better.
They are full of old equipment, strange configurations, partial failures, undocumented dependencies, timing problems, vendor behavior, historical decisions, and systems that work perfectly right up until two unrelated things happen at the same time.
A simulated environment behaves too well.
Even when you intentionally break it, it usually breaks in a clean and predictable way.
Real systems do not have that courtesy.
That became the ceiling for CodexMCP in my home lab.
I could build the platform. I could build the ingestion. I could build the normalization, correlation, plugins, APIs, and interfaces.
But I could not produce enough realistic operational noise to properly test whether the intelligence layer could separate a real problem from all the ordinary weirdness happening around it.
So CodexMCP changed direction.
Instead of trying to create a realistic network at home, I brought the underlying idea into a real one.
That project became Helix.
Helix is now being developed inside the telecommunications company where I work. It ingests and analyzes information from real operational systems across voice, cable, fiber, networking, and customer services.
This is not simulated data.
These are real call records, real device measurements, real alarms, real subscriber events, real outages, real network changes, and real patterns created by thousands of people using services in ways no lab simulation would ever think to reproduce.
Helix uses OpenSearch, MariaDB, Redis, Go, Python, Grafana, and a growing collection of purpose-built services and interfaces.
It collects billions of records.
It polls devices continuously.
It parses enormous volumes of voice logs.
It tracks cable modem health, fiber events, call behavior, equipment state, and network conditions over time.
But the volume of data is not the important part.
The important part is turning that data into operational knowledge.
Helix has helped identify voice routing failures that affected only a small percentage of calls and would have been extremely difficult to isolate manually.
It has narrowed cable plant problems from large service areas down to small physical sections.
It has exposed failing equipment, recurring patterns, unusual ONT behavior, call routing issues, and conditions that would otherwise remain spread across several unrelated systems.
It gives us memory.
That may be the simplest way to describe it.
Most network tools are very good at showing what is happening right now.
Some are good at showing what happened yesterday.
Very few understand that an alarm today may be related to a configuration change two weeks ago, a signal pattern last month, and a similar failure six months earlier.
Helix is being built to remember those relationships.
It is also slowly learning how I work.
Not in the generative AI sense.
It is learning the process.
How I compare events. How I narrow a problem. What evidence matters. What patterns I trust. What I dismiss as noise. What should become an alert, a ticket, a report, or a deeper investigation.
That is much closer to the original CodexMCP idea than anything I could have built in the lab.
CodexMCP did not fail.
It ran into the limit of simulation.
Helix is what happened when the same idea was given access to a living network.
I plan to write more about Helix here.
Not company secrets, customer information, internal addresses, or anything else that should remain private.
But the architecture, the ideas, the lessons, the mistakes, the methods, and the broader operational concepts are too valuable to leave undocumented.
I have learned a tremendous amount building this system.
Some of it came from success.
A lot of it came from building something the wrong way first, watching it collapse under real data, and rebuilding it with a better understanding of the problem.
That information should not disappear into an internal system, a forgotten folder, or a paid platform.
I do not want to put it behind a paywall.
I do not want every useful technical thought turned into a subscription product.
Some things should simply be written down and shared.
So that is what I am going to do here.
If you read the older CodexMCP posts, you are looking at the beginning of the idea.
Helix is what came next.
--Bryan