Work queue
All the tasks the agent has accepted but not yet started.
An agent with a queue is an agent with a plan. A visible queue lets the user reorder, drop, and approve future work at a glance. Without it, you're trusting a memoryless pipeline to not lose your intent, and trusting the pipeline to not auto-run something you didn't approve.
The queue is what separates a chatbot from software. It's also what separates agentic products that users trust long-term from the ones they quietly stop opening after a month.
"A queue you can't see is a queue you can't trust."
Ordered rows, one task each.
The queue is a list. One task per row. Each row shows the task's title, its ETA, the tool(s) it needs, and its trust class (auto, ask, manual). The user can reorder, promote a task to the front, drop a task, or bulk-approve everything in a trust class.
Trust class is the critical affordance. Auto means the agent will run without asking. Ask means the agent will pause for confirmation. Manual means the user has to explicitly press go. The queue shows all three states in the same list so the user can see at a glance what's safe to leave running and what needs their hand.
- 01Summarize the Monday callseta · ~45stools · retrieval● auto
- 02Draft reply to customer #2210eta · ~1mtools · compose● ask
- 03Export Q3 OKRs to Docseta · ~25stools · docs.create● ask
- 04Post retrospective to #eng-alleta · ~15stools · slack.post● manual
- 05Transcribe & index 3 videoseta · ~8mtools · asr + index● auto
Nothing auto-runs without the green. Every row shows its tool and trust class.
Order is a decision, not an accident.
Agents spawn tasks in the order they come up in conversation. That's almost never the order they should execute in. The queue is the user's chance to reorder before things run — to promote the urgent, defer the optional, and drop the things the agent misunderstood.
Without the queue, the first thing an agent does might be the thing the user least wanted it to do.
The queue I'd ship.
- Trust class, always visible. Auto, ask, manual. These should be color-coded consistently across the product. The user should never have to click into a task to learn whether it will auto-run.
- Bulk approve by class. Users with 40 queued tasks need a way to approve the auto-class safely without clicking 40 times. A single button that approves everything in a class (and shows you the list first) is the right escape hatch.
- Reorder is cheap. Up and down arrows. Drag. A "Now" button that promotes a task to the front. Reordering is how the queue stays honest, so make it frictionless.
Invisible auto-run.
The deadliest failure of this pattern is quietly demoting a task from "ask" to "auto" based on a heuristic. Suddenly the user is no longer a co-pilot; they're reading the log after the fact. If the trust class changes, it must be a visible, logged event — not a silent policy decision.
What this pattern gets wrong when it gets wrong.
- Orphaned task
- A task that was started, never completed, and is no longer visible in the interface, even though compute may still be running.
- Ambiguous state
- Running, done, errored, paused all look the same. The user has to infer from context.
- Runaway agent
- An agent that loops, spends, or edits past the user's intent with no visible cap.
Three shipping variants worth copying.
- A drag-reorderable list of queued tasks with per-row ETAs
- A bulk-approve affordance for trusted categories
- A 'promote to now' action that cuts a task to the front of the queue