Architecture · system design · Load-bearing · GTM World Model v3.2
T11
Why this claim matters
Traditional software has an expensive build phase (engineering) and a cheap run phase (cloud hosting). Agentic systems reverse this: LLM API calls cost per-token at run time, errors compound across multi-step workflows, and the cost of a failure is often a sent message or a corrupted CRM record that cannot be fully undone. This inversion is widely acknowledged but its operational implications are underestimated: teams budget for software (cheap to run) but incur agent (expensive to run) costs. The compounding failure claim is contested by vendors who argue modern agent frameworks have sufficient retry/fallback logic to prevent compounding — but the claim is about systemic failure modes, not individual step failures.
The mechanism
Traditional software: build cost O(n) with engineering hours, run cost O(compute) per unit, deterministic failure modes (the code either runs or throws an exception). Agentic software: build cost O(small) — prompt engineering and workflow configuration, run cost O(tokens * API_price * steps) per workflow run, with stochastic failure modes that compound across steps. Compounding failure: if step 1 has 95% reliability and step 2 has 95% reliability, a 5-step agent has 77% end-to-end reliability (0.95^5). At 10 steps, reliability falls to 60%. For a GTM agent that runs thousands of account sequences daily, even a 1% per-step failure rate produces material CRM corruption. Additionally, agent failures in GTM are often asymmetric: a false-positive action (sending a message to a do-not-contact account, miscategorizing a hot lead as cold) has external consequences that software bugs do not.
Evidence for
- OpenAI Function Calling reliability data: multi-step agentic workflows with 5+ function calls show 60-80% end-to-end success rates, consistent with compounding 90-95% per-step reliability
- 11x AI SDR collapse (2024): the failure mode was compounding — personalization errors in early pipeline steps propagated through to sending demonstrably wrong messages at scale, damaging sender reputation
- LLM API pricing: GPT-4o at $2.50/1M input tokens means a 10-step research-and-outreach agent processing 1,000 accounts/day can cost $500-2,000/day at full deployment — a run-time cost that scales with volume, unlike traditional software
- Andreessen Horowitz 'The New Economics of AI' (2023): gross margins for AI-native companies were 40-60% vs. 70-80% for traditional SaaS, with the gap explained primarily by inference (run-time) costs
Evidence against / limitations
- Inference costs have been falling ~50% per year as model efficiency improves (GPT-4 level capability now available at GPT-3.5 price points), compressing the run-time cost inversion over time
- For low-step, high-confidence tasks (single-turn email personalization), agent reliability is high enough that compounding failure is not a material risk
- Deterministic guardrail layers (regex checks, CRM validation before write) can prevent some failure-compounding without requiring full agent redesign
So what: the operator implication
Before deploying agentic GTM at scale, run a reliability audit: map every step in the workflow, estimate per-step failure rate from test data, and compute end-to-end reliability as the product. If end-to-end reliability is below 90% for customer-facing actions, add human-in-the-loop checkpoints at the failure-prone steps. Budget for run-time compute costs explicitly in your GTM tech stack budget — do not treat them as zero like traditional SaaS licensing. Set a hard limit on agentic action volume during initial rollout and scale only as reliability data accumulates.
Related theses
All theses
How to cite this
@misc{shalvi_gtm_thesis_t11_2026,
author = {Singh, Shalvi},
title = {GTM World Model Thesis T11},
year = {2026},
url = {https://shalvisingh.com/gtm/theses/t11}
} Singh, Shalvi. "GTM World Model Thesis T11." shalvisingh.com, 2026. https://shalvisingh.com/gtm/theses/t11