The friction of single-thread DM-style assistants

Simon Smith @_simonsmithOriginally posted 2026.10.10

Open original on X

I’m trying to work out in my head the direct message, monothread, and one-off chat AI interaction models and how to make this all work more seamlessly. Direct message is the default for assistants like Dots and Muse. One entity, one message thread. The nice thing about this is it feels natural. You ask for something, it gets done in the background. When something’s done or something happens that you need to know about, you get updates in one place. And you don’t need to start a new one-off chat or thread for each request. It’s all there. It has drawbacks I’m seeing now, though. A big one is if you’re managing multiple projects simultaneously through a single choke point. When you’re talking to one agent in one stream about three or four simultaneous things you’re working on, it can be hard to track those topics weaving in and out between each other. I just keep throwing things at my Dot, and it juggles them no problem, but then it responds and I have to sort through everything to understand what’s happening with each work stream. I also feel like when we’re juggling things, I have to preface each input with what stream it refers to, and now I’m adding context with each message and that takes more work than having separate threads. So, enter the long monothread. Muse lets you do this with side chats for dedicated conversation. ChatGPT lets you do this, but not with your Dot. Currently you have to do either Chat or Work threads, and Chat threads can’t manage Work threads, while Work threads don’t have dynamic UI. Oy! Claude is improving in this area, merging Chat and Cowork, and making projects monothread, with one manager thread (or agent, really) overseeing worker threads in the background. Finally, there’s the one-off chat model, the disposable chat model, which I think has a decreasing niche. It feels like most one-off chat questions should really be sent via direct message, and then responses created proportionally to the depth of the request. With all this said, perhaps a good approach is something like this: 1. You always start with an agent in direct message mode. That’s the default, it’s natural, it’s how we typically interact with humans. 2. The agent responds as is appropriate based on the request. A simple question just gets a simple answer. A more complex question gets a “chat” response that can incorporate dynamic UI elements. This is returned inline and you can expand it if it’s very long. Basically, it becomes like a document appended to the direct message response. 3. When the agent sees that you’re repeatedly working on something, it suggests creating a monothread that’s essentially a side chat with the agent dedicated to that topic or project. It can proactively suggest creating these and then spin them up with the relevant context. This would be similar to how I work with colleagues in Slack. Simple question, simple answer in DM. More complex question, longer answer possibly with documents appended in DM. Lots of back and forth on a topic, or specific deliverable, create a dedicated channel. That feels right.