About Me

I didn't come into any of this through the conventional route.

My background is in baseball and business. I played college baseball, earned a business degree, and had no formal education in computer science, software engineering, distributed systems, or any of the other disciplines that much of my work now involves.

When I started, I didn't have an engineering career behind me or years of industry experience to draw from.

What I did have was an obsession with building things that were difficult.

I've never been particularly interested in doing something just because someone else has already shown how to do it. I like big problems. I like complexity. And if something seems too ambitious, too difficult, or too far outside what one person should reasonably be able to accomplish, that generally makes me more interested in finding a way to do it.

That's a big part of how I ended up here.

How I actually build

I didn't approach AI as something that could just write code for me.

I started thinking about what would happen if I could orchestrate multiple AI systems to work together on problems that were far bigger than any one conversation, model, or coding task.

I had architectural ideas of my own, often without knowing the established engineering terminology for what I was describing. I'd explain what I wanted a system to actually be capable of, how its parts should work together, what shouldn't be allowed to happen, and what I expected the result to look like.

Then I'd work through the problem with AI.

Sometimes that meant directing the architecture myself. Other times the process led to ideas neither the original prompt nor my initial design had anticipated. I'd challenge the results, explore the consequences, change direction, and keep going.

I don't pretend the AI systems were just typing out instructions I'd already figured out. They've contributed substantively to the research, architecture, engineering, implementation, and evaluation.

But I've been the one directing that work, making the decisions, resolving conflicts, integrating the results, and ultimately taking responsibility for what gets built.

It's also how I've learned. I haven't separated learning engineering from actually doing engineering. Much of what I understand today came from encountering problems in the systems I was creating and refusing to work around them just because the proper solution was difficult.

What came out of it

I built Cuttlefish and Freehold through that process.

I'm the sole human engineer behind both systems. That includes their architecture, applications, enterprise backend, infrastructure, integrations, governance, GitOps, cloud environments, and production engineering across Azure and AWS.

There wasn't a human engineering team writing the backend, managing the infrastructure, or implementing the difficult parts for me.

It was me, orchestrating AI systems, working through the problems, and getting the work done.

Both Cuttlefish and Freehold are real production systems with customers. They aren't just research concepts or demonstrations of what might eventually be possible.

And they haven't been simple things to build.

Why the research exists

A lot of the research published here grew out of questions I encountered while building these systems.

What happens when an autonomous worker disappears but the responsibility for its work doesn't? How do you know whether an external action actually happened? How do you prevent a system from acquiring authority just because it has become capable of doing something? How does something continue operating when the model, infrastructure, or even the organization behind it changes?

I wasn't satisfied with answers that depended on an AI model remembering instructions or behaving correctly.

Those questions kept leading into other questions, across distributed computing, identity, authority, evidence, recovery, learning, and institutional continuity.

Eventually they became this body of work.

Some of the ideas came directly from problems I set out to solve. Others emerged through the research and the AI collaboration itself. Some are implemented, some have executable supporting evidence, and others still have unresolved questions.

I'm not interested in pretending everything is proven because a specification is extensive or a test passes. I want to know what actually holds up when it's challenged.

Why I'm sharing it

I'm not publishing this because I have an academic background in these subjects. I don't.

And I'm not claiming that orchestrating AI somehow makes me personally responsible for every line of reasoning or code it generated.

I'm sharing it because this is what I've spent my time creating, because the problems matter to me, and because I think some of the work deserves examination by people who understand these disciplines at a much deeper level.

I want people to challenge the technical ideas, test the evidence, point out what doesn't hold, and recognize what does.

I'm also interested in what this entire experience says about how engineering itself is changing.

I came into this without the training or professional background normally associated with work of this scale. Through AI orchestration, I was able to explore disciplines I hadn't formally studied, develop complex architectures, and turn ideas into operating software.

I don't think that means expertise no longer matters. If anything, building these systems has given me a much greater appreciation for how difficult correctness really is.

But it does make me question some of our assumptions about who can undertake this kind of work, how they can do it, and what becomes possible when one person can coordinate substantial AI engineering capability.

I don't know where all of that ultimately leads.

I do know I'm nowhere near finished.