The activity panel isn't optional. It's the product.
One stream can't do two jobs. Most agent interfaces force it to anyway — and that single non-decision is why your product feels confusing even when the model is good.
Here's the failure mode. A user sends a message. The agent takes four actions before it replies: searches, calls a tool, reads a file, drafts an answer. All four land in the chat thread. Now the conversation — the place where a human sets goals and gives input — is buried under a log of unsolicited machine activity. The user scrolls up to remember what they asked. They can't tell what the agent did versus what it's saying. Two different things are fighting for the same column of pixels, and both lose.

This isn't a cosmetic problem. It's an architecture problem — and the uncomfortable part is that teams create it by not making a decision. No one chose to merge conversation and task progress. They just never separated them. That omission is the design choice.
Conversation and task progress are two different data types with two different jobs. Conversation is a record of intent and collaboration. It should read like a transcript a human wants to revisit. Activity is a stream of autonomous work. It should read like a flight tracker: glanceable, real-time, disposable once the task lands. When you merge them, you optimize for neither. The chat becomes unreadable and the progress becomes invisible.
The fix is structural, not decorative: separate the conversation from the activity stream. The thread holds goals, questions, and answers. A dedicated activity panel holds the agent's autonomous work: the plan, the tool calls, the intermediate states. This separation is the foundational pattern for trustworthy agent UX, for one reason: it lets the user direct the agent and monitor it in parallel, instead of forcing those two modes to time-share one stream.
- The activity panel is a live plan, not a log. Show the steps the agent intends to take, then check them off as they complete. A user should be able to look once and know: where are we, what's next, did anything fail.
- Make it interruptible. The whole point of seeing the work mid-flight is to redirect it mid-flight. Every step in the panel is an intervention point. If the agent picks the wrong file on step two, the user catches it at step two — not after step five wasted four minutes.
- Disclose tool use, don't dump it. "Searched the web" with an expandable detail beats fourteen raw API traces. Transparency is a layer the user opens on demand, not a firehose pointed at their face.
- Keep one audit trail. When the task is done, the panel should answer "what did it do, and why" without making anyone reconstruct it from chat scrollback. That record is what makes the agent trustable the second time.
The deeper point: in an agent product, the activity panel is the accountability layer between what the user wanted and what the machine did. That's not a side feature you bolt on after the model works. It's the part of the interface that makes autonomy feel safe instead of spooky. Hide it, and even a flawless model feels like a black box. Surface it well, and a mediocre model feels controllable — which, to a user, is most of what "good" means.
Try this audit on your own product. Open it, give the agent a task that takes at least three steps, and watch the screen while it runs. Ask three questions: (1) Can I tell, at a glance, what it's doing right now? (2) Can I stop or redirect it before it finishes? (3) After it's done, can I see what it did without scrolling back through chat? If the answer to any of these is no, you don't have an activity panel. You have a chat log doing two jobs badly. Fixing that is probably the highest-leverage design change on your roadmap.
Sources