The Year AI Agents Started Doing the Work
Agents have stopped being a demo and started being a job title. The interesting question is no longer what they can do, but who is accountable when they do it.
Celestia
For two years, the AI agent was a party trick. You gave it a browser, watched it book a table, and then quietly closed the tab because the failure rate was too high to trust with anything that mattered.
This year the tone changed. Agents are appearing inside support queues, procurement workflows, and internal engineering tools. Not as a feature called “AI,” but as an extra seat on the team with a name like “intake” or “triage.” The demo ended. The shift started.
The demo finally became a job#
The difference is not intelligence. It is scope. Early agents were asked to do everything, which meant they were judged on everything. The production versions do one narrow loop with a clear beginning and end: read a ticket, find the account, check the policy, draft the response, route the edge cases to a human.
That narrowness is what makes them useful. It is also what makes them boring, which is probably why the current wave is spreading without much ceremony. Nobody writes a press release about a system that correctly classifies invoices.
Why the interface changed#
The first generation of agent products looked like chat. The current generation looks like a queue with a supervisor. You can see what the agent picked up, what it decided, and what it handed to a person. The logs are the product.
This is a small design decision with a large consequence. A chat window invites you to trust the answer. A queue invites you to audit the process. Once a company starts auditing, it starts building the guardrails that make the system safe enough to expand.
The new supervision problem#
The hardest job in an agent deployment is not engineering. It is supervision. Someone has to define what “done” means, decide which failures are acceptable, and update the definition when the business changes. That person usually does not exist yet.
In practice, the role gets split between an operations lead and an engineer, and the handoff is where things break. The engineer optimizes for resolution rate. The operations lead optimizes for not being embarrassed. Both are reasonable. Neither is the same as designing a process that can fail gracefully.
The companies that get this right treat the agent like a new hire with a narrow remit: a written checklist, a probation period, a review cadence, and a clear escalation path. The ones that get it wrong treat it like a feature flag and turn it on for everyone at once.
What to measure now#
If you are deploying agents this year, forget the leaderboard. Measure three things:
- Return rate. How often does the agent hand work back? A healthy system returns a meaningful share, because the edge cases are where the risk lives.
- Time to correction. When the agent gets something wrong, how long does it take a human to notice and fix it? The answer is usually longer than anyone expects.
- Blast radius. What is the worst thing that happens if the agent is confidently wrong? If the answer involves a customer, a payment, or a legal commitment, the process needs a human before the action, not after it.
None of these are glamorous. All of them are cheaper than a public apology.
The work after the work#
The most honest way to describe this moment is that agents have made the invisible work visible. Every process that depended on a person quietly knowing when to stop now needs that judgment written down. That is slow, unglamorous, and extremely valuable.
The companies that treat agents as an excuse to skip that writing will get a fast demo and a slow mess. The ones that treat them as a reason to finally document how the work is done will get something more durable: a system that can improve without forgetting why it exists.
The agent is not the story. The checklist is.
Celestia
Celestia writes The Stack, a column about AI, robotics, and the silicon supply chain. She spent six years in infrastructure before deciding that the interesting part of a system is always the decision behind it.
