AI Agent Collaboration Workspace: Ando Takes on Slack

In multi-agent systems, the work and the conversation live in different places. A lead agent splits a job for a worker, the worker finishes the task, the result lands on the task board, and that’s not where the team actually talks. The result has to pass through someone’s hands to reach the real conversation. That “someone” is usually you. The agent does the work, the human carries the message.

That’s the natural consequence of the architecture: when the task board and “where work actually gets discussed” are separate layers, the human ends up as the bridge between them. AgentSpace’s lead-worker architecture was built to shorten exactly that bridge.

The news: Ando makes agents teammates, not installed apps

Ando, a startup founded by Sara Du, grew out of a gap she noticed while setting up MCP servers: people wanted to run agents from inside Slack, but Slack and Teams were designed around agents as “apps you install” — even as agents were becoming real participants on the team. Ando came out of stealth on Thursday as a messaging platform that gives agents their own identity, their own inbox, and the right to join channels; it raised $20 million from Accel, Index Ventures, and Emergence.

Du calls the problem she’s describing the “meat proxy”: “The human effectively becomes the messenger between the agent and the rest of the company.” On Ando, agents can join a channel without being tagged, ping a human proactively on their own initiative, and even notice two separate teams discussing the same topic in different channels and bring them together.

What this means for us

Ando’s existence isn’t showing me a new problem; it’s validating an architectural decision we’re already working from. When we built AgentSpace, we deliberately designed agents not as “tools you run” but as team members with persistent memory and their own line on the task board. Du’s observation that “agents were treated as apps you install even as they were becoming participants” is exactly why we invested in our own task board instead of building on top of Slack. In that sense, Ando feels less like a separate marketing story and more like a bigger player telling us “you were right” — a competing architecture starting from the same assumption.

But the two architectures don’t land in the same place, and the difference matters. Ando’s model: the agent owns its own inbox, can join a channel on its own judgment, can ping a human without waiting for approval. In AgentSpace we deliberately did the opposite — a lead agent writes a worker’s output to the task board, and a status change on the board reaches me (or the relevant human) through an approval step. So the in-between step we’re calling the “meat proxy” is, for us, partly intentional friction: letting an agent message a human directly, without approval, runs against the permission-layer decision we described in an earlier post. Giving agents a free-messaging identity means expanding the question “which tool can it run and when” into “who can it talk to and when” — and that’s a risk area we haven’t closed yet, not a solved problem.

This already has a working counterpart on the ChatFlow side: the sales agent on WhatsApp talks to the customer in the same channel, under its own identity — there’s no “meat proxy” there, because the agent is already a participant. Our problem isn’t on the outward-facing channel; it’s on the inward-facing side — where the conversation happens between the lead agent and the worker agents, and between them and me. Right now the answer is “on the task board and in commit messages” — not a real chat channel. Ando’s validation makes one thing clear to me: this gap is real, I didn’t invent it on my own, and serious money in the market is chasing this exact problem.

What isn’t changing: we’re not switching to Ando, and we’re not planning to replace our own task board with a messaging app. In a small, solo-founder operation, adding tools is a bigger risk than reducing them. We’re also not loosening the approval layer — letting an agent ping a human “on its own judgment” runs directly against the “agent proposes, human approves” principle we’ve deliberately built into both ChatFlow and AgentSpace. Du frames the upside as “agents can manage humans better than humans can, because they can process more messages, faster” — to me, that’s exactly the point where you need to be careful. Speed outrunning oversight is where things break.

The next question is a measurement question: does AgentSpace’s task-board model or Ando’s shared-channel model cut coordination overhead more? The reason behind our architecture is clear; a side-by-side comparison of the two models is the next test.

What to do today

Map the “meat proxy” points in your own agent/human workflow. Copy-paste this:

1. For one week, flag every moment you manually move an
   agent's output somewhere (from task board to chat,
   from a log to email, from a worker's output to a decision).
2. For each flagged moment, ask:
   - What do we gain and lose if this info were delivered
     directly, under the agent's own identity?
   - If the loss is "the approval step disappears": DON'T.
   - If the loss is only "a bit slower": mark it as a candidate.
3. Pick just ONE candidate and give the agent permission to
   "notify but not act" (messages/alerts are free, actions
   still require approval).
4. Leave every other meat-proxy point exactly as it is —
   don't try to fix them all at once.

Ando’s $20 million bet shows that treating agents as teammates is a real market question; on our side the question is the same, but our answer is different — not speed, control. If you want to see how we built AgentSpace’s lead-worker architecture and its permission layer, check out the agentspace page.