What do we mean by ‘long-horizon’ work? 

TL;DR - The benchmarks frontier labs cite for long-horizon capability mostly measure capability on tasks involving many steps or lots of context, verifiable end states, and little external input. I argue that what defines real-world long-horizon work is delayed external feedback. That delay is where human input becomes high leverage, and it’s a constraint neither longer context nor multi-agent swarms can engineer away. I discuss this with examples like building a new, better Redis vs. running personalized lead conversion campaigns. Earlier this month, while working on task design for scalable oversight-related problem statements, my teammates at Lossfunk and I disagreed on what are good examples of long-horizon work. I suggested “run personalized digital lead conversion campaigns,” while my more software-minded teammates recommended, “build a better and different Redis.” This got me reading about how to define long-horizon tasks, and as it turns out, we weren't alone in our confusion. Investor and Operator Nikunj Kothari tweeting about how ‘long horizon’ is a concept he has heard highly varied and wildly different definitions for. I figured the best way to resolve this confusion was to review recent model release reports and note how frontier model labs talk about the concept and the benchmarks they use to report capabilities on this front. I also reviewed additional papers I found on arXiv. My current main takeaways from my reading are: • There is a difference between ‘long horizon task execution’ and models with ‘long context length’ and more efficient ‘long sequence modelling’. • Much of the literature I reviewed defines long-horizon execution as tasks that can be broken down into many subtasks, most often sequentially, borrowing from MDP modeling and long-horizon planning in RL, or as long context and long-sequence modeling in transformer- and attention-based architectures.• Chen et al. (2026), a survey of over 1500 papers, also define long-horizon as a property