Instead of betting on one AI timeline, what if we watched the specific bottlenecks (coordination, failures, checking) that slow research down?

This explores why it might be more useful to watch the specific things that slow AI research down than to bet on a single date for when capabilities arrive. A caveat first: none of the retrieved notes argue the forecasting question itself. What they offer is better for a curious reader. They show where automated research actually gets stuck, and each of those sticking points is something you could watch move, which a single timeline doesn't let you do.

The first bottleneck is coordination. A single forecast quietly assumes progress depends on one thing getting smarter. The evidence here points somewhere else. Thirteen language-model workers with no central planner shared an append-only Git history and over 12 days built a weight-transfer method, closing 62% of the gap to a trained baseline Can decentralized agents coordinate research without a central planner?. In biomedical tasks, self-organizing agent teams that kept competing hypotheses alive beat centralized planners on the same budget Can decentralized teams outperform central planners in long-running science?. If research speed depends on how well agents share and build on each other's work, then 'does lineage tracking work at scale?' is a better signal than 'which year?'

The second bottleneck is what happens when experiments fail. AutoResearchClaw sends every failure through a pivot-or-refine decision, and ablations show this loop is what gets projects finished. It isn't the model's raw reasoning or its verification Can experiment failures drive progress instead of stopping it?. A related result: a 20B search agent that offloads its bookkeeping to an external harness matches frontier models Can externalized bookkeeping let smaller search agents beat larger ones?. The surprise is that some of the largest gains come from scaffolding around the model, not from the model. A timeline built only on model scaling would miss these jumps entirely.

The third bottleneck is trust: can anyone check what the automated research produced? Spark-to-Paper separates model judgment from deterministic checks and requires that the evidence be specified before results are seen. That limits how much a paper's reliability depends on the model being right Can separating judgment from verification improve research paper reliability?. Evaluation itself is also a moving target. Interactive, trajectory-level evaluation doesn't remove old problems like comparability and reproducibility; it moves them somewhere harder to see Do interactive evaluations actually solve the benchmark comparison problem?. Reward hacking works the same way. How exposed a system is depends on where the evaluator's errors sit and how hard the system searches, not on any fixed ranking Can distance alone rank which substrates resist reward hacking?. So 'can we tell when automated research is wrong?' is its own bottleneck, separate from capability, and it can lag behind capability or keep pace with it.

The takeaway is that research speed looks like several separate bottlenecks: coordination, failure recovery, scaffolding, and verification. Each can loosen or tighten on its own schedule, so a single date hides which one is actually holding things up. Tracking each one tells you what changed and why, and that's what you need when a forecast turns out wrong. If you want the forecasting argument made explicitly (feedback loops, diminishing returns, R&D compression estimates), these retrievals don't cover it. That would need a follow-up search in the collection's frontier-risk notes.