Trustworthy infrastructure for autonomous AI systems.

My interest in autonomous infrastructure comes from a decade spent designing and operating systems where reliability, security, and failure were not theoretical concerns. I started in network engineering, moved into DevOps, then into senior DevSecOps work, then into infrastructure architecture, technical interviewing and engineering leadership, and eventually into co-founding and building agentic systems.

Each of those steps widened the surface I was responsible for and narrowed my faith in static rules. Networking taught me that failure is a property of topology, not of any single device. DevOps taught me that the delivery pipeline is itself a production system. Security engineering taught me that controls expressed as guidance are not controls. Architecture taught me that the interesting failures are in the seams between components that each work correctly.

By the end of that arc I was maintaining systems that were too large for any operator to hold in their head, defended by rules written for attacks we had already seen, and recovered by humans paged at three in the morning. That is the limit of infrastructure that depends entirely on static policy and human intervention — and it is precisely the limit that autonomous systems are being sold as the answer to.

So my research questions are not abstract to me. They are the questions I would need answered before I would let an agent touch the systems I used to be responsible for: what does it remember, what can I see, and what is it structurally unable to do? Everything below follows from that, and from one recurring thesis: reliability is a systems problem, not a model problem.

The next generation of software will not be written as a static set of instructions. It will be written as agents: programs that observe, reason, and act over time, often across systems their designers do not fully control.

This is not hype. It is a natural evolution. We already trust automation to manage infrastructure, security, and data pipelines. The difference is that classical automation is deterministic and narrow. Agents are adaptive and general. They can handle situations the designer did not explicitly anticipate.

That generality is also the risk. An agent that can do many things can also do many things wrong. It can misinterpret intent, persist bad decisions, or act on outdated knowledge. Making agents useful means making them trustworthy.

Most of the conversation around AI safety focuses on models: alignment, fine-tuning, red-teaming, and evaluation benchmarks. These matter. But they are not sufficient.

A model is one component of a larger system. The system also includes memory, tools, observability, governance, identity, and coordination. Even a perfectly aligned model can fail if the infrastructure around it is brittle or opaque.

Infrastructure is where reliability engineering meets AI research. It is where we ask: How do we know what the agent believes? How do we stop it when we need to? How do we make sure its actions are auditable and reversible? How do multiple agents share context without corrupting each other's state?

These are systems questions. They require distributed systems, security, databases, networking, and observability. They also require a deep understanding of how agents actually behave in production. That intersection is where I want to work.

The current state of agent infrastructure is reminiscent of web development in the late 1990s. There are powerful primitives, but the surrounding tooling is immature. We are building skyscrapers on foundations that were designed for smaller structures.

• Memory is mostly retrieval. Most "memory" systems are vector search over history. They lack forgetting, consolidation, causal structure, and provenance.
• Observability is human-centric. Metrics, logs, and traces assume a human operator. They do not capture reasoning, intent, or the agent's model of the world.
• Governance is static. Approval gates and allow-lists do not scale to thousands of autonomous actions per hour, and they ignore uncertainty.
• Coordination is ad-hoc. Multi-agent systems lack shared identity, shared memory, and shared protocols. Each integration is bespoke.
• Evaluation is narrow. Benchmarks measure single-turn correctness, not long-episode reliability, recovery, or side effects.

These gaps are not accidental. They exist because agentic systems are genuinely harder to build than the systems that came before. Solving them is the work of years, not months.

My research is organized around a few concrete questions. Each one could occupy a career; together they define a coherent research program.

1. How should autonomous agents represent, update, and forget long-term knowledge while remaining efficient and explainable?
2. What observability primitives are needed when the consumer of telemetry is another machine rather than a human?
3. How can runtime governance be dynamic, uncertainty-aware, and grounded in simulated impact?
4. What identity, memory, and trust infrastructure enables reliable multi-agent coordination across organizational boundaries?
5. How should autonomous agents be evaluated across long episodes, not just single turns?

These questions are not purely theoretical. They are grounded in the systems I have built and the failures I have observed. The goal is to turn hard-won production experience into generalizable research.

I believe the strongest research in this area will come from building real systems, failing informatively, and then abstracting the lessons into theory. I do not want to write papers about systems that do not exist.

My current method is to maintain a portfolio of open-source projects, each addressing a specific piece of the agentic infrastructure puzzle. I write about what I learn. I keep a research journal. Over time, the projects and the writing converge into design documents and, eventually, into a substantial systems paper.

If this vision resonates, I would love to collaborate. You can explore the projects, read the writing, or get in touch.