The article explores whether agent-run companies could achieve exponential growth by leveraging AI agents for tasks like product development and customer management, while discussing experiments on model failure overlaps and the challenges of building resilient systems to scale effectively.
Could agent-run companies grow as fast as the AI behind them? If models and agent systems keep improving exponentially, could a company built around them grow at a similar pace? Agents could develop products, find customers, handle onboarding, and maintain what they’ve already deployed. Revenue from those customers could fund more capacity, while better models make each agent more productive. In principle, the business could expand without having to hire and train a proportionate number of people. As the company takes on more customers, it would also need to check more decisions and repair more mistakes. Other agents could test changes, monitor deployed systems, and handle recovery. For those checks to be useful, the reviewers would need evidence that could contradict the producer and enough authority to stop a deployment or escalate a problem. How much protection would those additional agents provide? If the producer and reviewer inherit the same mistaken assumption, they might agree while both being wrong. A test generated from a faulty specification can faithfully confirm the specification’s mistake. Our first suspicion didn’t hold up very well We initially worried that businesses relying on the same handful of foundation models would make similar mistakes, limiting the protection offered by using multiple models to verify/validate eachother. Our first study weakened that concern considerably. Across a retrospective panel, models frequently failed on the same questions, but much of that overlap was consistent with some questions simply being hard for the models. After adjusting for task difficulty, the typical residual overlap was near zero. A fresh prospective panel retained only a small positive remainder. In the contrasts we tested, changing the model endpoint reduced failure overlap more than changing the evidence source did. That changed a bundle of model and deployment characteristics, so it wasn’t a clean test of vendor identity. We couldn’t reasonably conclude that model diversity was useless, or that shared inputs mattered more than model choice. Shared faulty inputs Would models be more likely to fail together when they received the same faulty input, rather than independently assigned errors? The follow-up used eight fixed model/deployment routes and synthetic records containing one recoverable wrong field. In one condition, every route received the identical corrupted version. In the other, each route drew independently from the same corruption pool, with accidental matches still possible. Each route had to identify the error and return a specified repair. They weren’t reviewing one another’s answers or operating a business. We were testing one possible source of shared failure that could potential matter in such a cross-checking system. Across the same 1,677 item families: Average exact-repair failure barely changed: 59.2% → 59.9%. Cases where all eight routes failed increased from 77 → 117, or 4.59% → 6.98%. The average alone would have largely missed the change in all-eight failures. These findings are preliminary and haven’t been peer reviewed.1 What this means for the growth question The experiments don’t establish a ceiling on business growth or measure real-world losses. The results suggest measuring shared failures directly when agents are used to check other agents. The number of reviewers and their individual accuracy alone won’t tell a company how often a mistake could pass through every check. Better agents could improve production, checking, and recovery together. Whether those functions keep pace is an operating question we haven’t answered. And a company gaining market share or shifting repair costs onto customers is different from the economy producing more with the same resources. If you’re expanding an agent-run operation, what are you measuring to tell whether the agents resiliency system is working well enough to scale to 10x agent clusters? 100x? 1000x? ----- The average and all-eight comparisons came from follow-up analyses, and the study did not meet its full confirmation criteria. The analysis used different weights from the protocol, and a required statistical-support check was omitted before collection and failed when reconstructed afterward. The interval for the average change included zero, while error detection and final-answer failure did not establish the same pattern. The share of cases where at least half the routes failed actually decreased slightly. Failing the exact-repair requirement also did not necessarily mean returning a wrong final answer.
The article explores the difficulties of managing multiple AI agents in an enterprise setting, emphasizing the need for comprehensive inventory and oversight to prevent agent sprawl.
The author shares lessons from building an agentic system at work, describing failures with a giant prompt, excessive tools, and dynamic sub-agents, and ultimately finding success with a fixed orchestrator and specialized child agents for each domain.
A practitioner shares challenges scaling multi-agent AI systems in production, including dealing with shadow workflows (undocumented Slack threads and spreadsheets), context loss across different systems (ERP to CRM), and cross-departmental ownership issues. They seek advice from others who have navigated these real-world problems.
The author reflects on how AI agents are moving from answering questions to running work, potentially enabling one-person companies built on an AI agent stack, though judgment and execution remain critical.
The article discusses the gap between impressive AI agent demos and real-world deployment, focusing on practical challenges in business processes like sales ops, and calls for production case studies.