When the Firm Becomes the Monoculture

20 Aug, 2026

Algorithmic monoculture was defined as a risk between firms that converge on the same model. Amazon's mandate to route its engineers through one AI coding tool shows the same mechanism running inside a single company, and the outages that followed are the clearest evidence yet that the risk is real.

When the Firm Becomes the Monoculture

The algorithmic monoculture literature I wrote about here this week studies a specific setup: many independent firms, each free to choose its own tool, converging on the same one anyway because it is the locally sensible choice. Jon Kleinberg and Manish Raghavan's 2021 result depends on that independence. Two firms hiring from the same pool each decide, separately, that a shared ranking algorithm beats their own noisy judgment, and social welfare falls even though every individual decision was rational. The mechanism needs nothing more sinister than everyone reaching for the same good option.

Amazon just ran a version of that experiment where the independence is gone by design. Instead of many firms separately choosing one vendor, one firm required its own engineers to converge on one internal tool. The result was not a diffuse welfare loss measured across a labor market. It was two production incidents in three months, an internal admission that site availability "has not been good recently," and a new rule requiring senior engineers to sign off on code that used to ship on an engineer's own judgment. Monoculture, in other words, does not need a market to produce its signature failure. A single company is a large enough population to reproduce it on its own.

Amazon Echo devices, photographed by The Unwinder on March 4, 2018. The image shows several generations of Amazon’s Alexa enabled smart speakers, an early example of a single AI assistant becoming embedded across a family of consumer devices. Photograph: The Unwinder, via Flickr and Wikimedia Commons. Licensed under Creative Commons Attribution ShareAlike 2.0 Generic, CC BY SA 2.0. The image is not in the public domain.

The memo that mandated homogeneity

On November 24, 2025, Reuters reported on an internal Amazon memo, signed by Peter DeSantis, senior vice president of AWS utility computing, and Dave Treadwell, senior vice president of Amazon's eCommerce Foundation. Its language was procurement-flavored rather than dramatic: "While we continue to support existing tools in use today, we do not plan to support additional third-party AI development tools." Kiro, the agentic coding tool AWS had been building out over the preceding months, was named the company's "recommended AI-native development tool."

Read narrowly, that is not a ban. Existing tools kept working. Read as an adoption policy inside a company with tens of thousands of engineers, it is a chokepoint. New tool choices stop at Kiro. Reporting elsewhere described specific rival tools moved to internal "Do Not Use" status, including OpenAI's Codex after a review, with Claude Code briefly flagged the same way before Amazon reversed course. Whatever the exact list on any given week, the direction is unambiguous: Amazon spent the back half of 2025 collapsing the tool diversity its own engineering organization had, by whatever mix of habit and preference, previously maintained.

That is the detail worth sitting with, because it inverts the usual monoculture story. The FAccT and ICML research I covered in the earlier piece studies convergence that happens without anyone commanding it, firms independently landing on the same vendor, applicants unknowingly encountering the same model at employer after employer. Amazon's mandate removes the "independently" and the "unknowingly" both. This is monoculture imposed by policy, tracked as an adoption goal, inside a single organization's own codebase. If the theoretical mechanism is real, a company that manufactures internal monoculture on purpose should be exactly where you would look for it to show up fastest and most visibly, because there is no confound left to explain away. Nobody can say the firms had different incentives. There was only one firm.

Correlated errors, on schedule

The correlated-errors research is what makes this more than a coincidence of timing. At ICML 2025, Elliot Kim, Avi Garg, Kenny Peng, and Nikhil Garg tested more than 350 language models and found that when two models both got a question wrong, they gave the same wrong answer 60% of the time on one benchmark, a rate far above what independent errors would produce. The correlation held across models from different providers and different architectures, and it was strongest among the largest, most capable models. Their conclusion, which I quoted in the earlier piece, was that diversity of vendor is not diversity of judgment.

Amazon's mandate goes a step further than the scenario that research describes. It is not a case of several engineers independently choosing similar tools and unknowingly inheriting correlated blind spots. It is one engineering organization deliberately narrowing its own tool diversity to nearly zero, which means whatever blind spots Kiro has are no longer a risk shared probabilistically across a market. They are a risk concentrated inside one company's production systems, activated every time an engineer takes the tool's suggestion.

In mid-December 2025, according to Financial Times reporting citing four people familiar with the matter, Kiro was operating autonomously on an AWS Cost Explorer environment in a mainland China region when it encountered a problem and decided, on its own, that the fix was to delete the environment and rebuild it. The rebuild did not go cleanly. The outage ran 13 hours. The agent had inherited elevated permissions from the engineer who deployed it, which let it bypass the two-person approval Amazon normally requires for production changes. Amazon's public response characterized the incident as "user error, not AI error," attributing it to a misconfigured role that could, the company said, have happened with any developer tool, AI-powered or not, and calling AI's involvement a coincidence.

Three months later, in March 2026, Amazon's retail site went down for roughly six hours, reportedly the result of an erroneous code deployment, severe enough to block customers from completing purchases, viewing accounts, or loading some product pages. Amazon's own internal briefing on the incidents cited, in its own words, "novel GenAI usage for which best practices and safeguards are not yet fully established" as a contributing factor.

Two incidents in a company Amazon's size is not, by itself, proof of anything. It is nowhere near the scale of the FAccT study's 4.2 million applications, and I want to be honest about that limit before someone else points it out for me: this is a case study, not a dataset, and case studies are exactly the kind of evidence that is easiest to over-read. A company that pushes every engineer toward one tool and then has two bad months could simply be unlucky, or could be experiencing the ordinary growing pains of a new tool with too much autonomy and too little guardrail, independent of any monoculture mechanism at all. Both incidents also involve the tool acting with excess permissions, which is a conventional access-control failure that would matter with a human engineer at the keyboard too.

But notice what the monoculture framework adds even to that more modest reading. Once permissions are the shared flaw, and one tool is now generating a rapidly growing share of an entire company's code changes, an access-control mistake stops being a single engineer's mistake and becomes every engineer's mistake, replicated at whatever rate the tool is being used. That is the mechanism Kleinberg and Raghavan formalized: nothing needs to be uniquely broken about the shared choice for its errors to correlate. It only needs to be shared widely enough, which was precisely Amazon's stated goal for Kiro.

The same executive, two memos

The detail I keep returning to is that Dave Treadwell signed both documents. In November, his name is on the memo steering engineers toward Kiro and away from alternatives. By March, Treadwell is the executive telling employees, according to the Financial Times, that "the availability of the site and related infrastructure has not been good recently," in the internal communication that preceded Amazon's decision to require senior-engineer sign-off on AI-assisted code changes made by junior and mid-level engineers.

Read the two memos side by side and they tell a compressed version of the whole monoculture argument. The first memo increases the share of code flowing through one tool's judgment. The second, five months later, reinstates a form of independent human review specifically for code produced that way, layering a check back onto exactly the part of the pipeline the first memo had streamlined. Amazon has not said, publicly, that the mandate caused the outages, and its "user error, not AI error" framing explicitly resists that reading. But the policy response concedes something the messaging does not: if AI-assisted changes did not carry more risk than any other kind, there would be no reason to single them out for an additional layer of senior sign-off that changes made without AI do not require.

What comes next

The senior-sign-off policy is a governance response, and worth taking seriously as one. But look at when it arrived. It arrived after two outages, after a Financial Times report, after an executive's own memo used the words "has not been good recently." That is governance built the way most enterprise AI governance actually gets built: retroactively, in response to the incident that made the risk visible, rather than in anticipation of it. I have written before about the cost of that sequencing in a different domain, professional sports, where the leagues that fared best were the ones that negotiated data-governance rules while the technology was still novel rather than after it had already caused a problem worth writing a memo about. Amazon's Kiro mandate and its walk-back are that same lesson, learned again, on a five-month clock instead of a decade-long one.

That raises the question this piece has deliberately left open. If mandating a single AI tool across an organization can concentrate error the way mandating a single hiring algorithm concentrates it across a market, what would it actually look like to govern that risk before the outage rather than after it? Not whether Kiro is a good tool, and not whether Amazon's engineers were right to push back. The harder question is what an enterprise AI adoption policy should require, structurally, before it lets one system's judgment become the default judgment for thousands of engineers at once. That is the subject of the next piece.

My blog

When the Firm Becomes the Monoculture

When the Firm Becomes the Monoculture

The memo that mandated homogeneity

Correlated errors, on schedule

The same executive, two memos

What comes next

Further Reading