The Handoff

AI enablement for teams learning to build differently

Support this blog

© 2026 Liz Baker. All rights reserved.

The Ceiling Is Plumbing

12 Aug 2026

I kicked off a release notes pipeline this week that was built to run end to end with no one watching: pull tags and git logs across three repos, cross-reference eighteen Jira tickets, write the summary, publish it. Fully wired. Fully automated.

It stopped at step one. git fetch failed. My SSH key had expired over the weekend and had gone unnoticed all weekend, including by me, until an agent tried to use it and had nowhere to go.

I spent more time generating a new key and getting it registered than the entire rest of the pipeline took to run once it was unblocked. The smart part worked on the first try. The dumb part was the whole outage.

The ceiling we keep arguing about

Almost every “AI is going to replace X” conversation is an argument about capability. Is the model smart enough? Will it reason through the edge case? Will it hallucinate a fact and ship it? We benchmark reasoning, we compare models on how well they think, and we design our review around the assumption that the risky failure is the model being confidently wrong.

That’s a real risk. It’s just not the one that took my pipeline down, and in my experience it’s not the one that takes most of them down.

It isn’t the thinking, it’s the plumbing

The thing that stops an agentic workflow is rarely a hard problem. It’s an expired credential. A stale token. A permission nobody renewed. A service account whose password rotated on a schedule this job never accounted for. The ceiling on how far you can automate isn’t reasoning. It’s access, auth, and the mundane infrastructure a human babysits so the smart part can do its job.

That expired key is the same outage software has had for decades. It isn’t a new class of bug that agents introduced. It’s the oldest, most boring bug there is, and it predates every model on the market.

What changes with an agent is who’s standing there when it fails. A human hits an expired key mid-task and barely registers it as an interruption: they reissue it, or route around it, or ping the team who can resolve it, and keep going. The failure and the fix happen in the same motion. An agent hits the same expired key and halts. It has no standing to generate a new credential, no judgment about whether it’s safe to, and nobody in the loop to improvise past it.

And because the work is a chain, the halt is complete. My eighteen-ticket cross-reference never ran, because step one never returned. The summary never got written, because there was nothing to summarize. One expired key at the start took the whole stack down, and the only reason I found out is that I went looking for the output.

The boring layer

If you’re going to take the human out of the loop, the babysitting they were doing has to go somewhere. So here is the foundation they were holding up:

Each item on that list points to something that you can build a process around. Give the agent its own service identity instead of borrowing your personal key, so the pipeline’s access doesn’t expire because you changed your password. Monitor the credentials the way you already monitor the model: something should be watching that key’s expiry and telling you a week out, not letting an agent discover it at runtime. And check the plumbing before the run, not during. A thirty-second preflight that confirms every credential the job needs is still valid turns a silent 2am halt into a check that fails loudly while you’re awake.

None of that is clever. That’s the point. It’s the layer we skip because it isn’t interesting.

What you get for the trouble

Instrumenting the boring layer has a payoff past not getting paged. To health-check every credential a job depends on, you first have to enumerate them, and once you’ve done that you’re holding something most teams never had: an exact inventory of what the automation touches. Every key, every scope, every system it reaches into, written down in one place.

That inventory is worth having on its own. It’s the thing a security review asks for and few teams can produce. It’s how you answer “what breaks if we rotate this?” without guessing. You were building it to keep the pipeline alive, and it doubles as the access map you never wrote for the humans either.

The overhead was already there

The fair pushback is that this is all overhead. The whole promise of an agent was to remove work, and here I am adding a preflight check, a monitoring rule, and a service account to stand up before the interesting part runs at all.

But that work didn’t appear when I automated the pipeline. It got uncovered. A human running these steps by hand was absorbing all of it invisibly: noticing the key was old, refreshing the token without a second thought, knowing which proxy to ask about. Take the human out and that work doesn’t leave with them. It stops getting done, and either you pick it up on purpose or it comes back as an outage. You’re not adding overhead the agent created. You’re paying, up front and on purpose, for the babysitting a person used to do for free.

The alternative isn’t less work. It’s the same work, discovered later, in worse conditions, with the whole pipeline dark behind it.

The unglamorous half of enablement

I spend my time trying to help teams automate more of their work, and the temptation in that job is to make it a story about the model: pick the smart one, prompt it well, watch it reason. But the release notes pipeline didn’t stall on reasoning. It stalled on a key, at the boring seam between the agent and the thing it needed to reach, and no amount of model capability was ever going to clear it.

So whatever you’re handing to an agent, spend real attention on the layer underneath it. The reasoning is the part that gets the headlines. The plumbing is the part that decides whether the reasoning ever gets to run.

Related Posts