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.

The post Your AI Employee Needs a Circuit Breaker, Not an Onboarding Plan appeared first on Top Rope Media.

In a single eight-day window, three frontier labs converged on the same playbook. On May 4, Anthropic launched a $1.5B joint venture with Blackstone, Hellman & Friedman, and Goldman Sachs. On May 11, OpenAI launched DeployCo — a $10B PE-backed consulting venture anchored by TPG and 18 other investors. The day after that, Google Cloud announced its own forward-deployed engineer team. All three reached for Palantir’s vocabulary.

The industry read has been sharp and largely celebratory. The labs finally admitted that deployment, not capability, is the bottleneck. They committed real money and real engineers to it. Stratechery framed the economics cleanly. Bloomberg and Fortune covered the deals like a strategic awakening. LinkedIn is gushing about “AI labs disrupting consulting.”

It’s a tidy narrative. The labs are putting their best engineers in your building. The deployment problem is being solved by people who actually know how. As OpenAI’s Chief Revenue Officer Denise Dresser put it, “deployment, rather than technology capability, is the key bottleneck to wider AI adoption.”

But read the deal terms, not the press releases.

OpenAI committed a guaranteed minimum 17.5% annual return to its PE backers on $4 billion of the DeployCo structure — and capped the upside. That’s roughly $700 million owed to TPG and the rest of the 19-investor consortium every year before DeployCo earns a dollar of profit. FT and Reuters reported it. It wasn’t in OpenAI’s launch announcement.

Where does that $700 million come from? Not from OpenAI’s existing token revenue — that business doesn’t profit. It comes from the DeployCo customer engagements. Which is to say: from you.

A detail buried in the investor list makes the structure unmistakable. Bain & Co., Capgemini, and McKinsey are also among DeployCo’s backers. The legacy consultancies are funding their own disintermediation. Which tells you they see this as a fee-based services business worth owning, not a venture bet.

The FDE engagement isn’t a service line. It’s a recovery vehicle for a capped, guaranteed return.

Who Pays the Engineer in Your Building

Start with the plain version. The engineer in your building works for the people paying them — and the people paying them just committed to a 17.5% guaranteed return on $4 billion. That’s the structure in one sentence. The mortgage broker knows it. The insurance broker knows it. The lawyer billing by the hour knows it. Anyone who has sat across from a professional whose employer wasn’t them has seen what happens: the advice tilts toward what keeps the engagement going.

The economic literature has a name for this — principal-agent theory — and forty years of catalogued failure modes: agents under-disclose, optimize for what they’re measured on, recommend solutions that compound dependence. The vocabulary is useful for citation. The observation doesn’t depend on the vocabulary.

Apply it to the forward-deployed engineer. The FDE has information advantages over you — what to build, what model tier to use, what counts as “advanced,” which workflows are tractable to AI and which aren’t. Their performance is measured in token volume, contract renewals, and platform lock-in. Their career is structured around the lab’s commercial growth, not your operational outcomes.

What makes DeployCo different from ordinary principal-agent failure is the 17.5% fixed hurdle rate. A services vehicle carrying that obligation isn’t running a normal P&L — it’s running leveraged-buyout economics. Investors capture a guaranteed return; operators inside the structure are accountable to recover it; everything not in service of the recovery is overhead. The PE return isn’t a side fact. It’s the load-bearing constraint that determines what the FDE is allowed to recommend.

Your AI consultant has a hurdle rate.

The Conflict Already Exists at Smaller Scale

The small-scale version of this conflict has been running in my work for two years.

Integration engagements regularly hinge on a decision about which model vendor gets more workflow traffic. Every time that decision comes up — Claude or GPT or a smaller open-source model — the agency relationship goes live. My agency’s revenue, the client’s outcomes, and vendor relationships built over years are not always pointing in the same direction. Doing the work honestly means making the conflict explicit: telling the client what’s actually being optimized for, and letting them decide.

The FDE engagement is the same conflict, scaled up by orders of magnitude and obscured by a deal-term filing nobody reads.

A second case comes from the buyer’s seat. I lead product on a multi-million-member professional association’s AI-augmented panel review system. Among the open questions: should the grammar feature be built on Grammarly or on the Claude API? In a rational evaluation, the answer depends on the use case, the cost per panelist-document, the integration burden, and the long-run governance posture. I get to give the vendor-neutral answer because my principal is the association. An FDE working through the same evaluation as part of a DeployCo or Anthropic-JV engagement would not. The structure of the engagement forecloses the recommendation before the analysis begins.

The third case is the one the FDE narrative borrows its credibility from. Palantir.

Palantir’s flywheel works because each FDE engagement feeds product. The engineer sits inside customer operations, finds repeated problems, and encodes those patterns back into platform features. The FDE is a product-discovery mechanism, not a revenue line. Beam.ai surfaced this distinction in mid-May: services inform product, product reduces the need for services, and each deployment makes the platform better for every customer.

OpenAI’s DeployCo is structurally different. Each engagement feeds distribution — API calls, inference workloads, compute demand flowing back to OpenAI’s infrastructure. Beam called it a “compute-pull strategy built on a services wrapper.” Same vocabulary. Structurally different business.

What About the Talent-Access Argument

The strongest version of the case for FDE engagements goes like this. Even if the FDE’s incentives aren’t aligned with yours in some abstract sense, you still benefit from access to engineers who actually know how to ship production AI. The market for that talent is brutal. Mid-sized companies cannot hire it. A vendor sending someone to your office for six months at a quoted rate beats not having that capability at all. The conflict of interest, on this view, is the price of admission to a workforce you couldn’t otherwise touch.

There’s something real in this. The talent shortage is genuine. The expertise gap on integration patterns is genuine. I would not argue that operators should skip outside help on a complex AI build.

The argument also rests on a hidden assumption: that the operator’s alternative is a competent internal team. For most enterprises, the alternative is no AI deployment at all — and if the FDE is the only path to deployment, the principal-agent concern starts to look like a price-of-admission argument rather than a refutation. But the FDE engagement isn’t positioned as last-resort access. It’s marketed to operators with internal hiring capacity that just moves slowly. A 17.5%-yielding services vehicle only makes economic sense if the customer base is mid-cap and up. The assumption hides a market segmentation that doesn’t favor the operator who can’t hire at all.

The case collapses harder when you look at what you’re actually buying. The output of an FDE engagement isn’t “your team learned to ship production AI.” The output is “a workflow exists inside your operations that runs on the vendor’s model, and that no one in your organization could rebuild without the vendor.” That isn’t capability transferred. That’s capability rented. When the FDE leaves, the institutional knowledge leaves with the API key. You haven’t filled the talent gap. You’ve made it permanent.

The honest version of the talent-access argument would require the engagement to produce real capability inside your team. None of the current deal structures require this.

What About “You Already Chose the Vendor”

A sharper objection: the operator already chose OpenAI as a vendor before any FDE walked through the door. The conflict of interest isn’t introduced by the engagement — it’s the relationship the operator already signed up for. Calling out the FDE for working for OpenAI is calling out a vendor relationship the operator already chose.

The flaw is that the two relationships aren’t the same instrument. A monthly token contract is reversible — if costs drift or capabilities change, you rebalance to a different model substrate next quarter. The vendor relationship was a month-to-month spend at elasticity. A six-month FDE engagement inside a hurdle-rate-bearing services vehicle is a five-year commitment dressed as a project. It doesn’t continue the dependency the vendor relationship started — it amplifies and locks it.

They aren’t the same scale of commitment. Treating them as equivalent collapses a small reversible choice into a much larger irreversible one. The deal terms don’t.

Four Moves Before You Sign

Four operator moves change if you take the reframe seriously. They cluster into two halves: what to ask before signing an enterprise AI consulting contract, and what to demand if you sign anyway.

Before signing, do two things. Demand a written alignment-of-incentives document. What metric does the FDE’s team get reviewed on? What happens to the engagement if your workload decreases? If those questions can’t be answered in writing, the engagement is structurally pre-loaded for divergent outcomes — and “we’re aligned on your success” is not an answer. Then model the all-in cost the way you’d model a leveraged buyout. Ask what IRR the vendor needs to make the structure work over the engagement’s life, then back out what that implies for pricing pressure on your contract across a five-year term. The 17.5% guarantee isn’t a separate fact from your contract. It’s in your contract.

If you sign anyway, demand a vendor-agnostic workflow specification as a contractual deliverable — a portability artifact. A documented description of the workflow that a competent team that wasn’t the FDE could reimplement on a different model substrate. If your engagement doesn’t produce one, you don’t have a workflow. You have a rental that re-prices annually. And one more thing, the simplest of the four: don’t hire your model vendor’s engineer to reduce your model vendor dependency. The argument is already lost.

None of these are exotic. They’re the same procurement discipline that gets applied to any high-stakes outsourcing relationship — legal counsel, audit, managed services. The FDE engagement is currently being marketed in a register that bypasses procurement discipline. The deals get positioned as a strategic capability investment, not a five-year services contract with embedded yield obligations to a PE consortium. That positioning is the problem.

What This Actually Frees Up

The Palantir flywheel is real. Palantir built it by selling a platform. The labs reached for the same words; they did not reach for the same business. The FDE engagement looks like a service — it’s a sales channel with a capped, guaranteed yield, and the engineer in your building has a different principal. They don’t work for you. They work for OpenAI, and OpenAI works for TPG.

Look at where the money actually goes. PE consortium funds DeployCo. DeployCo deploys engineers to PE portfolio companies. Portfolio companies pay DeployCo. DeployCo pays the PE consortium its 17.5%. The capital never leaves the room.

Let the big firms play in that loop. The FDE engagement is structurally a vehicle that exists because enterprises have procurement departments, board-level approvals, and a tolerance for paying for the appearance of strategic certainty. The labs built a recovery-of-capital structure that sells into exactly that tolerance.

Small and mid-sized operators are not in that vehicle. They can route around it.

The consumer-tier AI stack has caught up to where the enterprise-tier was eighteen months ago. MCP connectors are mainstream. Claude reads your Notion. ChatGPT reads your Drive. Zapier and its successors run the integration layer that used to require a six-figure consulting engagement. A small team with a competent technical leader — someone who understands the substrate well enough to know which pieces to wire together and which to leave alone — can build operational AI capability that would have required a year-long McKinsey deck in 2024.

That’s the asymmetry the FDE structure depends on you not seeing. The consultancy layer exists because procurement requires it, not because the work requires it. The cost curve has collapsed; the procurement requirement hasn’t. The gap is the opportunity.

The big firms will keep selling each other layers of process — it’s where their margin comes from. The real leverage agentic AI unlocks is on the other side of the deal table, with the operators who don’t need the structure in the first place.

Read the deal terms first. Then ask whether you need a deal at all.

The post Your AI Consultant Has a Hurdle Rate appeared first on Top Rope Media.

The post After Integration, the Actuarial Table appeared first on Top Rope Media.