I Didn't Build an AI Agent. I Built the Infrastructure Behind It

A friend recently suggested I build an AI agent loaded with vendor documentation, troubleshooting guides, and technical information. He also asked what kind of hardware I use to run local language models.

Well, I've actually been building something along those lines for quite some time. Except I approached it a little differently.

I built the data infrastructure first. AI came later.

The result is Helix, an on-premises operational intelligence platform I developed for our telecommunications network.

And although AI has become an important part of it, the real machinery underneath is traditional database and software engineering.

Helix: The Architecture

At its core, Helix is a hybrid database environment built around MariaDB, OpenSearch, Redis, and a substantial amount of Go code.

Each component serves a different purpose.

MariaDB is the relational foundation.

The current system contains roughly 98 tables maintaining relationships among customers, equipment, services, addresses, network infrastructure, and other operational information.

Data comes from provisioning systems, customer management platforms, equipment APIs, and various network databases.

MariaDB maintains the structured relationships and operational state that connect all these otherwise independent systems.

OpenSearch is the analytical and knowledge platform.

It contains billions of operational records collected from network equipment, cable modems, optical networks, telephone switches, SIP trunks, system logs, alarms, and call detail records.

It also holds our entire TSC knowledge base, historical trouble tickets, and practically every piece of technical documentation I've been able to locate from our equipment vendors.

That information is indexed for traditional searches, full-text searches, and vector-based semantic retrieval.

This is an important distinction. I don't depend exclusively on vector searches.

Sometimes I want to find a specific telephone number, MAC address, equipment identifier, or error message. Other times I'm looking for a concept buried somewhere in hundreds of pages of documentation.

OpenSearch handles both, along with the time-series analytics needed to understand network behavior.

Go is the glue holding everything together.

I've written numerous Go services that communicate with equipment APIs, poll network devices, synchronize databases, parse enormous log files, and correlate records from systems that were never designed to communicate with one another.

These services continuously enrich the data using authoritative information from MariaDB and analytical information from OpenSearch.

Much of the real intelligence in Helix comes from this correlation.

Instead of forcing someone to manually connect customer records, equipment information, network statistics, and historical events, the software establishes those relationships ahead of time.

Redis provides fast temporary state and caching where needed.

The result is a continuously updated operational environment rather than a collection of disconnected dashboards.

Where AI Fits In

Codex sits on top of this infrastructure.

It can search the technical knowledge base, examine operational history, query the databases, inspect code, and investigate problems using information collected directly from our network.

It isn't simply answering questions based on documents.

It has access to structured relationships, historical telemetry, equipment information, and operational tools.

The important part is that the AI doesn't have to maintain all that knowledge internally.

The information lives in the databases.

The model retrieves what it needs, interprets the results, and helps with the investigation.

I use OpenAI's models extensively, but Helix isn't dependent on any particular language model.

I can change models without rebuilding the underlying data infrastructure.

The databases hold the knowledge. Go maintains the relationships. AI provides another way to interact with it.

The Hardware Running Helix

One misconception about systems like this is that they require an enormous GPU cluster.

Helix doesn't.

The core infrastructure runs on three refurbished Xeon servers under Proxmox.

Each server has:

• 28 CPU cores
• 512 GB RAM
• 16 TB NVMe storage
• 16 TB additional disk storage

The servers communicate over 10-gigabit networking, with a 10-gigabit fiber uplink.

The hardware investment was approximately $15,000.

That cluster handles the OpenSearch indexes, MariaDB environment, Redis, Go services, and other supporting applications.

We're processing billions of records, polling thousands of network devices, and continuously ingesting operational information.

Most of that work requires no AI whatsoever.

A database query doesn't need a language model. Neither does parsing a log file or polling a modem.

Conventional software handles those jobs faster and more efficiently.

AI comes into play when we need flexible investigation, interpretation, or natural-language interaction.

My Home Lab: A Separate Environment

My home laboratory uses a similar philosophy, but it is completely independent of Helix and contains no TSC proprietary information.

I've built a personal technical knowledge environment containing approximately 800 technical books, along with a large collection of documentation and reference material gathered from the internet.

That knowledge is searchable using OpenSearch, including full-text indexing and vector embeddings.

I use Codex and OpenAI models to help develop and expand the environment, but I also experiment with locally hosted language models.

My main workstation is a fairly substantial Linux machine.

Component	Hardware
Processor	AMD Threadripper, 32 cores
Memory	256 GB RAM
Graphics	AMD Radeon GPU, 12 GB VRAM
NVMe storage	Approximately 6 TB
Additional storage	Approximately 21 TB ZFS
Operating system	Linux Mint
Local AI	Ollama, Mistral Nemo, Qwen, and other models

The 256 GB of system RAM allows me to experiment with larger quantized models that don't fit entirely in GPU memory, although inference speed depends heavily on how much can be accelerated.

I've tested several model families, but Mistral Nemo 12B has been one of my regular choices.

Like Helix, the home environment keeps its knowledge separate from the language model itself.

I'm not retraining foundation models every time I add another technical book or document.

I index the material, generate embeddings, and retrieve the relevant information when needed.

OpenAI and Codex help me build and refine the software, while local models can use the same underlying knowledge without requiring every request to go through a hosted service.

The Point of All This

I didn't set out to build a chatbot that happened to know a few things about telecommunications.

I wanted an infrastructure capable of collecting information, maintaining relationships, and making that information useful.

MariaDB handles the structured facts.

OpenSearch handles the analytical history, full-text knowledge, and vector searches.

Go keeps the information flowing and connects the pieces.

Redis handles fast state and caching.

And AI sits above it all, using the information those systems provide.

The same philosophy applies to my home laboratory, just with different data and considerably different hardware.

The most important part of an AI system isn't necessarily the model. It's the quality, accessibility, and organization of the information the model can use.

Models will continue improving. Some will disappear, and better ones will replace them.

But the databases, documentation, relationships, and software I've built will still be there.

That's why I built the infrastructure first.

Bryan