<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>AI agents | Top Rope Media</title>
	<atom:link href="https://topropemedia.com/blog/tag/ai-agents/feed/" rel="self" type="application/rss+xml" />
	<link>https://topropemedia.com</link>
	<description>Marketing for the Outdoor Industry and Lifestyle Brands</description>
	<lastBuildDate>Mon, 01 Jun 2026 07:49:32 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>
	hourly	</sy:updatePeriod>
	<sy:updateFrequency>
	1	</sy:updateFrequency>
	<generator>https://wordpress.org/?v=7.1</generator>

<image>
	<url>https://topropemedia.com/wp-content/uploads/2020/01/cropped-top-rope-media-logo-orange-favicon-32x32.png</url>
	<title>AI agents | Top Rope Media</title>
	<link>https://topropemedia.com</link>
	<width>32</width>
	<height>32</height>
</image> 
	<item>
		<title>Your AI Employee Needs a Circuit Breaker, Not an Onboarding Plan</title>
		<link>https://topropemedia.com/blog/2026/06/01/ai-agent-blast-radius/</link>
		
		<dc:creator><![CDATA[Tyler]]></dc:creator>
		<pubDate>Mon, 01 Jun 2026 07:48:03 +0000</pubDate>
				<category><![CDATA[AI]]></category>
		<category><![CDATA[Digital Marketing]]></category>
		<category><![CDATA[Software Development]]></category>
		<category><![CDATA[AI agents]]></category>
		<category><![CDATA[AI deployment]]></category>
		<category><![CDATA[AI governance]]></category>
		<category><![CDATA[AI strategy]]></category>
		<category><![CDATA[artificial intelligence]]></category>
		<category><![CDATA[Enterprise AI]]></category>
		<guid isPermaLink="false">https://topropemedia.com/?p=12785</guid>

					<description><![CDATA[<p>Vendors sell AI employees you onboard like staff. The AI agent blast radius is the question they skip: what's your circuit breaker, rollback, kill path?</p>
<p>The post <a rel="nofollow" href="https://topropemedia.com/blog/2026/06/01/ai-agent-blast-radius/">Your AI Employee Needs a Circuit Breaker, Not an Onboarding Plan</a> appeared first on <a rel="nofollow" href="https://topropemedia.com">Top Rope Media</a>.</p>
]]></description>
										<content:encoded><![CDATA[<p>I kept hearing the same word this spring.</p>
<p>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.</p>
<p>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.</p>
<p>That is exactly what worries me about it.</p>
<h2>The Metaphor Smuggles In an Org Chart That Doesn’t Exist</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2>There’s a Discipline That Already Has the Right Words, and It Isn’t HR</h2>
<p>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.</p>
<p>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.</p>
<p>You can’t fire a process. You can only kill it.</p>
<p>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. <a href="https://topropemedia.com/blog/2026/04/28/agents-underwriting-problem/">The failure surface</a> is wider than either metaphor admits.</p>
<p>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.</p>
<p>So the question is not how you onboard your AI employee. A human who errs costs you time. <strong>An AI employee who errs at machine speed costs you scale, because you deployed a production service and called it a hire.</strong></p>
<h2>The Metaphor Earns Its Keep, Right Up Until It Doesn’t</h2>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<h2>What an AI Agent’s Blast Radius Looks Like in Production</h2>
<p>This is not a thought experiment. Two recent examples.</p>
<p>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.</p>
<p>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.</p>
<h2>What Changes on Monday</h2>
<p>If you take the production-service framing seriously, three things change before you deploy anything.</p>
<p>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.</p>
<p>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.</p>
<p>Third, budget the throttle. Price <a href="https://topropemedia.com/blog/2026/05/17/fde-principal-agent-deployment-jv/">the loaded cost</a>, 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.</p>
<p>None of this is exotic. It’s <a href="https://topropemedia.com/blog/2026/04/24/the-case-for-enterprise-ai-technology-as-risk-management-not-innovation/">the same discipline</a> 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.</p>
<h2>The Word Was the Problem</h2>
<p>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.</p>
<p>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.</p>
<p>The post <a rel="nofollow" href="https://topropemedia.com/blog/2026/06/01/ai-agent-blast-radius/">Your AI Employee Needs a Circuit Breaker, Not an Onboarding Plan</a> appeared first on <a rel="nofollow" href="https://topropemedia.com">Top Rope Media</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>I Connected Three APIs This Week. None of Their Vendors Knew I Was Shopping.</title>
		<link>https://topropemedia.com/blog/2026/05/05/self-serve-apis/</link>
		
		<dc:creator><![CDATA[Tyler]]></dc:creator>
		<pubDate>Tue, 05 May 2026 14:43:36 +0000</pubDate>
				<category><![CDATA[AI]]></category>
		<category><![CDATA[AI agents]]></category>
		<category><![CDATA[AI deployment]]></category>
		<category><![CDATA[API strategy]]></category>
		<category><![CDATA[b2b]]></category>
		<category><![CDATA[Developer experience]]></category>
		<category><![CDATA[MCP]]></category>
		<category><![CDATA[Operator strategy]]></category>
		<guid isPermaLink="false">https://topropemedia.com/?p=12769</guid>

					<description><![CDATA[<p>94% of B2B buyers now compare vendors with LLMs mid-funnel. If your self-serve APIs aren't agent-readable, you're not losing deals — you're not in the set.</p>
<p>The post <a rel="nofollow" href="https://topropemedia.com/blog/2026/05/05/self-serve-apis/">I Connected Three APIs This Week. None of Their Vendors Knew I Was Shopping.</a> appeared first on <a rel="nofollow" href="https://topropemedia.com">Top Rope Media</a>.</p>
]]></description>
										<content:encoded><![CDATA[<h2>Making the case for Self-Serve APIs</h2>
<p>My recent integration work has got me thinking.</p>
<p>The first vendor was Google Ads. I never spoke to anyone — signed up with an email, ran their quickstart, hit a snag in the OAuth flow, found the fix three sentences into their auth doc, and was making real requests inside an hour. The second vendor I also never spoke to. Signup form to working integration in roughly the same window. The third was different. I went looking for it — knew the category, knew the company name, walked in with intent. Their docs page redirected me to a “book a demo” form. Within days I’d shipped against a competitor.</p>
<p>Different vendors. Different categories. Different price points.</p>
<p>Same dynamic.</p>
<p>Two of them got onto my integration shortlist without ever knowing I was a prospect. One of them lost the deal before they knew there was one. The agent did the shopping — the synthesis tool I’d been pasting their docs into all afternoon, the assistant I asked to compare authentication flows, the model I ran the rate-limit math through. The vendor’s funnel still assumed a human knocked on the door. The buyer’s funnel didn’t have a human in it.</p>
<p>That’s when I started thinking about this less as a developer-experience question and more as a distribution one.</p>
<h2>The Buyer’s Funnel Doesn’t Have a Human In It</h2>
<p>Let me be specific about what I mean. The dominant story in B2B leadership rooms right now is that public docs and self-serve APIs are a developer-experience investment you fund post-Series-B. Sales-led growth funded the company. AEs scope integrations. Demos generate pipeline. Custom implementation work preserves margin. The motion converts; why diversify surface area now?</p>
<p>It’s a rational default. It built most of the enterprise software economy we have today.</p>
<p>Here’s the context that often gets left out. 94% of B2B buyers now use LLMs during their purchase journey, primarily as synthesis tools mid-funnel — comparing offerings, evaluating proposals, summarizing what they’ve gathered. Two-thirds say they’d prefer to buy without engaging a sales rep at all. Gartner forecasts that by 2028, 90% of B2B buying will be agent-intermediated, pushing roughly $15 trillion through agent-driven exchanges.</p>
<p>The so-what doesn’t depend on the forecast. The present-tense data already says the buyer’s funnel doesn’t have a human in it. The vendor’s still does. That’s the gap that gets you cut from the consideration set before you knew there was a deal.</p>
<h2>There’s a Discipline That Already Speaks This Language</h2>
<p>This isn’t a marketing story. It’s a distribution one — and there’s a mature discipline with the vocabulary for it.</p>
<p>Retail merchandising. Specifically, shelf-space economics: the body of practice that governs how products get found, picked up, and bought when the buyer is making a hundred adjacent comparisons in a finite window. Shelf, placement, planogram, end-cap, category captain, slotting fee. These aren’t metaphors. The dynamics are identical. An agent shopping the API landscape is doing exactly what a buyer does walking down an aisle: scanning labels, evaluating fit on a small set of legible signals, putting one item in the cart.</p>
<p>Once you have the vocabulary, the maturity arc falls out.</p>
<p>Stage 1 is being on the shelf at all. There is a public schema. There is a quickstart that runs without a human in the loop. A developer — or an agent acting on a developer’s behalf — can find your endpoint, evaluate your auth flow, and ship a first request without speaking to anyone at the company. If you’re not at Stage 1, you’re not in the consideration set. You don’t lose the deal. You don’t get evaluated.</p>
<p>Stage 2 is earning placement. Your docs are clean. Your error messages explain themselves. Your rate limits are honest. Your idempotency is documented. Your examples compile on first paste. You’re the API the agent reaches for first because the friction of integrating you is lower than anyone else in the category. Stage 2 is where competitive advantage actually lives in 2026 through 2028.</p>
<p>Stage 3 is becoming the category captain. Your name is in the prompt. Developers and the agents working for them say “Stripe” when they mean payments, “Twilio” when they mean messaging, “Plaid” when they mean bank connections. You’re the default that other names get compared to. Category captains in agentic-discovery markets get set by who reaches Stage 2 first and compounds longest.</p>
<p>Public docs are how you exist. Tool quality is how you win.</p>
<h2>Three Stages, Four Examples</h2>
<p>The three integrations I started with were each at a different stage. The two that made my shortlist were Stage 2 — clean public quickstarts, OAuth that worked first try, docs doing the selling. The one I’d hunted by name had slipped backward into a sales-call gate. Category captaincy slipping in real time.</p>
<p>Stage 0 has two flavors, and I’ve shipped against both.</p>
<p>Bloomberg actually publishes its API documentation. The BLPAPI Developer’s Guide is a public PDF. The HTTP API has a public GitHub repo. What’s gated is access, not docs. To use the API you need either a Terminal subscription — roughly $30,000 per seat per year — or an enterprise data contract negotiated through a sales conversation. There’s no developer signup. The shelf is real, the labels are pristine, and the buyer can’t reach it.</p>
<p>The same dynamic shows up smaller. An equestrian streaming platform we work with: IP-whitelisted API, server-side only, documentation that arrives by email after you ask. Different scale, same gate.</p>
<p>Then there’s Substack. I publish on it, and when I wanted programmatic access for an automation, the only path was a cookie-auth shim against an undocumented surface — no published schema for the publishing surface. The shelf isn’t gated; the labels just aren’t there. Two flavors of Stage 0: docs published but access locked, or access available but nothing to read.</p>
<p>The pre-agent precedent for Stage 3 is Stripe, Twilio, and AWS. Stripe didn’t outcompete Braintree on processing economics. They outcompeted on a signup that worked in seven lines of code while competitors were still running multi-day merchant-account approvals, and on documentation a developer could actually read. Twilio’s 2016 S-1 said the same thing in SEC language: revenue depended on self-service adoption by developers, and over a million developer accounts had registered by IPO. AWS got there earlier — S3 launched in March 2006 on an email address and a credit card, with enterprise sales infrastructure built years later on a developer base AWS had already won. All shelf-space plays, a decade before agents made the play structural. None of these are stories about devrel as a cost center. They’re stories about distribution as the moat.</p>
<p>The present-tense version is at the protocol layer. Anthropic released the Model Context Protocol in November 2024, betting that whoever published the standard for tool schemas would shape the ecosystem. Twelve months later, Anthropic donated MCP to the Agentic AI Foundation, a new directed fund under the Linux Foundation co-founded with Block and OpenAI — each contributing a project of their own. Platinum members include AWS, Bloomberg, Cloudflare, Google, and Microsoft. Textbook captaincy graduation: a vendor protocol becoming open infrastructure. Publishing the interface didn’t dilute the position; it locked it in.</p>
<h2>The Sales-Led Argument Deserves a Real Answer</h2>
<p>There’s an honest objection worth taking seriously. Sales-led GTM has built most of the enterprise software companies that matter. Custom implementation preserves margin self-serve can’t. AE-driven scoping protects deal velocity in real enterprise sales — procurement, security review, six-stakeholder buying committee. Diversifying surface area too early dilutes focus and creates support cost the company isn’t ready to absorb. Every one of those points is real.</p>
<p>But here’s what’s worth noticing. None of those arguments contradicts the shelf-space frame. They argue for keeping the sales-led motion for the deals where it works — large, complex, multi-stakeholder enterprise contracts. The shelf-space play isn’t a replacement. It’s the play for the part of the buyer base that doesn’t behave like a procurement committee anymore: the engineer at a target account who’s been told to evaluate three vendors by Friday, who pastes your docs into an LLM after dinner and decides on Monday which one procurement should call. That engineer is the shortlist gatekeeper even for the deals that close through sales. Cutting yourself off from her upstream because the downstream contract still needs an AE doesn’t preserve the motion. It cedes the shortlist.</p>
<h2>What This Actually Changes</h2>
<p>For an operator weighing whether to fund this work, four things follow.</p>
<p>First, Stage 1 is overdue, not Series-B-funded. If your interface isn’t readable by an agent today, you’re not in the consideration set tomorrow. The budget conversation isn’t “should we fund developer experience?” It’s “should we be visible in the discovery layer agents are using now?” Asked that way, the answer is forced.</p>
<p>Second, Stage 2 is the durable bet. Within 18 to 24 months, every serious competitor will reach Stage 1. Shelf presence becomes table stakes. Differentiation moves to tool quality — schema clarity, error messages that diagnose themselves, idempotency, rate-limit honesty, examples that compile on first paste. That’s where engineering compounds.</p>
<p>Third, the first hire is DX engineering, not developer marketing. “Developer evangelist” is a 2018 job title. The 2026 version is the engineer who writes API docs, designs schemas an LLM can parse cleanly, and maintains examples that don’t rot. Senior engineering hire, not marketing.</p>
<p>Fourth, stop scoping integrations and start measuring picks. If your sales motion treats every integration as a custom implementation, you’re optimizing for the wrong unit. Measure how often agents pick you over the alternatives. That’s the leading indicator for the next 18 months of revenue. Instrument for it now.</p>
<p>None of that is rocket science. It’s just discipline — the discipline that separates a company that compounds for a decade from one that gets a great quarter and a soft landing.</p>
<h2>Close</h2>
<p>The pattern shows up everywhere the buyer is a developer or an agent acting on a developer’s behalf. Payments, messaging, identity, observability, ad-tech, analytics — anything where the integration is the product. The companies that publish their interfaces this year will define their categories. The ones that don’t will be footnotes in someone else’s quickstart guide.</p>
<p>The internal conversation isn’t “are we ready for devrel?” It’s “are we visible to the buyer the buyer has become?” One of those questions gets a budget. The other gets the category.</p>
<p>The vendors who exist tomorrow are the ones whose interfaces an agent can read today. The vendors who win are the ones whose interfaces an agent reaches for first.</p>
<p>The shelf is already there. The agents are already shopping.</p>
<p>The post <a rel="nofollow" href="https://topropemedia.com/blog/2026/05/05/self-serve-apis/">I Connected Three APIs This Week. None of Their Vendors Knew I Was Shopping.</a> appeared first on <a rel="nofollow" href="https://topropemedia.com">Top Rope Media</a>.</p>
]]></content:encoded>
					
		
		
			</item>
		<item>
		<title>After Integration, the Actuarial Table</title>
		<link>https://topropemedia.com/blog/2026/04/28/agents-underwriting-problem/</link>
		
		<dc:creator><![CDATA[Tyler]]></dc:creator>
		<pubDate>Wed, 29 Apr 2026 06:46:49 +0000</pubDate>
				<category><![CDATA[AI]]></category>
		<category><![CDATA[AI agents]]></category>
		<category><![CDATA[AI deployment]]></category>
		<category><![CDATA[Enterprise AI]]></category>
		<category><![CDATA[Operator strategy]]></category>
		<category><![CDATA[risk management]]></category>
		<category><![CDATA[Underwriting]]></category>
		<guid isPermaLink="false">https://topropemedia.com/?p=12745</guid>

					<description><![CDATA[<p>The 88% enterprise AI deployment failure stat is rhetorical, not empirical. The fresh frame for shipping operators is two centuries old: underwriting.</p>
<p>The post <a rel="nofollow" href="https://topropemedia.com/blog/2026/04/28/agents-underwriting-problem/">After Integration, the Actuarial Table</a> appeared first on <a rel="nofollow" href="https://topropemedia.com">Top Rope Media</a>.</p>
]]></description>
										<content:encoded><![CDATA[<div class="et_pb_section et_pb_section_0 et_section_regular" >
				
				
				
				
				
				
				<div class="et_pb_row et_pb_row_0">
				<div class="et_pb_column et_pb_column_4_4 et_pb_column_0  et_pb_css_mix_blend_mode_passthrough et-last-child">
				
				
				
				
				<div class="et_pb_module et_pb_text et_pb_text_0  et_pb_text_align_left et_pb_bg_layout_light">
				
				
				
				
				<div class="et_pb_text_inner"><p>My <a href="https://topropemedia.com/blog/2026/04/27/you-can-buy-intelligence-you-have-to-build-integration/">prior piece</a> ended on a line: <em>the work of the next two years is the body.</em> You can buy intelligence; you have to build integration. The contract surface between the model and everything around it is where deployments live or die.</p>
<p>True. And not the whole story.</p>
<h2>Capability Is Solved. The Discourse Has the Receipts.</h2>
<p>The April-2026 consensus is sharper than it’s been in two years. Stanford’s 2026 AI Index named the <em>jagged frontier</em> — models that win gold at the IMO read analog clocks correctly only 50.1% of the time. OSWorld reports accuracy rose from roughly 12% to 66.3% in twelve months. Fidji Simo calls this the <em>capability overhang.</em> Bersin: the engine isn’t the issue, it’s the surface. Hashimoto: <em>Agent = Model + Harness.</em></p>
<p>Underneath all of it, there is a common failure rate for AI enterprise projects being cited:  88% — the share of enterprise AI agents that, depending on which analyst you read, never reach production. The frame writes itself: capability is solved, deployment is the work, organizational maturity will close the gap.</p>
<p>That diagnosis is right but unfortunatley the prescription is incomplete.</p>
<h2>The 88% Failure Rate is driving a False Narrative</h2>
<p>No single primary owns this number. Apify and Digital Applied have a March 2026 survey of 650 enterprise tech leaders showing 78% piloting, 14% production scale. MIT’s NANDA has 95% pilot failure on a different denominator entirely — financial impact, not deployment. Stanford HAI is widely credited as the source and shouldn’t be: Stanford publishes 88% organizational <em>adoption,</em> a different stat that’s been conflated across analyst coverage. The 88% is what happens when a discourse rounds different studies to a clean repeatable number.</p>
<p>And the comparison context is missing from every cite. Standish Group’s CHAOS Reports have tracked enterprise IT failure rates between 60% and 85% for thirty years. VentureBeat reported in 2019 that 87% of data science projects never reach production. The 88% isn’t telling you AI is uniquely broken. It’s telling you enterprise IT is failing at the historical rate, with new vocabulary that lets the governance industry sell the fix.</p>
<p>It’s also not the median. Mayfield’s 2026 CXO survey reports 42% in production. Zapier’s 2026 Adoption survey: 72% deployed, 40% with multiple agents in production. The 88%-failure narrative is one half of a bifurcated discourse, presented as the whole.</p>
<p>The right question isn’t <em>why is AI failing at 88%?</em> It’s <em>why does enterprise IT keep failing at this rate, and what’s the boring answer?</em></p>
<h2>Insurance Has Had This Answer for Two Centuries</h2>
<p>The discipline that has the answer is underwriting.</p>
<p>Every AI deployment is a policy. Build cost is the premium. Failures are claims. Tasks the harness refuses are exclusions. Claims over premium, observed over time, is the loss ratio. The table that lets you price the next policy is the actuarial table.</p>
<p>Options traders know it as tuition on a new ticker.</p>
<p>Here’s what the AI discourse misses: the actuarial table doesn’t get written before deployment from theory. It gets written <em>through</em> deployment, from observed claims. Software dev calls this fast-failure. Ship deliberately failure-budgeted experiments. Contain the blast radius. Let each shipped loss price the next exposure. Every shipped failure is a row in the table.</p>
<p>The 88% is what an unpriced book of policies looks like over time. It eats itself. The teams who avoid it aren’t avoiding failure — they’re paying tuition deliberately, in priced lots, with the blast radius contained.</p>
<h2>What This Looks Like</h2>
<p>The MCP tooling I built around Linear is the closest example I have. Personally owned. The integration lets me query, update, and reason about project state through natural language instead of clicking through the UI. It ships work roughly 20–30% faster than the equivalent click-through workflow, on rough opportunity-cost math.</p>
<p>It works that well because earlier versions did things I didn’t want — surfaced wrong issues, updated wrong status, missed edge cases. Each was a claim, in policy language. The fix in each case wasn’t a smarter model. It was an exclusion clause: this tool will not perform that operation. The current version is what you build when you’ve paid the tuition.</p>
<p>You’re reading this because the workflow shipped.</p>
<p>The pattern shows up in the broader research. Stanford’s Digital Economy Lab studied 51 successful enterprise AI deployments. Their conclusion in their own words: <em>the difference was never the AI model. It was always the organization.</em> The variation across those 51 wasn’t model choice or harness sophistication. It was which orgs treated their deployments as priced policies and ran fast-failure loops to refine the prices.</p>
<h2>What Changes</h2>
<p>Five operator moves.</p>
<ul>
<li><strong>Budget for claims before launch.</strong> Target loss ratio, not target uptime.</li>
<li><strong>Run a per-agent expected-loss calculation.</strong> Frequency × severity × exposure window. Same math as a per-trade EV calc.</li>
<li><strong>Require a written exclusions document.</strong> Tasks the agent will not perform. Contract clause, not rate-limiter.</li>
<li><strong>Hire underwriters, not governance officers.</strong> The role isn’t <em>ensure compliance.</em> It’s <em>price the claim before it’s filed.</em></li>
<li><strong>Run fast-failure loops as the actuarial process.</strong> The harness is the policy form. The actuarial table is the product. The experiments are the data.</li>
</ul>
<h2>Closing</h2>
<p>The 88% isn’t telling you AI is uniquely broken. It’s telling you enterprise IT is failing at the historical rate, and the boring two-century-old answer is the same one insurance has had since the 1700s.</p>
<p>The <a href="https://topropemedia.com/blog/2026/04/27/you-can-buy-intelligence-you-have-to-build-integration/">integration piece</a> named the substrate. This piece adds the discipline. Fast-failure is the loop that compounds them.</p>
<p>The actuarial table doesn’t write itself.</p></div>
			</div>
			</div>
				
				
				
				
			</div>
				
				
			</div>
<p>The post <a rel="nofollow" href="https://topropemedia.com/blog/2026/04/28/agents-underwriting-problem/">After Integration, the Actuarial Table</a> appeared first on <a rel="nofollow" href="https://topropemedia.com">Top Rope Media</a>.</p>
]]></content:encoded>
					
		
		
			</item>
	</channel>
</rss>
