I run live television. The rest of the time, I build AI.

That's the short version. For two decades I've led technical and production teams in live broadcast, in the control room, getting the show to air live, where it works the first time in front of everyone or it doesn't count. The rest of my time goes into building software, and funnily enough it runs the same way: I'm in the director's chair, AI agents are the coding team, and I steer the whole production until the thing I set out to make is real.

One of those jobs is pure process and signal flow. The other is people, judgment, and timing. Both taught me to think in processes first: to see the whole sequence of how work moves, where it hands off, and where it breaks, before building anything. That is the lens I bring to AI. Live TV has one rule: it works the first time, in front of everyone, or it doesn't work at all. You learn to see where something will break before it does, and to stay calm when it breaks anyway. That's the instinct I bring to building, and AI turns out to need exactly that kind of hand on it.

The part most teams skip is the part I obsess over: what the system does when the AI is wrong, who catches it, and how fast it recovers. That is the difference between something that wows in a demo and something you can still trust six months in.

I came to this without the usual on-ramp and learned it by building real things and hardening them until they held under real conditions. What I care about is whether the thing works when someone is depending on it.

If you have a system that needs building, or a prototype that breaks under real conditions, this is the work I do: architect it from first principles, build it to hold, keep the human approval gates clear, and hand it back in plain language.