← All posts
ThoughtsJuly 20, 2026

The Coming AI Layoffs Should Be Agents, Not Engineers

Most of us are guilty of anthropomorphizing agents when it is useful for a demo. But the flip side is also often true: companies dehumanize employees when it is useful for a budget.

We introduce agents as never sleeping teammates. We give them a name, an avatar, and sometimes even a launch announcement. And if the experiment underperforms, the cost gets folded into “AI transformation.” The human team is then asked to justify its existence against the theoretical productivity the agent was supposed to create.

But I think that accounting is backward.

An agent workflow is software with variable inference cost. It should have an owner, a purpose, a success condition, and an operating history. If it can’t show what it produces, it isn’t a digital employee.

Why are we not reviewing deployed workflows and removing the ones that don’t earn their cost before we start cutting engineers? The easiest spreadsheet answer will be to say AI lets the company operate with fewer engineers. But that answer should not survive after we look at the session data.

Before cutting the humans who understand the systems, we should terminate the agent workflows that are failing, duplicating work, looping, or producing output nobody needs. The coming AI layoffs should be agents, not engineers.

Give the agents a performance review

For each recurring workflow, ask:

  • How many sessions did it run in the last seven and 30 days?
  • How many completed, failed, or were abandoned?
  • What was the total spend and spend per successful run?
  • How much agent time and how many tool calls did success require?
  • Which models drove the cost?
  • Are the longest sessions genuine deep work or repeated failure?
  • Did the output ship, inform a decision, or become reusable knowledge?

paper console already captures the raw material for this review: session status, cost, tokens, duration, tool calls, model mix, success rate, and recent time windows. Suggestions flag cost outliers and spend on unfinished runs. The session list makes running work visible instead of waiting for it to appear on an invoice.

a3f8c21dRunning
wire outcome detector into cursor cache$18.40
brian(You)
Claude Fable 5+2
d91b04eeCompleted
fix flaky export-sessions test$2.10
maya
Claude Sonnet 5
7c25e9baCompleted
migrate span search to direct reads$31.75
brian(You)
Claude Opus 4.8+1
f04a77c3Completed
scaffold billing exporter cron$6.88
devon
GPT-5.2 Codex+1
58e1d20fFailed
triage grove sync failure$1.04
maya
Claude Haiku 4.5
Live demo — hover a model chip with a +n badge for the cost breakdown

We’re not ranking engineers here. We’re reviewing automated systems.

I want that distinction to be explicit. A failed agent run might show a broken tool, missing context, or an unreasonable task. Those are conditions the organization should fix, not evidence that the person supervising the agent is unproductive.

Some agents need training. Some need severance.

Not every weak workflow should be deleted immediately.

A repeated failure may point to a missing skill. A long setup phase may be compressible into a reusable procedure. A high-cost model may be doing work a cheaper model can complete. A brittle tool integration might need repair. A task might need a clearer definition of done.

Those workflows deserve intervention and another measured attempt.

Others should be shut down:

  • The background agent whose output nobody reviews.
  • The automated report that reproduces data already available elsewhere.
  • The code-review bot that generates comments developers habitually dismiss.
  • The retry loop that treats an unavailable permission as a reasoning problem.
  • The agent launched because leadership wanted an “AI use case,” not because a user needed the result.

Deleting these workflows is not anti-AI. It is what mature adoption looks like.

No company proves its cloud sophistication by preserving every container it has ever started. Agent count shouldn’t be the next vanity metric either.

Preserve the institutional knowledge before you cut

When a workflow is retired, its history shouldn’t disappear.

Export the session data. Preserve representative failures. If the agent discovered a procedure worth keeping, generate a skill from the successful sessions and publish it to the team library with an author, source links, and a version.

The workflow may not deserve to run continuously, but the knowledge it produces may still save the next engineer hours.

This is one reason session-level records matter more than aggregate ROI decks. They allow a company to separate the disposable automation from the durable learning.

Humans are not the rounding error

Engineers do more than produce code. They decide which problems matter, negotiate constraints, recognize when requirements are incoherent, carry historical context, review risk, and take responsibility when the system fails.

Agent sessions depend on that environment even when the dependence is hidden behind a prompt.

Cutting engineers because agent spend rose is especially perverse. It removes the people most capable of diagnosing why the agents are expensive and whether their output is safe.

The right cost question is, “Which work should exist, which parts should be automated, and what evidence shows the automation is helping?”

If leadership can’t answer that at the session level, it’s not ready to answer it at the headcount level.

Terminate your zombie workflows. Retrain the fixable ones. Turn the successful patterns into shared skills. Keep the humans who can tell the difference.

Those are the layoffs an AI-native company should make first.

Found this useful? Share it.
ShareY
← OlderYour Engineers Are Running Fable 5 on Merge Conflicts

Start with paper

Turn every session into knowledge at team scale.

Get started