The newest agent products are logging the unglamorous problems in public. Buzz's issue tracker carries an opaque completion string, an inherited private key, and a channel that did not survive a restart, while Notion and Linear walk toward the same place from the durable-object end.
The category is already filing the tickets
This is not a thought experiment about a model that does not exist yet. It is a maintenance problem that the newest products in the category are logging in public.
Block's Buzz is an agent-native workspace where humans and agents hold separate identities and events are signed. Its public issue tracker is the most useful document in this category right now, because it is where the ambition meets the shell. One open issue asks for the opaque Markdown string an agent returns on completion to be replaced with an inspectable result manifest. Another describes a raw private key inherited into a model-controlled shell. A third reports a channel that did not survive a restart.
Cartoon about the difference between a record and a result: the delivery was fulfilled exactly as specified, on time, and is about to be signed for, while the outcome it produced sits in the same frame entirely unaccounted for by the paperwork.
Read them together and a shape appears, which is that each of these products solved the interesting problem and then inherited three boring ones. A signed event log does not make an outcome legible. An agent-native workspace does not isolate credentials by virtue of being agent-native. A new primitive does not persist merely because it is new.
Buzz deserves credit for that. It is filing in public, on a repository anyone can open, what the rest of the category is quietly discovering in private.
Agent-native startups are the loud threat. The quieter one comes from the structured systems, which are walking toward the same place from the opposite end. Notion is shipping scheduled agents with run logs and reversible changes. Linear keeps the human as primary assignee while agents operate as scoped app users. Both of them start with a durable object and add conversation to it, which is the reverse of Slack's problem and probably the easier direction to travel.
Two public positions on Slack: a criticism that it manufactures fake work, and a defense that its layout is where every agent interface is converging. The article's turn is that both are describing furniture — the panes are settled, and what is not settled sits one layer underneath.
Meanwhile, an argument about furniture
Sam Altman uses Slack every day at OpenAI and has said on the record that it “creates endless fake work.” His replacement was agents. That was a November 2025 interview, and the qualification attached to it has travelled far less than the insult: OpenAI was nowhere near that future and had not tried it.
The criticism — Sam Altman, November 2025 interview
The designer shadcn took the other side and absorbed a week of grief for it. “Slack is close to being the perfect UI for most apps,” he wrote, betting that most interfaces, even IDEs, converge toward a Slack-like design. When it landed badly he came back with receipts and pointed at the apps everyone already has open. Explorer on the left. Chat in the middle. Preview on the right. Then the part that is a business claim rather than a design one: “Whoever nails this shape owns where work happens next. The 2030 Microsoft Office.”
The defense — shadcn
One of them thinks the shape is a disease. The other thinks it is a moat. Both are describing where the panes go. The panes are settled. Open any agent product shipped this year and count them. What is not settled sits one layer underneath: the moment a sentence in the middle pane becomes an act in the world, and what has to be true when it does.
A message is a superb unit of conversation and a poor unit of work. Slack's own developer documentation draws the line between message-bound interaction and persistent Work Objects, and GitLab has run the operating-model version of it in public for years.
What a message cannot hold
A message is a superb unit of conversation. Author, timestamp, destination, reply path, social context.
It is a poor unit of work. Work needs the boring things a message has no field for. A stable identity, an owner, a state, an acceptance condition, dependencies, a change history. And some definition of done that was written before the work started, rather than assembled afterwards to fit whatever happened.
Slack's own developer documentation draws exactly that line. Block Kit renders an interaction bound to a message timestamp. Work Objects represent persistent external entities with permanent identity and deep links, so the object can surface in Slack while its truth stays in Salesforce, Linear, a tracker, or a document.
Cartoon about where work actually rests: the figure who appears to carry the load is not carrying it, and the thing bearing the weight is improvised and unexamined — the inspection checks only that the load is still up, never what is holding it.
Reading that as a concession gets it backwards. It may be the most important line Slack has drawn.
GitLab has run the operating-model version of it in public for years. Slack is a communication surface and not the source of truth, and decisions return to a durable system. A short call can beat a hundred replies, provided the decision lands in the record.
An agent does not blur that line. It stands on it, with weight.
Almost every component of an authorization layer already exists in Slack's documentation — scoped agents, user-scoped search, per-tool approval modes, audit events, retention and Slack Connect — with Salesforce's FY26 filing naming Slack the primary conversational interface. Architecture, not adoption.
The parts bin nobody is counting
Slack's critics skip this part, and Slack itself undersells it.
What Slack already documents
Almost every component of an authorization layer already exists in its documentation.
Conversation
Third-party agents are apps with scopes, and their access moves with installation, channel membership, and the permissions of whoever invoked them.
Scoped access
Real-time Search is user-scoped and requires additional consent for private messages and DMs.
Consent
Slackbot's MCP controls mark a tool always allowed, approval-required, blocked, or custom.
Audit
Audit events can name Slackbot as the acting party.
Durable governance
Retention, legal hold, and Slack Connect extend the perimeter, with the honest caveat that a shared channel leaves each organization governing its own copy of the record.
The corporate parent has said out loud what this is for. Salesforce's FY26 filing calls Slack the “primary conversational interface” for its Agentic Enterprise. Governed data underneath, execution in Agentforce, conversation in Slack.
None of that is adoption, reliability, or outcome, and this piece has no inside access with which to claim otherwise. It is a parts bin. But it is a better parts bin than anyone starting an agent workspace from scratch this year will assemble, and it sits under the one surface where people, identity, history, and organizational boundaries already meet.
An agent inheriting your access also inherits an organization's history of never revoking anything, and it treats every stale grant as a legitimate source at machine speed. Retention deletes the message on schedule; it does not delete what the message caused.
Permission-aware is not permission-correct
Which is where the trouble starts.
An agent that inherits your access also inherits your organization's long history of never revoking anything. It will faithfully reproduce a stale group, an overbroad channel, and a decade of casual oversharing, and it will do all of that while obeying every rule on the list. Every one of those grants was correctly approved at the time. None of them was ever taken back.
Cartoon about inherited permission: a vampire may not enter uninvited and may enter forever once invited, so a permission correctly granted long ago outlives the reason for it, the people who granted it, and even the ownership of the house — and the family has stopped treating it as remarkable.
The difference is what happens next. A colleague holding that much accumulated access uses almost none of it, because they open the three channels their job actually touches and forget the rest exists. An agent holding the same grant treats every one of them as a legitimate source, at machine speed, on every request.
A permission nobody revoked is a memory with no expiry. Slack does have expiry: retention and legal hold delete the message on schedule. What they do not delete is what the message caused. An agent reads a channel and writes a conclusion into a customer record. Ninety days later the source is gone while the conclusion sits there, attached to a decision nobody can trace back to anything. The deletion was correct. The provenance died with it.
Slack's agent guidance reads like a company that knows this. It recommends visible status, streamed plans, explicit controls, reversible actions, citations, least-privilege scopes, and deterministic fallbacks. Nobody writes that list for a surface where ambiguity is harmless. It is a company describing, in the polite register of design recommendations, a grammar that conversation does not have.
Per-tool approval works on the first write and decays into reflex somewhere past the twentieth. That is the author's inference, stated as such: nobody publishes approval rates or rejection rates, and the falsifier is named — publish the number and the problem shrinks.
The twentieth approval
Then there is the failure that nobody in this category has answered, including the model I am about to propose.
A per-tool approval works beautifully on the first write. A person reads the request, weighs the stakes, clicks yes. It works on the second. Somewhere past the twentieth, in a week where the agent has been performing well, the click stops being a decision and becomes a reflex. A reflex is not authorization, whatever the audit log records.
I have no data on that, and neither does anyone else, which is the actual problem. Nobody publishes approval rates. Nobody publishes how often a human approver rejected the thing in front of them, or how many seconds they spent looking at it before agreeing. That single number is the load-bearing assumption under every human-in-the-loop architecture shipping right now, and it is the one number the category does not collect. If a vendor publishes it and it holds up under volume, I am wrong and this problem is far smaller than I think it is.
Until someone does, the approval step is a critical component that nobody measures.
Slack's 97-minutes figure and Salesforce's 138,000-hours estimate are published without a sample, a control group, or a counterfactual. The article's own division puts them at about 3.29 hours per employee and $46.38 per hour. There is a price for the hour saved and none for the hour spent checking.
What an hour is worth, and what checking is worth
The industry's answer to most of this is to point at a productivity number, and the productivity numbers repay a close reading.
Slack's 97-minutes-per-user-per-week figure came from an internal pilot analysis published without a sample size, a control group, or a confidence interval. Salesforce later estimated that more than 42,000 employees using Slackbot saved 138,000 hours a week, and attached $6.4 million of weekly productivity value to the total.
Divide it out. About 3.29 estimated hours per reported employee, at roughly $46.38 per estimated hour.
A company is entitled to estimate its own savings, and these are clearly labelled as estimates. The arithmetic is fine. The interesting question is where its boundary was drawn, because a measurement that counts one side of a transaction will always find that side profitable. There is a dollar figure for the hour the agent saved. There is none anywhere for the hour someone spent checking whether it should have been saved, and nobody reports an exception rate, a reversal rate, or a count of actions taken that nobody had authorized.
The number works because the other side of it was never counted.
That is the shape of every problem in this piece. Agents can already do the work. What nobody can yet do is keep the books on it.
Cartoon about one-sided measurement: the job that was done has been priced and invoiced down to the line item, and the far larger cost of doing it is standing in the same room entirely uncounted, so the only figure anyone can examine is the one from the side that was measured.
Keeping the books starts by fixing the task. Pick a bounded class — route a support request, update a CRM record, capture a decision, triage an incident — and then report separate quantities against fixed denominators instead of one blended score:
- eligible tasks, and tasks attempted
- tasks passing a deterministic acceptance test written before the run
- exceptions escalated, and actions taken that nobody authorized
- minutes a human spent reviewing
- provenance coverage, and reversals that actually worked
- outcomes that landed in the system of record they were meant to land in
Every one of those is collectable today with no new science. None of them is flattering, which is the likeliest reason none of them is published.
An editorial argument, not a roadmap: treat the moment of authorization as a signed instrument. Six things fixed before anything runs, reversibility rather than sensitivity as the line that needs a countersignature, a published plan during the run, and a result rather than a victory sentence at the end.
What a signature would have to contain
No vendor has committed to any of this, Slack least of all. What follows is an editorial argument and should not be read as a roadmap.
Treat the moment of authorization as a signed instrument rather than a message that got lucky.
Before anything runs, six things have to be fixed and visible: the named task, the durable object it is allowed to touch, the accountable human, the exact sources it may read, the writes that need a countersignature, and the acceptance test that decides what done means. Reads and drafts can proceed without ceremony, because nothing has left the building. Sending and mutating cannot. Reversibility draws that line, rather than sensitivity, and the difference is practical: a machine can check whether an action can be undone, and a policy meeting will never agree on whether something is sensitive.
While it runs: the plan, published before execution rather than reconstructed after it. Provenance attached to each step. A named owner for anything the sources could not resolve, because an unresolved clause deserves a name rather than a guess.
At the end, a result instead of a victory sentence. Not “Done.” A statement of what was checked, what passed, what was touched, and how long the reversal window stays open. Then the whole act lands on the durable object, so the next person inherits a decision rather than a thread, with the exception still attached and still owned.
None of that is magical. It looks a great deal more like a purchase order than a coworker, and the dullness is the reason it would hold.
Every element of a signed instrument costs the user something at the exact moment they were promised magic, so it loses every demo and gets built after the first expensive mistake. Slack ships the pieces already, as settings administered separately, composing into nothing a user would recognize as a single act.
Why it does not exist yet
Drawing this is easy. Shipping it is hard, because every element costs the user something at precisely the moment they were promised magic. Naming the object is work. So is reading the plan, and so is countersigning, and none of it is work anybody came here to do. A product that asks for all three loses every demo to a product that says “on it” and returns a confident paragraph.
Which is why, at most companies, this gets built after the first expensive mistake instead of before it.
Slack's advantage is that it could build it before. Its disadvantage is that it currently ships these pieces as settings — membership, app approval, per-tool policy, retention, audit, Work Objects — administered separately, by different people, in different screens, composing into nothing a user would recognize as a single act.
The panels were never the question. The question is whether the thing reading six words on a Friday can tell being talked to from being told — and whether the sentence can carry its own paperwork, giving the last free instrument in business a price.
A message you can sign
Every workplace tool ever built was sold as the end of email, and every one of them became a place where people type things at each other. Slack won that fight so completely that the products trying to replace it are quietly rebuilding it, panel by panel.
So the panels were never the question. The question is the six words someone types at 4pm on a Friday, and whether the thing that reads them can tell the difference between being talked to and being told.
Get that wrong and you have built the fastest way in history to do something nobody approved.
Get it right and the sentence carries its own paperwork. Who allowed it. What it touched. How to take it back. Where it lives now that it is finished. The last free sentence in business finally acquires a price, and everyone who sends one becomes, quietly, a signing authority.
That is the job Slack is closest to and furthest from admitting. Somebody is going to do it.
The interface will look like Slack either way.