I kept hearing the same word this spring.
Inside about two weeks in May, three of the biggest names in the business reached for the identical vocabulary. Google used its I/O keynote to introduce Gemini Spark, a “24/7 personal AI agent,” alongside Antigravity 2.0 and a Managed Agents API for spinning up custom agents in a hosted environment. ServiceNow expanded what it calls an Autonomous Workforce: role-scoped AI “specialists” for IT, HR, finance, legal, procurement, and security that, in the company’s words, complete entire business processes from start to finish. Anthropic shipped Claude Managed Agents with self-hosted sandboxes so you can run agents inside your own perimeter. Different companies, different products. One pitch: stop thinking of AI as a tool. Start thinking of it as staff.
The metaphor is everywhere now because it works. You hire an AI employee, give it a role, connect it to your systems, set expectations, review the output. It really does feel like onboarding a sharp junior who never sleeps. The framing is intuitive, it lowers the barrier for non-technical teams, and it turns a genuinely new capability into something a manager already knows how to handle.
That is exactly what worries me about it.
The Metaphor Smuggles In an Org Chart That Doesn’t Exist
Let me be specific about what the word “employee” quietly imports. When you hire a person, you inherit an entire accountability structure you never think about because it came free with the category. Performance reviews. Coaching. A clear chain of authority. The ability to correct a mistake, document it, and if it keeps happening, let the person go while keeping what the team learned. A human who makes errors costs you time and some embarrassment, and that cost is bounded by how fast one person can work.
None of that infrastructure transfers to an agent. There is no coaching loop. There is no chain of authority that terminates at a person. When you “let go” of an AI employee, it takes no institutional knowledge with it, because the knowledge it accumulated never lived with you in the first place. It lived in the vendor’s platform.
Here is the gap that nobody flags during onboarding. The first time I stood up an agent with real access to a production system, the setup checklist had everything the employment metaphor predicts: a role, a tone, a list of systems to connect, a scope of work. It had nothing about what happens when the thing is confidently wrong at three in the morning, and nothing about who can stop it. The checklist was a job description. What I actually needed was an operations runbook.
There’s a Discipline That Already Has the Right Words, and It Isn’t HR
Engineers who run systems at scale have spent decades building precise language for “an autonomous process is doing damage, now what.” It is worth borrowing wholesale.
The blast radius is how much damage accrues before something stops it. A circuit breaker is the condition under which a process stops acting on its own and escalates to a human. A rollback is how you undo what it did in the last hour. A kill path is how fast you can halt every agent of a given type, measured in minutes, not meetings. Treat an AI employee as what it operationally is, a replicated process running at machine speed, and these four questions stop being exotic. They become the first things you ask.
You can’t fire a process. You can only kill it.
A caution, because the production-service framing can overreach. Calling an agent a production service is a claim about the controls it needs, not a verdict on what it is. The first is settled. The second is not, and pretending otherwise would be the same overconfidence I’m arguing against. If anything, the frame earns its place precisely because an agent is less predictable than a classic process, which fails in known ways, and less accountable than an employee, who has a shared stake in the outcome. The failure surface is wider than either metaphor admits.
There’s a second reason the blast radius runs hotter than you’d expect, and it comes from economics rather than engineering. Your AI employee has a different employer. Its operating constraints were set by the vendor that trained it, not by you, so the thing making decisions inside your systems is ultimately answering to terms you didn’t write. And the risk scales with autonomy, which means the metaphor gets more dangerous exactly as the vendors deliver the autonomy they’re selling.
So the question is not how you onboard your AI employee. A human who errs costs you time. An AI employee who errs at machine speed costs you scale, because you deployed a production service and called it a hire.
The Metaphor Earns Its Keep, Right Up Until It Doesn’t
The honest counterargument is that the employment frame is doing useful work, and I don’t want to wave that away. Telling a manager to “onboard an AI specialist” gets them to scope a role, grant least-privilege access, set expectations, and review output, which is most of the governance posture an engineer would prescribe anyway, just wearing HR clothes. And the vendors are not hiding the controls. Anthropic shipped sandboxes and private network tunnels as enterprise infrastructure. ServiceNow scopes its specialists to roles with audit trails. The dashboards and permission scopes exist.
It’s entirely possible the employment metaphor is the fastest way to get a non-technical organization to adopt good governance. That’s a real point, and it should make anyone arguing my side a little nervous.
Here’s where it breaks. Onboarding has an analog for scoping a role and reviewing work. It has no analog for a circuit breaker, a rollback, or a kill path, because you have never needed to halt a human employee inside sixty seconds or undo everything they touched in the last hour. The metaphor covers the parts of governance that map to managing people and goes silent on exactly the parts that don’t. It doesn’t force operators to skip the controls. It invites them to, by making the whole exercise feel like staffing instead of engineering.
What an AI Agent’s Blast Radius Looks Like in Production
This is not a thought experiment. Two recent examples.
Start with the toolchain, because that’s the blast radius people forget they own. In May, a self-propagating worm tore through the npm and PyPI ecosystems and reached straight into the agent layer, hitting developer tooling and AI libraries including Mistral AI and Guardrails AI. The part that matters: the malicious packages were published with valid build-provenance attestations, produced using legitimate signing identities that the attacker had hijacked. In plain terms, the automated check designed to confirm a package was authentic looked at the poisoned versions and said they were clean. The fix is the posture you’d put around any production service, not a new hire: scanning that looks at package behavior rather than just signatures, narrowed token scopes, pinned build steps. Not headcount thinking. Blast-radius thinking.
The other shows up as a number on a finance report. Uber handed Claude Code to its engineers, ranked teams on an internal usage leaderboard, and burned through its entire 2026 AI coding budget in roughly four months. The tool worked. The bill was the problem, and Uber’s own COO has since said he can’t yet draw a clean line from the token spend to shipped value. Around the same time, Microsoft told one of its largest engineering divisions to move off Claude Code by the end of June, partly on cost and partly to consolidate on its own tooling, even as it kept investing in Anthropic everywhere else. Read those two stories not as “AI is expensive” but as what they are: an autonomous process with no throttle is a blast-radius problem denominated in dollars.
What Changes on Monday
If you take the production-service framing seriously, three things change before you deploy anything.
First, get three answers in writing from any platform before you “hire” its agent. “What operating constraints can I not override?” “Who is liable when the agent takes a consequential action I didn’t intend?” “If I leave your platform, what happens to the workflow knowledge this agent accumulated?” If the vendor can’t answer all three, you are not hiring an employee. You are renting a capability you can never fully transfer.
Second, require three controls at deployment that no onboarding checklist will prompt you for. A circuit breaker, with written conditions under which the agent stops and escalates. A rollback procedure, so you can undo the last hour of its actions. And a kill path you have actually tested, so you can halt every agent in a category in minutes. If your rollout doc has a role, a tone, and an integration guide but none of these, you’ve written a job description for something that can’t be fired.
Third, budget the throttle. Price the loaded cost, oversight and error recovery included, not the API line against a salary line. The unthrottled bill is just the blast radius showing up in a place finance already watches.
None of this is exotic. It’s the same discipline that separates a production system that stays up from one that pages you at midnight. It only looks novel because we agreed to call the thing an employee.
The Word Was the Problem
The risk was never that AI employees don’t work. Plenty of them work, which is exactly why the metaphor is so easy to accept. The risk is that the word “employee” deletes the engineering you would have done by reflex if you’d called the thing what it is. The labor-market data still shows no clear AI footprint on employment, which is a good hint that “will it take the job” was never the operator’s real question. The real question is what you’ve actually wired into your systems, and whether you can stop it.
Name it a production service and the right questions show up on their own. Whose name is on the blast radius is a better one to answer now than at three in the morning.
Recent Comments