What comes after chat?

I've been thinking a lot about what comes after chat. I worked at Slack, so it is the obvious place for me to start, but the question gets strange pretty quickly. Slack was a chat application, sure, but by the time I worked there it was also a brand, a public engineering culture, a way for companies to signal something about themselves, and a very expensive go-to-market operation. Microsoft Teams made that distinction hard to ignore because Microsoft did not really have to make a more lovable chat application; it could include one in a contract its customers already had.

I started pulling on that thread. Slack's S-1 led me to the Teams antitrust case in Europe; Mattermost led me into USAspending and years of Department of Defense contracts; the agent piece led me back through Slack's engineering postmortems and API rate limits. That is a funny set of places to end up when you're trying to answer a product question, but the story makes more sense once you stop treating chat as the whole product.

What I came away with is that Slack did build something meaningfully new, then Slack and Microsoft spent years competing through distribution while Mattermost spent years establishing itself in a market neither had entered. The agent piece is where this becomes a current problem. Chat applications have always had a natural rate limit: a person has to read the message, figure out what to do, and then do it. Once software can read and act through the same systems all day, the architecture stops being an implementation detail and starts determining what the product can actually become.

Slack sold an idea of a company

Slack launched in 2013 after Tiny Speck shut down Glitch and turned its internal communication tool into the product. The origin story became part of the charm: a strange game failed, a very good chat application fell out of it, and teams began inviting other teams without waiting for the CIO to issue a mandate.

That bottom-up adoption was itself a product innovation. Enterprise software normally arrived through a contract and an implementation plan. Slack arrived through a link from the team down the hall. It made workplace chat legible as a category and gave that category a vocabulary: channels, reactions, workflows, apps. Plenty of the pieces existed elsewhere. Slack made them cohere.

What Slack layered on top was marketing in the broadest and most effective sense of the word. The corporate voice made enterprise software feel human, the public engineering culture made it feel serious, and the brand let customers perform being a more open, modern, technically competent company. Even the name became a verb. None of this was fake; the engineering was real, the product was useful, and the company did have a distinct personality. Those facts also made an extraordinarily good sales system.

Slack's S-1 is where the size of that sales system becomes visible. For the fiscal year ending January 31, 2019, Slack reported $400.6 million in revenue, $233.2 million in sales and marketing expense, and a $138.9 million net loss. That means Slack spent 58 cents on sales and marketing for every dollar of revenue it brought in, and still ended the year with a $138.9 million loss.

There is an important accounting detail here. Sales and marketing was not a pure measure of ad spend. Slack included personnel, business development, promotional programs, and its Frontiers conference, but also allocated hosting and customer-support costs associated with free users. That makes it a bad number for claiming Slack simply bought ads until it won, but a very good number for seeing the actual shape of the machine.

Slack's go-to-market system extended into the free product, the customer experience, the category story, and the people required to turn all of that attention into enterprise accounts. Product and marketing were not competing explanations for Slack's growth. The product made the story credible; the spending made the story durable and taught companies to see themselves in it.

Microsoft made the choice disappear

Teams did not run the same play with a larger advertising budget. Microsoft had a better weapon: an existing contract.

If your company already bought Office or Microsoft 365, Teams could arrive inside the bundle. There was no new vendor assessment, no separate budget line, and no need to explain why one chat window was sufficiently better than another. Slack made chat desirable. Microsoft made declining Teams a procurement event.

Slack understood the threat clearly enough to file an EU antitrust complaint on July 14, 2020. The European Commission opened a formal investigation in 2023 and eventually made Microsoft's commitments legally binding in September 2025. Microsoft agreed to offer versions of Office and Microsoft 365 without Teams at a lower price, make it easier for customers to switch licenses, and improve interoperability and data portability.

This was a regulatory complaint and commitments decision, not a lawsuit. The proceeding was European, although Microsoft says most of the resulting pricing and licensing changes rolled out globally in November 2025. Some transition guarantees remain specific to the European Economic Area, and Microsoft still sells suites that include Teams. The details matter because "Europe made Microsoft unbundle Teams" is directionally satisfying and imprecise in almost every other way.

The antitrust case still tells us what the competition was about. Slack's complaint was not that Teams had invented a better model of collaboration. It was that Microsoft could use dominance in one market to erase the purchase decision in another.

I think the distinction is that Slack sold a modern corporate identity, while Microsoft barely had to sell Teams at all. Adopting Slack said something about the kind of company you wanted to build; Teams was already available through a contract the company had signed.

Mattermost made one market expensive to enter

Mattermost is privately held, so there is no S-1 or sales and marketing line to put next to Slack's. What is public is its fundraising and the federal contract record. Mattermost raised a $20 million Series A and a $50 million Series B in 2019, but funding tells us what the company could spend, not where the money went.

I pulled the USAspending records for Mattermost Inc. and Mattermost Federal. The direct awards add up to about $20 million between 2021 and July 2026, almost all of it from the Air Force. The largest was $10.68 million for Mattermost enterprise licenses; another $4.84 million went to Platform One ChatOps; and a separate $1.25 million award was explicitly for scaling Mattermost across Platform One deployments. These are direct obligations to Mattermost rather than a measure of all of its federal revenue.

One thing I had to be careful about was reseller awards. An AFRL report lists a Mattermost license contract through Insight Public Sector with a potential value around $3.48 million, but that is the ceiling on the reseller contract rather than money directly obligated to Mattermost.

The contracts explain how Mattermost got paid. The reason the Department of Defense could use it in the first place is architectural: Mattermost can run on-premises and in private clouds. The company says it operates across IL4, IL5, IL6, JWICS, and other classified environments. I could independently verify the IL4 deployments through government sources; the broader classified list comes from Mattermost rather than a government accreditation record.

By 2020, an Air Force account said AFRL had funded access for 50,000 users and that between 14,000 and 18,000 Department of Defense users were already onboarded. The 349th Air Mobility Wing later put all 2,600 of its members on Mattermost and used it during Operation Allies Refuge. Mattermost also completed a $750,000 AFWERX Phase II contract for command-and-control work at the 618th Air Operations Center. That award is already part of the $20 million total, not an extra number to stack on it.

GovSlack reached Department of Defense IL4 authorization in December 2025. By then Mattermost had been used in Air Force workflows for about five years. Certification gets Slack through the door, but it does not recreate those deployments, contract paths, or the familiarity people already have with the product.

From what I can tell, Mattermost did not beat Slack in defense by building a nicer chat application. It made itself deployable in places Slack could not yet run, then spent years accumulating contracts and operating history there. GovSlack can compete now, but it is entering a market where the alternative is already familiar.

The engineering culture was part of the product

Slack's public engineering culture belongs in this story because the posts did more than explain the system. They recruited engineers and reassured enterprise customers that Slack could be trusted as critical infrastructure. They also left a public record of the constraints those engineers kept running into.

Slack began with a PHP monolith. As the company grew, it moved toward Hack and HHVM and hired people who had already worked on related problems at Facebook, including chief architect Keith Adams. Slack's dataset eventually outgrew a single MySQL primary, so it was sharded with Vitess. Vitess made the distributed keyspace look like one MySQL instance to application code. That abstraction was useful, and it made the physical cost of some queries easy to ignore.

I joined Slack in August 2022 and watched this become a recurring argument. The Datastores team needed application code to respect shard boundaries. Application teams kept writing scatter queries that asked Vitess to fan work across the keyspace.

Two months later, a customer bulk-removed users. The forget user job created work for every channel and thread subscription those users had accumulated, sending an enormous number of queries across multiple shards. One shard fell behind and its MySQL process was repeatedly killed for running out of memory as replicas were promoted. The incident exposed the gap: Slack had distributed the data while much of the application still reasoned about one logical database.

Slack ran a large EC2 fleet of unusually large instances, but many hot paths still expected work to complete within one VM, with Memcached shielding Vitess behind it. Memcached played an outsized role. On a miss, the application read from Vitess and repopulated the cache. Replacement cache nodes came up empty, so rehydrating them imposed a large cost on the datastore at the exact moment cache loss had increased its load. Scaling the web tier did not scale those dependencies.

The postmortems make the inherited shape easiest to see. On January 4, 2021, customers returned from the holiday and Slack hit shortages in its web tier while AWS autoscaling and Transit Gateways saturated together. The February 22, 2022 incident is an even better precursor to the agent problem. Consul maintenance churned Memcached nodes and promoted empty replacements. The hit rate fell. Each miss sent an inefficient membership query across every shard in a Vitess keyspace. Database overload slowed cache rehydration, and automated client retries added more work.

Slack put it plainly: "Client retries are often a contributor to cascading failures, and this scenario was no exception."

Slack throttled client boot, changed the scatter query, and waited for the caches to refill before gradually restoring traffic. Recovery meant protecting Vitess while Memcached rehydrated. It also showed how much Slack's stability depended on keeping software behavior within boundaries set when most traffic came from people.

Slack's postmortems show where pressure collected: the web tier, shared network infrastructure, cross-shard queries, caches, and retrying clients. Go-to-market success bought Slack years of customers, integrations, history, and habit. It also left the architecture with years of accumulated decisions that cannot be unwound because a new interaction model becomes fashionable.

This history helps explain Slack's server-side agent strategy. APIs, hosted search, and server-side agents extend the system Slack already has. A local-first product where tools execute from a person's device requires a different architecture. Slack's agent roadmap starts from those constraints.

Agents remove the human rate limit

Slack and Teams were designed around a person reading, typing, clicking, and occasionally invoking an integration. The person was a natural rate limiter. They could only open so many threads, file so many issues, or ask a bot to perform so many actions before needing lunch.

Agents do not get hungry. They recurse, retry, poll, and operate across many resources at once. They can turn one instruction into hundreds of reads and writes without the person who issued it seeing most of them. The producer of work has changed.

GitHub is where I expected to find the clearest cautionary example. The primary sources turned out to be more specific than the viral version of the story. GitHub's May 2026 availability report says traffic was growing rapidly, driven in large part by AI-assisted and agentic development workflows. The company had more than doubled effective capacity in four months, with Azure serving 40% of monolith traffic and 30% of Git traffic.

GitHub also reported nine incidents that month. The tempting argument is that agents caused those outages. GitHub's own postmortems do not say that. They identify schema migrations, configuration changes, rate limits, routing mistakes, failover behavior, and shared dependencies. Agent traffic created capacity pressure. It is not established as the cause of each incident. The distinction is less dramatic and more useful.

The human capacity problem is easier to prove. Jazzband shut down after AI-generated pull requests and issues made its open-membership model untenable. Curl maintainer Daniel Stenberg ended curl's paid bug bounty after the same kind of submissions imposed more triage work and mental cost than the program could sustain. Curl later reopened vulnerability reporting without bounties. The project did not stop accepting security reports; it stopped paying people to generate a queue it could no longer afford to review. That's to say agents make production cheaper without making judgment free, which is a fairly serious problem for systems built around the assumption that producing the work was the expensive part.

Slack's API policy shows another version of the boundary. On May 29, 2025, Slack reduced the limits for conversations.history and conversations.replies to one request per minute with 15 objects per response for newly created commercially distributed apps outside the Marketplace and new installations of existing unlisted commercial apps. Existing installations were grandfathered. Internal customer-built apps kept 50 or more requests per minute and up to 1,000 objects. Marketplace apps were unaffected.

The limits are not global across an integration. Slack's Web API limits generally apply per method, per workspace, per app. Exhausting one method does not take down every other endpoint. This matters because a much more alarming version of this story circulated among developers in early 2026. It also was not what Slack's documentation said.

Slack describes the change as protection against unvetted applications exfiltrating conversation data. That is a credible security concern. An agent capable of walking the history of every channel can move a great deal of sensitive information very quickly. Slack also says the Marketplace is the only appropriate channel for commercial distribution and points developers toward its Real-Time Search API for permission-aware access.

Both things can be true. The security boundary is real, and the implementation makes Slack's review process the gate to commercially useful access. There is no documented blanket exemption for something called an Agents API. The verified distinction is whether an app is internal, approved for the Marketplace, or commercially distributed outside it.

Microsoft used a bundle to govern which human collaboration product reached the customer. Slack uses review, rate limits, and new APIs to govern which agents get useful access to the incumbent. These are not equivalent actions, but they come from the same instinct: when the underlying competition changes, control the distribution boundary. In that sense the technical response is also a go-to-market decision.

A searchable log is not a memory system

Slack has always made an unusually literal promise in its name: Searchable Log of All Conversation and Knowledge. For a person, that log can be useful. I can search for a phrase from six months ago and reconstruct the decision because I remember the people, the project, and what happened afterward.

The log did not remember any of that. Decisions happen in huddles, documents change, threads end without resolution, and people correct themselves somewhere else. Search makes those traces easier to find. Putting an AI summary on top can make them easier to read. Neither makes them current or authoritative.

Recent work on coding agents gives me another reason to be suspicious of memory as a pile of text. A 2026 study of repository context files across several agents and models found no improvement in task success and more than a 20 percent increase in inference cost. That result is narrower than saying agents never benefit from memory. A separate ACL study found that memory helped sequential agents avoid repeated mistakes while making tree-based agents less exploratory. Memory has to fit the work and the agent using it. More remembered text is not the same thing as better state.

Slack also looks like a convenient pub/sub system for agents. It already has events, subscriptions, permissions, and a place to report results. The problem is that a channel event was written for a person. A message can be a request, a suggestion, a joke, an abandoned idea, or an approval whose conditions were explained in a meeting. A person can notice the ambiguity, remember the surrounding context, or ask. An agent needs something less fuzzy: current state, explicit authority, an operation it can safely retry, and a durable account of what changed.

A system built only for agents misses the other half. People need somewhere to ask an incomplete question, disagree, explain a judgment, interrupt the plan, and work out what they mean. I do not want to replace that with a task state machine.

Whatever comes after chat has to encompass both. I expect it to have channels because people need them. I expect agents to work against something more explicit than the transcript: tasks, state, events, permissions, and a durable record of actions. The channel is where people make sense of the work. It should not also be asked to serve as the agent's memory, queue, and database.

The replacement and extension bets are already live

The current products make the tradeoff visible. Ano is a small, current example. It presents itself as a Slack alternative for AI-native teams and describes a local-first sync engine that keeps messages and the search index on the device. Pressing a key inside a channel opens a shell running the user's Claude Code with local CLIs and MCP servers. The result can be posted back into the channel for the rest of the team.

Ano's line is that Slack is "a loud lobby where you talk about work." Ano wants to be the room where the tools do it.

Those are Ano's own product claims, not an independent performance evaluation. Ano may win, change direction, or disappear. I find it interesting because it keeps the channel for people while refusing to make the channel the agent's execution environment. The work begins near the user's tools and only the result has to return to chat.

OpenAI and Slack are working from the other direction. OpenAI's Workspace Agents are a research preview for shared, repeatable workflows that can gather information and act across Slack, Google Drive, and Microsoft applications. They can be scheduled, connected through custom MCP servers, and deployed into Slack channels. Lindy takes a similar route through a conventional Slack integration: listen to selected channels, receive events, and take actions through Slack's APIs.

Slack and Salesforce are building both sides of that extension. Slack's hosted MCP server and Real-Time Search API let outside assistants query Slack context and take permission-aware actions. Slackbot can act as an MCP client for other products. Salesforce's hosted MCP server can expose configured Agentforce agents and prompts as tools to ChatGPT, Claude, Slackbot, and other clients. Agentforce 360 then makes Slack an interface for those agents.

That strategy preserves the part Slack is already good at: a human surface with an established permission boundary. It also lets Slack approve, bundle, and meter the agents that pass through it, so the hub starts to look a lot like a tollbooth. What it does not establish is that Slack's archive is the right memory or event system for those agents. Outside agents still encounter the API limits described above, and the useful state has to exist somewhere more reliable than a conversation.

Neither side gets the other for free. Ano still has to make local execution legible and governable for a team. Slack still has to give agents reliable state without treating a conversation archive as one. That is the experiment I care about.

Distribution cannot prepare the architecture

Slack made workplace chat into a product category and a corporate identity. Microsoft showed that an existing distribution system could overwhelm both. Mattermost showed that a smaller company could secure valuable ground by concentrating architecture, accreditation, procurement, and money on a boundary the broad incumbents had not crossed.

Fleets of agents add two constraints those strategies never had to solve: machine-paced load and a need for state that is more reliable than human conversation. The incumbent response will always contain go-to-market choices because architecture determines what is expensive and distribution determines who is allowed through.

This is why I do not think the next Slack is waiting for somebody to invent a richer chat window. It has to make room for human conversation and machine execution without pretending they need the same interface or the same memory.

People will still work in chat, agents should not have to.