We’re rapidly moving toward a world in which we all constantly have multiple agents working on our behalf. Depending on who you ask,this may or may not be the definition of AGI — but either way, it’s clear that the current state-of-the-art in agents is to havemany small agents doing relatively narrowly scoped tasks rather than to have one super-agent that does everything. The level of control, visibility, and reliability is much higher with a swarm of smaller agents.

That naturally raises the question of having these agents communicate with each other. What happens when one agent needs to ask another agent for help or decides to escalate an issue to a different agent for resolution? That’s the promise of protocols like A2A — we’ll define a secure standard that all agents can conform to, and then Agent 1 and Agent 2 can happily go back and forth with each other collaborating on an issue.

The idea of creating a space for agents to collaborate is extremely important. Different agents will have different kinds of expertise, and they will naturally need to work together on those tasks. Having a well-defined way that different agents interact with each other is absolutely necessary.

Unfortunately, we think that creating an opaque protocol for agent communication is a terrible idea (at least for the foreseeable future). The key problem with A2A is that it enables communication without clear visibility into what information is being exchanged and what decisions are being made will lead to extremely poor visibility, debuggability, and control.

We’ve discussed many times that we believevisibility and control are the cornerstones of good AI UX. At least in the context of enterprise applications, A2A is the exact opposite of that. Let’s consider a very simple scenario where two agents might be collaborating with each other: There’s a sales agent that is interacting with a customer, and it gets a question it doesn’t have the full context on, so it asks for help from an internal product expert agent, and that agent mistakenly shares not-yet-public product roadmap plans with the sales agent, which in turn ferries that information back to the customer.

How might we go about debugging this in a world where these two agents are interacting via A2A? It’s not immediately obvious. Likely, you’d know something went wrong when the customer raises a question about a feature that they shouldn’t have known about. You’ll probably know intuitively that the sales agent gave them that information, but you might be confused about how the sales agent knew that in the first place. Your first step might be to double check what documents the sales agent has access to — but this obviously wasn’t the issue! Depending on how well the sales agent makes its internal thinking process visible, you’ll have to go to that system, see what steps it took, then discover that it made a call out to the product expert agent. Then you switch over to investigate that agent, figure out that it was this agent that made an access control error, and change the corresponding behavior.

In other words, A2A has recreated all of the triage and spelunking that teams were previously doing to diagnose issues.The opacity of the protocol is the key issue here.

What you really need is a human-friendly, text-first, searchable way for agents to interact that’s already a part of every team’s workflow. In other words… Slack.

You might think we’re being a little facetious when we say that you should replace A2A with Slack, but we think this is a perfectly reasonable argument (if a little overstated).

Let’s go back to the scenario above with the sales and product expert agents. If there was a dedicated Slack channel where sales team asks for product help (whether human or agentic), that would be natural place for these two agents to collaborate. If this channel was the defined protocol for interaction, you would be a single Slack search (which has thankfully gotten dramatically better!) away from figuring out where this feature was mentioned in a sales-product interaction and why the wrong information was provided.

This pattern works for a whole host of other interactions. Here’s a couple simple examples:

SRE + Engineering: When a system like Datadog raises an alert about a potential product error, an SRE agent can automatically step in and diagnose the issue in that Slack thread. If the issue is a false alarm, they can mark the thread as resolved, and if it requires human intervention, they can tag the appropriate on-call team.

RunLLM + Cursor: As of our last launch, RunLLM can now analyze the logs related to an issue and make a recommendation about what caused the customer’s error. If that error requires internal code changes, you could tag the Cursor Agent app and have it pick up from where RunLLM leaves off. There’s many, many more possible examples, but this hopefully illustrates the point pretty clearly. Once you adapt this framing, there’s a variety of other reasons why Slack is the most natural collaboration point for most agents.

For better or worse, we all spend most of our days in Slack, so during the adoption and trust-building process with a new agent, it becomes very easy to work monitoring the agent’s behavior into your daily workflow. (For example, some of our customers have us mirror every RunLLM conversation into a dedicated Slack channel for quick internal review — this is much easier than navigating to the UI.) Naturally, whenever an agent reaches the limits of its capabilities and needs to ask for help from a person, Slack is the easiest way to surface that issue. And if two people need to discuss whether an agent behaved correctly, well, where else would they do it but Slack?

In other words, Slack is the optimal place for collaboration between agents because it’s already the place where all other collaboration happens. Once your mental model of an AI agent is “another coworker”, that agent should work with you and its other coworkers — human or AI — in the same place.

Now, the slightly overstated part of this argument is that Slack is the end-all-be-all. It is, of course, not the only possibility for effective collaboration. At RunLLM, we’ve built similarly deep integrations into common support tooling like Zendesk, where our agent and our customers’ employees can have back-and-forth discussions that are visible to their teammates. But — regardless of your opinion on its merits — Slack is absolutely the least common denominator for most enterprises in terms of communication, so we think its very worthwhile to invest in making your agent as Slack-friendly as possible.

We also think that Slack itself could be doing much more to enable agents to make their work clear and actionable to customers — but that’s a discussion for a whole another blog post!

Agentic workflows are very clearly going to become a part of every company’s daily operations — it’s just a question of when, not if. Once you have multiple agents interacting with each other, you’re not going to want them to live in silos, so the natural problem to solve is where and how those agents interact with each other. It’s always fun to develop a new protocol, but our hypothesis is that the success of these agents is all about working where and how you work. Today, that’s Slack — and there’s no sign that’s going to change.

If you can make it clear to your customers how you’re doing work, how they can fix your work, and when you need help, that will go incredibly far in building trust with them. That comes down to — again — control and visibility. Forcing them to navigate to a UI to see what you’re doing isn’t going to cut it. Whether you like it or not, Slack is the future of agentic interaction.

No posts