A series for engineering leaders

The Agentic CTO

Your company bought the AI tools. Every engineer has a licence. And the delivery graphs look exactly like they did last year.

That’s not a tooling problem — it’s an operating model problem. Copilots make individuals faster. They don’t change what your org can do, because the process around them still assumes humans do every step. Six parts on rebuilding that process, written from inside an org that already works this way.

Written for CTOs, VPs of Engineering and technical founders running teams of roughly 5–100 engineers, somewhere between “we bought licences” and “agents ship unsupervised”.

1,000+pull requests
1full-time engineer
2gates humans hold

One production repo, one full-time engineer. How these numbers were counted →

Where to start: read Part 1 for the operating model. If you already run agents and want the objection answered first, start with Part 4.

Part 3

Your agents react

Incidents, alerts and inbound bugs. The reaction ladder agents climb while you sleep, the weekend our pager stayed silent, and the backlog that triages itself.

Read the article →

Part 4

Securing the agentic org

Blast radius beats cleverness: a free-fire staging zone, read-versus-write production, a break-glass agent behind MFA — and why your ticket tracker is an attack surface.

Read the article →

Part 6

Your sceptics are right

The greybeards are correct about AI code quality and the worried are correct that the org changes. You don't win either group with hype — you win them with a harness and honest maths.

Read the article →

What I actually do

An agentic engineering operating-model review

Bought the tools and the graphs didn’t move? Here is how I move them — over a handful of sessions with you and, where it helps, your leads:

  • Find where agents are creating activity without outcomes — and what that is costing you.
  • Map your SDLC and pick the first step you can safely delegate, with the guarantee it has to keep.
  • Define the human gates and the autonomy thresholds that let the rest run unattended.
  • Set the baseline delivery and quality metrics you’ll be judged on — before you scale anything.
  • Design the security model: environments, read-vs-write, break-glass, untrusted input.
  • Coach you through the adoption — the part that is about people, not tooling.

Book a first conversation

Who’s writing this

I’m Ben Jones. I was CTO of an engineering org of 50+ and scaled Nuri to 120 people. Today I’m co-founder and CPTO at Herita — the repo behind the numbers above — and I coach CTOs and VPs of Engineering through this shift.

Not sure which of these is your bottleneck?

That’s usually the first thing we work out together. Tell me what your delivery looks like now and I’ll tell you what I’d change first.

Get in touch

Or follow along on LinkedIn →