There is a particular kind of waste I’ve been committing for about a year: doing the thinking, and not keeping it.
Since July 2025 I had the opportunity to be co-technical lead on an agentic AI initiative at a worldwide publisher. That means I spend my working days at the sharp end of problems the safety literature discusses in the abstract: prompt injection, tool-use failure, the gap between how a system behaves in an eval and how it behaves in production. And the much less glamorous question of who signs off on shipping it.
That work has extended well beyond its original scope, and it’s where the safety interest comes from rather than something running alongside it. I conceived, built and now run an internal AI platform used by around 2,000 colleagues — a single submission chokepoint for the organisation’s AI builders, most of them outside engineering, with scanning on the way in, sandboxed runtime isolation and deploy tokens. Which means I don’t propose controls, I ship them and then find out what they miss. Four years leading DevSecOps before that makes attestation and chain of custody ordinary trade, so porting them into AI deployment is a port, not an invention. The same is true of agent identity: “which agent, using which tools, was allowed to spend what” stopped being a design question and became a safety one.
Alongside that I’ve been reading, building small harnesses, and working out which skills I need next in order to be confident that what I ship is safe.
All of it lives in markdown files on my laptop. None of it is written down anywhere a reader could find, argue with, or hold me to.
This is the first of a series of posts written retrospectively from those notes. They are dated to when the thinking happened, not to when I published them. That feels like the honest way to do it: I’m not going to pretend I had these thoughts today, and I’m not going to smooth out the parts where I was wrong or undecided.
Why the deployment layer is worth writing from
The standard story about how you learn AI safety goes: read the research, do the course, join the community. I came at it from the other direction. I have fifteen years in technology, eleven of them writing production code, a Data Science and Engineerng, DevSecOps, Platform and SRE background, and I worked on leading the set up of our first agentic systems that real people depend on. What I lack is the research training. What I have that most people entering the field don’t is over a year of watching what these systems actually do when you point them at a real workflow, with real tool access, inside an institution with real reputational exposure.
My working thesis, (the thing I keep coming back to when deciding what to do next), is that the gap between frontier safety research and everyday production deployment is where a lot of near-term risk lives. Very few people sit in both worlds. The research side produces methods; the deployment side produces incidents. They are not currently in close conversation, and the translation loss between them is not small.
That’s a claim I should be able to defend, and writing is how I intend to test it.
What this series will cover
The notes I’m working from cluster into a few areas:
Where technical skill moves the problem most. Research, engineering and governance are three different ways of acting on the same risk. Which of them a given person should invest in is a live question, and I’ve been working through mine in the open.
The hardest tension I’ve found in the field. Narrow AI has produced the clearest demonstrated benefits; the incentive gradient points at general agentic systems, which is where the risk concentrates. I live a small, local version of that tension every week.
Verification, mechanistic interpretability, and agent identity. July and August 2026 went deep on the questions the deployment work keeps raising. How do you verify what a system is actually doing? Is mechanistic interpretability even feasibly achievable at the scale that would make it useful? What does identity mean for an agent acting on someone’s behalf? Those notes, on what makes a good research question and what a null result is worth, are the ones I’d most like to have had on the record as I went.
Prompt injection as a mechanistic problem rather than an input-validation problem. This is the one that changed how I think about my own production mitigations.
Benchmarks, baselines, and being suspicious of your own numbers.
The rule I’m setting for myself
Everything here is written from my own notes and my own work. Where I’m quoting someone, Hinton on incentives, Neel Nanda on what makes research good, a paper’s central claim, I’ll say so and point at the source. Where I’m speculating, I’ll mark it as speculation. Where I later turned out to be wrong, I’d rather write the correction than quietly edit the post.
The point of a public journal isn’t to look like I knew what I was doing. It’s to make the reasoning inspectable, to me, six months later, and to anyone who wants to tell me where it breaks.