At 11:03am, an agent in a support team's Slack channel surfaced a diff: one customer record, one field change, the reason in plain text. A human read it and clicked approve. The write hit the CRM. The entry - what changed, who authorized it, why - went into the audit log automatically. That is not a chat conversation. That is a delegation surface with a receipt attached.
The debate about whether chat is the wrong interface for AI agents has been running hot this year, and most of the critique is right. But it is aimed at the wrong target.
Why "chat is wrong for agents" is mostly right
Agent UX is fundamentally different from chatbot UX: it is goal pursuit across tools, time, and systems, which means state management, permissions, retries, and audit trails - none of which a chat window handles well. The specific failure mode is structural. If an agent misunderstands a goal and you correct it ten messages later, the wrong version remains visually equal to the right one. A confirmed decision, a temporary hypothesis, and an unresolved question all look like the same object: a message bubble.
A chatbot needs a conversation thread, input controls, and response formatting. An assistant adds confirmation dialogs. An agent interface requires all of that plus a plan visibility layer, real-time progress tracking across multi-step workflows, intervention points for mid-process redirection, and an audit trail recording what the agent did and why. Shipping a capable agent inside a plain chat thread is a bit like giving someone a powerful piece of equipment with no instrument panel.
The chatbox became the default AI interface because it was the cheapest to ship and the right thing to ship at the time. It works when the user does not yet know what they want. It fails when the user knows exactly what they want, and the blank text box becomes a tax on every interaction.
That is the honest version of the critique. But it elides something important about where most workplace agents actually live.
Where the Slack thread does something surprising
Here is the steelman for the other side: the products winning in 2026 put the AI behind a verb, a canvas, a delegation, an ambient capture, or some sort of interactive output rather than behind a prompt
- and a Slack approval message, done right, is exactly that. It is a delegation surface. The verb is "approve." The output is structured. The human is not typing into a blank box; they are reviewing a specific proposed action.
Autonomous agents run 24/7 in the background. When they need to provide an update or ask for an approval, Slack is the most natural place to bring humans back into the loop. That is not a consolation prize. When an agent posts a diff - "field X on record Y will change from A to B, reason: rule Z" - and a human clicks approve, you have achieved the core requirement: users feel in control of a system whose entire value proposition is that it operates without their involvement.
The gap is not the channel. The gap is the receipt.
The two fields teams most often skip are the reasoning summary and the human authorization context. Without them you can see that a record changed, but not why the agent thought it should, or who let it. A Slack thread where the agent posts "done ✓" is not an audit trail. A Slack thread where the agent posts the exact diff, the triggering condition, and the approver's name - and writes all three to a structured log - is.
The design mistake that makes chat genuinely dangerous for agents
Give users too much control and you have defeated the purpose - every action requires approval, every decision needs a click, and the agent becomes a very expensive confirmation dialog. Give users too little control and trust evaporates the first time the agent does something unexpected. The user cannot intervene, cannot course-correct, and starts treating the system as a liability rather than an asset.
This is the real design tension, and it plays out in a specific failure pattern in Slack: agents that mix answering and acting inside the same thread, with no visual separation between a response that is informational and one that triggered a write. The thread scrolls. The action disappears into history. Someone asks "did it actually update the record?" and three people have to search backward through messages to find out.
Multi-step workflow tracking needs a timeline view that survives interruption. A chat thread cannot serve as a workflow tracker because conversational cadence and workflow cadence run on different clocks.
The fix is not to leave Slack. It is to stop treating the thread as the record of what happened and start treating it as the trigger point. The thread captures the delegation. The actual state - what ran, what was approved, by whom, when - lives in a structured log that the thread links to. Claude Routines (shipped April 2026) execute multi-step workflows in the background, and each run creates a reviewable session. The review surface is a trace timeline: users can review what the agent did after the fact. The pattern validates the core argument: background execution requires a review surface that is not the original conversation.
Beagle in action#ops-approvals, 11:03amWhat "right interface" actually means for Slack agents
The teams getting this right are making three specific choices.
Separate answer threads from action threads. A question that gets an answer is one kind of interaction. A request that triggers a write is another. They should not look identical in the channel. Even a consistent naming pattern - "[ACTION PENDING]" vs "[ANSWER]" - gives the team enough signal to scan.
Make the receipt non-negotiable. Every agent action should produce a receipt: what changed, where, with what permissions, a diff or confirmation, and a rollback hook. In Slack terms: a structured message with the before/after, the triggering condition, and the approval context. Not a "✓ done" and nothing else.
Escalate on risk signals, not on everything. Escalate on risk signals - dollar amount, external recipient, irreversibility - not on every write. The entry a reviewer sees should show the exact before/after diff, so a real approval takes 15 seconds and a suspicious one gets caught. An agent that pages you for every minor status update trains your team to ignore it. An agent that pages you only for consequential actions, with full context attached, earns trust.
A teammate like Beagle is built around this model: the agent drafts and surfaces the action; a human approves it; the approval and the action are logged together. That matters because an approval you cannot later prove happened is not a control - it is a rubber stamp with no paper.
AI agents in Slack: common questions
Is chat the wrong interface for AI agents in Slack?
Partially. Chat fails as a workflow tracker for multi-step autonomous tasks because conversational cadence and workflow cadence run on different clocks. But a structured Slack approval message - with a diff, a triggering reason, and an approve/reject action - is closer to a purpose-built delegation surface than most people credit. The failure is usually in the receipt, not the channel.
What should an AI agent post in Slack when it takes an action?
At minimum: what changed (a before/after diff), what triggered the action (the rule or condition), who approved it, and a link to the structured log entry. A plain "done ✓" message is not an audit trail. Teams most often skip the reasoning summary and the authorization context, which makes root-cause analysis later nearly impossible.
How do you keep a human in the loop for Slack agents without creating approval fatigue?
Escalate on risk signals - irreversibility, external recipients, dollar thresholds - not on every write. An approval prompt that shows the exact diff lets a real approval take under 15 seconds. Approvals that expire unresolved should fail closed, not auto-approve. An agent that pages constantly trains teams to click through without reading.
Do AI agents in Slack need a separate audit log, or is the thread enough?
Both are needed, but they serve different purposes. The thread captures the delegation in the moment. The structured log - separate, tamper-evident, queryable - is what you show an auditor or use for root-cause analysis. A thread you have to search manually is not evidence; it is archaeology.
What is the difference between a Slack chatbot and a Slack agent?
A chatbot answers questions and returns a response in the thread. An agent takes a goal, reasons across multiple steps, calls external tools, and changes state in real systems. The interface requirements are different: an agent needs approval surfaces, a plan visibility layer, and an audit trail - none of which a plain conversation thread provides on its own.