About

I took a somewhat unusual path into engineering.

I am self-taught and entered software engineering without a traditional computer science degree. Rather than a liability, this background forced an intense, practical appetite for understanding difficult and unfamiliar systems from first principles.

My career progression—from technical support into software engineering, then principal architecture, and now leading agent infrastructure—was driven by volunteering for the hardest systemic problems I could find.

The recent identity and agent work rests on a broader systems background: TCP/IP and DNS, HTTP and TLS, Linux, concurrent programming, distributed state, multi-region services, containers, performance engineering, failure isolation, and production operations. I care about the behavior beneath an abstraction because that is where reliability and security properties are ultimately won or lost.

Today I lead the open-source engineering and major specification work for Agent Name Service as it moves toward Linux Foundation governance. In parallel, I lead GoDaddy's ANS Registration Authority implementation and wrote the transparency log that makes its agent-registration state independently auditable.

I also participate directly in Agentic AI Foundation technical meetings and working groups, bringing an Internet infrastructure, identity, and security perspective to the broader open-agent ecosystem.

How I think about engineering

  • Understand the system beneath the abstraction. Abstractions leak. You cannot secure or operate a system at scale if you only understand its interfaces.
  • Reason from invariants. Distributed systems fail in unpredictable ways. Design around core properties that must remain true regardless of failure mode.
  • Eliminate accidental complexity. Enterprise software often accumulates complexity for organizational reasons rather than technical ones. Ruthlessly prune it.
  • Optimize for operability. A system is only as good as the ability of an exhausted on-call engineer to understand its failure state at 3 AM.
  • Distrust security claims not backed by implementation. Architecture documents don't stop attacks. Cryptographic proofs and fail-closed code do.
  • Favor simple primitives with strong properties. Overly clever protocols break. Append-only logs and verifiable signatures scale.
  • Learn whatever domain is necessary. Never say "that's not my area." If a problem requires learning RFCs, Rust, or PKI, learn it and solve the problem.

Outside of work

When I'm not untangling distributed systems, my time goes toward lifting, golf, dogs and dog sports, photography-business technology, and continuing to build things with my hands.