After Automation: The Framer, Not the Frame, Is Where the Work Still Lives

Dan Shipper (Every) just published After Automation, an essay worth reading in full and worth a response from the European DevOps and platform trenches. His central claim is that the more you automate with AI, the more expert human work shows up — not less. Every has 30 employees, has automated with Claude Code and async agents wherever it could, and hasn't cut a single role. The work has changed shape, not disappeared.

I agree. But the part of the essay that deserves the most attention — and that no "AI transformation" roadmap I've reviewed this year actually names — is the distinction between the frame and the framer. That's the line separating teams who will understand what they're buying over the next two years from teams who will wake up one morning having bought a dashboard.

The paradox some are already living without realising it

Shipper puts the paradox in one clean sentence: "Making expert work cheaper does not simply replace experts. It creates more situations where expert judgment is needed."

Let me translate that into my world. When we drop Claude Code, PR-review agents and LLM-driven pipelines into a platform team in banking or healthcare, I don't see the team shrink. I see:

• More PRs opened per unit of time, because the marginal cost of opening one drops.
• More architectural decisions per week, because every PR now forces one — on data residency, authorisation, regulatory blast radius — that friction used to silently absorb.
• More time spent deciding what is worth automating, because automating the wrong work is now cheap and fast, which makes it more dangerous, not less.

The head of platform who was expecting AI to shrink headcount instead runs into the inverse question: how do I scale the senior judgment needed to filter the volume the agents are now producing? That question is not a criticism of AI. It is the evidence it's working.

It's the same pattern I read in Microsoft's ActionNex numbers: 71% precision, 53% recall over real Azure outages. The system works well enough to deploy and not well enough to be autonomous. The consequence isn't "fewer SREs"; it's SREs with a larger decision surface because they're now reviewing recommendations at a cadence that didn't previously exist.

The frame, the framer, and why this is the distinction that matters

The most underused part of Shipper's essay is this:

The frame is not the framer. […] Humans know about what needs to be done, right now.

Let me unpack. A benchmark measures model performance inside a frame — a specific prompt, a specific dataset, a specific definition of "task completed". When a model saturates that frame, the industry moves the frame: we stop measuring "writing the code" and start measuring "deciding when to rewrite the code". The new frame scores 60 again and everybody panics on cue.

Shipper calls this Zeno's Paradox of AI. I'd call it something more operational: the framer is the role that survives, and it's the role most roadmaps don't name because they don't know how to budget for it.

Three practical consequences no AI pitch I've heard this year addresses directly:

1. Vendor frames expire before vendor contracts do. If you buy an "AI platform for operations" today on the strength of a capability that demos inside a specific frame, the frame will shift before the budget cycle ends. What you bought is not the capability — it's the promise that the vendor will reframe before you do. Often they won't.

2. The framer is not a job title. It's a distributed function. In a platform team, the framer is whoever decides which workloads are worth automating this quarter, under what compliance, energy and risk constraints, with what acceptable error budget. It's not the ML lead. It's not the VP of Engineering alone. It's the two of them composed with the regulator in the room — and it's the most under-staffed role I see today.

3. In regulated sectors, the frame is a regulatory artefact. This is the part Shipper, writing from a B2B SaaS perch, doesn't need to spell out. But for a client in banking, healthcare or the public sector, the frame itself — what counts as a "correct decision", what counts as "PII", what counts as a "reportable incident" — is defined by the regulator. By definition, it can't be delegated to a model trained on yesterday's frame. The framer here isn't optional. It's where the legitimacy of the system lives.

The toddler analogy — and why it's more awkward in production than it looks

Shipper compares current agents to a toddler: they have agency, they want things, they pursue self-directed goals nobody handed them. LLMs don't. They execute frames they're given.

In enterprise production, that distinction is more awkward than it looks for two reasons:

• We want agents not to have agency. An agent with emergent goals in a regulated environment is a problem, not a promise. The Silicon Valley narrative of "AGI with a will of its own" is exactly the opposite of what a CISO will sign off on. So the limitation Shipper names — "models execute someone else's goals" — is, in my sector, a feature, not a defect.

• But that means the cost of specifying the goal well doesn't drop, it climbs. If the agent doesn't self-direct, every authorisation, every constraint, every success criterion has to come from a human — and the quality of the output is gated by the quality of the frame, not the quality of the model. A team scaling agents without scaling the quality of its frames is manufacturing slop at industrial speed with an ISO certificate stapled to the side.

This is the reading I'd add to Shipper: the "framer" isn't only a product or strategy role. In regulated environments, the framer is the most poorly documented control in the full sociotechnical system, and the auditors will get to it before 2027.

The asymmetry no vendor will explain to you

Shipper observes that models only know about work that has been done. Humans know about work that needs doing right now. That asymmetry has a procurement consequence that shows up on no vendor deck:

When an AI vendor pitches you a new capability, they're showing you performance on snapshots of the past: code already written, incidents already resolved, contracts already signed. What they can't demo is performance on this quarter's problem, because this quarter's problem isn't in anybody's training set yet. So:

• The gap between demo performance and production performance is not a vendor bug. It is structural.
• That gap is closed by the human framer — which the vendor doesn't sell you, because it isn't their product.
• True system cost = licence cost + cost of the human framer who keeps it relevant. Most business cases only budget the first.

If your AI business case this year doesn't have a line for "senior headcount to keep the frames current", the business case is incomplete. The line isn't large. But it isn't zero, and without it the system drifts.

What I'd put on the roadmap this quarter

For a platform or engineering team in a regulated sector, three concrete moves in response to Shipper's essay:

1. Name the framer role on the org chart. You don't have to create a new title. But somebody concrete needs to have it written into their job description: "defines the frames under which our AI systems operate, reviews them quarterly, and is the point of contact with compliance when the frame changes." If nobody owns this in writing, everyone owns a slice and nobody owns it well.

2. Audit the training-set asymmetry. For each AI system in production, build a table: which vendor frame did you buy, what data trained it, what business decisions have changed since. The distance between those two columns is the invisible technical debt. It's probably larger than you expect.

3. Budget for the work after automation, not before it. The cost of the system isn't the cost of deploying it; it's the cost of keeping it relevant while the frame shifts underneath. A PR-review agent deployed in January 2026 against a Python 3.11 monolith isn't the same system in December once you've migrated to Go microservices. The frame has changed. Someone has to redefine it. That someone is a line item, not a volunteer.

The line I draw

I'm on the record as positive on LLMs and agentic systems in production. We deploy them, we bill them, clients pay me to do it. What I see — and what Shipper's essay articulates better than most — is that the real automation win does not show up on the "FTEs reduced" line of the business case. It shows up as "decisions per week we weren't making before", "PRs per week we weren't opening before", "incidents per month we weren't catching before". None of those lines cut cost. All of them grow capacity. That's the honest conversation.

And behind all of it, there is always someone defining the frame: what's worth deciding, what's worth opening, what's worth catching. That someone is not substitutable by any model trained on the past, because the question moves faster than the training cycle. If your AI programme this year hasn't named the framer — not just the frame — you're building a system that will age at the vendor's pace, not your business's.

The interesting work, as usual, happens just to the side of where everyone is looking.

---

Sources:

• Dan Shipper, After Automation, Every, May 2026. every.to/p/after-automation

Putting agents and LLMs into production in a regulated environment and not sure who owns the framer role on your team? Talk to a CTO — we help separate the frame from the work of the framer before the regulator does it for you.