Many coding agents have a "modes" feature that (kinda?) made sense in a RAG or early agentic era. Now they're adding subagents like Amp (search subagent, general subagents, the oracle) and Claude Code (which just shipped a really cool custom subagents feature). Modes are heavyweight, non-composable UI dropdown menus. Subagents are invoked through natural language ("use the oracle to ...", "use the issue subagent to ...", or implicitly), are perfectly composable, and fit neatly into the conceptual model of agentic tool-calling. It turns out modes and subagents basically serve the same purpose. Subagents are a strictly better solution. So, prev-gen coding agents that have an existing "modes" feature now face a tough choice when they add subagents: keep both modes & subagents around (which is confusing and complex), rip out modes (which is painful to their userbase because they put a lot of effort into creating modes), or try to stretch the "modes" concept to include subagents as well (which will be confusing too). I don't envy them. On the Amp team, we live in mortal fear of being in this unenviable position when we've mis-judged where agentic coding will be in the future and need to make painful product changes. We've made all of these mistakes on products we built before Amp (and we make and will make tons of mistakes on Amp). This is why we have an incredibly high bar to add new UI concepts, it's why we prioritize team members with strong intuition, and it's why we build for where models and the median dev will be in 6-12+ months, not today. In this case, I believe this orientation led us to the right decision (no modes, only composable subagents). We are fortunate to be able to build for incredibly smart and open-minded/forward-thinking devs who share their feedback often and through basically every channel except carrier pigeons. We've gotten to know and understand so many of you all well. We simply couldn't see any of you or ourselves really loving "modes". But when @thorstenball built subagents and then the oracle, and said that to use them, just say so ("use the oracle to ...") instead of selecting them from some dropdown, it felt right to us and all of you, and it felt like it's where the models were going, too. Props to him there, and thanks to our awesome users for seeing the future. Just wanted to share a bit behind the scenes about how we think about this stuff and why we might seem extreme or rigid on things. ...and stay tuned for this weekend, when I'll be admitting I was wrong about one of our most controversial Frequently Ignored Feedback (FIFs) and will be changing it, thanks to a ton of feedback that it turns out I did not ignore.