How I Got Here
Computer Math, 1983
It started in Computer Math class at Joel E. Ferris High School in Spokane, Washington. Junior year — I was sixteen. The class had Apple IIes, and the curriculum was BASIC programming. I took to it immediately.
What hooked me wasn’t the assignments. It was the moment I realized I could make the machine solve my problems.
The Commodore 64 Era
The Apple IIe was the school’s. The Commodore 64 was mine.
I kept building. A friend and mentor showed me his RPG character tracker and I couldn’t wait to make it myself! Multi-character load and save from disk, calculators for game mechanics, anything that saved time at the table. The C-64 was slow by modern standards — certain operations took five minutes to grind through — but it was my machine, and I could make it do things.
My friends and I played a lot of Aftermath! — a post-apocalyptic tabletop RPG that fit the mid-80s Cold War mood perfectly. Calculating a machine-gun burst in Aftermath was a multi-step process: range, cover, weapon specs, hit probability, wound location. In the middle of a session, nobody wanted to stop and do the math. So I wrote a program. You’d enter the inputs, it would roll the dice, and tell you how many bad guys needed to be removed from the table.
That was the first time I built something that solved a real problem for real people in real time. That feeling never got old.
In the early 90s I converted one of those character-tracking programs to run in IBM QBasic. I ran it, watched it complete, and thought it had crashed — it had finished in about 3 seconds what the C-64 spent five minutes on. That was my first real lesson in what hardware generation changes actually feel like.
The Long Road Through IT
My career has been the full tour. Desktop support. Network admin. Telephony, Systems administration across Windows, Linux, and the sprawling hybrid middle ground most enterprises actually live in. I’ve done networking, web-filtering, virtualization, identity management, and eventually landed in the SRE/infrastructure space.
For a long time, the job was about keeping things running. Reliability over innovation. Don’t break what works.
At some point — somewhere in the VMware-to-cloud migration era — that started to feel insufficient. “Keeping things running” is necessary but not a destination. It started with Infrastructure-as-Code - Packer, Terraform, Ansible - I could build whatever I wanted, configure it how I wanted, as MANY as I wanted…everything was just variables.
The AI Pivot
My real pivot into AI happened the way most things happen in this field: I stumbled into it through a side door.
My family and I started playing D&D together when my daughter was about 5. We had great fun wreaking destruction throughout the Forgotten Realms. In 2023 I started using ChatGPT to help build the places we explored — world details, NPC backstories, plot threads, Character dialogue. The moment I realized a language model could be a collaborative storytelling partner rather than just a search engine, something clicked. It wasn’t just answering questions. It was maintaining context, building on previous turns, synthesizing a world.
That was the moment I understood this was something genuinely different from every prior wave of “AI.”
From there I started reading everything. Research papers, blog posts, conference talks. I found Nate Jones on YouTube — an ML engineer who covers agentic AI systems with the kind of engineering rigor that actually maps to real infrastructure work. His content changed the way I think about what these systems can do.
Where I Am Now
I’m currently an infrastructure/SRE engineer at Rockwell Automation in the Boise metro area. I run a homelab on Proxmox — a Talos Kubernetes cluster, Technitium DNS, and a handful of self-hosted services I use as a personal research environment.
The homelab is where I build things that don’t have to work in production yet. That’s where OpenBrain, the multi-agent infrastructure automation system, and the agent eval harness all started.
This blog is the documentation layer. Notes on what I’m building, what broke, and what I’d do differently. Technical enough to be useful, personal enough to have a point of view.
If any of this sounds like work you’re doing — or work you want to do — I’d like to hear from you.