Ando vs Slack: agents as teammates, not bots

By Lazar Milicevic · Published September 25, 2026 · 10 min read

You already have a Slack workspace stuffed with 40 unread threads, three integrations that mostly notify, and a handful of "AI bots" that all sound like the same helpful intern. Now you're being told to add agents to the mix. The honest question isn't whether agents belong in team chat — it's how they participate without turning your workspace into a firehose. Ando is one of the first serious attempts to answer that.

What Ando actually is

Ando is a team messaging app, built by the team behind Asana's early product work, that treats AI agents as first-class members of a workspace. Instead of bolting bots onto Slack channels, agents get their own identity, avatar, direct message inbox, and can be tagged, replied to, and included in threads exactly like a human teammate.

The pitch is narrow and specific: if agents are going to do real work — draft PRs, summarize customer calls, follow up on invoices — they need to exist inside the same conversation surface where humans coordinate. Not as /slash commands. Not as webhook-driven notifications. As participants.

Concretely, Ando gives each agent:

• A persistent identity (name, avatar, profile, "role")
• A DM inbox where humans can talk to it privately
• Channel membership, with the ability to read context and reply in threads
• A memory of past conversations it participated in
• Tools it can use to actually do work (send email, update a doc, hit an API)

That's a meaningful shift from the Slack model, where bots are second-class citizens tied to apps rather than being addressable entities with their own inbox.

Why the "bot" model in Slack broke down

Slack's bot framework was designed in 2015 for a different problem: pushing notifications and running slash commands. It works fine when the bot is a dumb pipe. It falls apart the moment the bot needs to hold context, act on behalf of a user, or collaborate across multiple channels.

A few specific failure modes anyone who's shipped a Slack integration will recognize:

1. No native inbox. You can DM a bot, but there's no unified "conversations with this agent" view. Every DM is its own island.
2. Context is per-channel and shallow. A bot in #support doesn't naturally know what was said in #eng. You have to build that plumbing yourself.
3. Identity is fixed to the app. You install "Zapier" or "Notion" — not "Priya, the AR follow-up agent who only handles invoices > $5k."
4. Threading is awkward. Bots posting into threads often break conversation flow because the mention model was designed for humans.

Slack has added Agentforce, Slack AI, and canvas features, but the underlying primitives — bots as apps, not identities — haven't changed. Ando is starting from the other direction: chat is the substrate, agents are peers, humans are peers, and the platform's job is to route context between them.

The core primitives Ando gets right

The design decisions that matter, from an engineering standpoint:

Agents as addressable identities. Every agent has a stable ID. You can @mention it, DM it, add it to a channel, remove it. It has an avatar and a bio. This sounds cosmetic. It isn't. It's the difference between "the Zendesk bot" and "Maya, who owns tier-1 triage from 9pm to 6am."

Per-agent inboxes. Each agent has a private DM view where the human owner can steer it: correct a bad response, feed it new context, approve or reject a proposed action. This is the closest thing I've seen to a proper human-in-the-loop UI baked into chat.

Shared context across channels. An agent added to #sales and #billing can naturally reference a customer conversation from one when responding in the other. In Slack, you'd stitch this with a vector store and a lot of glue code.

Tools bound to agents, not workspaces. In Slack, "Zapier" has all its actions available anywhere. In Ando's model, an individual agent has its own toolset — Maya can send emails and query the CRM but cannot deploy code. This is real least-privilege design.

A concrete example: an AR follow-up agent

Let's ground this. Say you run a 6-person consultancy and 20% of invoices go past due. You want an agent to handle the polite chase.

In Slack, here's what you'd build:

# Slack-style: bot as pipe
- Cron job hits QuickBooks every 6h
- Bot posts overdue invoices to #finance
- Human copies invoice, clicks button, bot sends email
- Reply lands in a support inbox, not Slack
- Bot has no memory of what it sent last week

In Ando's model, the same workflow becomes:

# Ando-style: agent as teammate
identity:
  name: "Jordan (AR)"
  role: "Accounts receivable follow-up"
  owner: "founder@company.com"

tools:
  - quickbooks.list_overdue_invoices
  - gmail.send_as(finance@company.com)
  - gmail.read_thread(finance@company.com)

channels:
  - "#finance"    # posts weekly summary
  - "DM: founder" # asks for approval on tricky cases

policy:
  auto_send_threshold_usd: 2500
  require_approval_above_usd: 2500
  tone: "polite, direct, one paragraph"
  cadence: "day 7, day 14, day 30 past due"

Jordan shows up in your workspace with a face and a name. You can DM Jordan: "Skip Acme this month, they had a billing issue." Jordan remembers. When an invoice > $2,500 needs a nudge, Jordan pings you in DM with the draft. Below $2,500, Jordan just sends and posts a log line in #finance.

That's the model. It's not that Slack literally can't do this — it's that Slack makes you build every one of those primitives yourself, and the resulting bot never feels like a teammate. It feels like a form.

Where Ando is likely to struggle

Being honest about the risks: I'd bet against Ando displacing Slack, and I'd bet on Slack copying the good ideas. A few reasons:

Switching cost is brutal. No serious SMB rips out Slack because a competitor has better agent primitives. Chat lives at the center of your operational graph — call recordings, docs, tickets, CI notifications, HR. Ando starts at zero on integrations.

Slack will ship its own version. Salesforce owns Slack and has already announced deeper Agentforce embedding. If per-agent identities become the winning pattern, Slack will bolt them on within 12-18 months. Whether they'll do it well is a different question.

Agent-native workspaces can get noisy fast. When agents can freely post in channels, the signal-to-noise ratio collapses. Ando will need strong defaults — quiet-by-default agents, DM-first interactions, digest posting — or it becomes the exact firehose people are fleeing.

Identity != capability. Giving an agent a name doesn't make it competent. Under the hood, it's still an LLM with tools, and 80% of the work is in the tool definitions, retrieval, and eval loops. A pretty avatar hides bad prompt engineering only briefly.

Slack vs Ando: what's different where it matters

If you're a solopreneur starting fresh, Ando's model is genuinely more coherent. If you're on Slack with 200 integrations and a Business+ plan, wait and watch — but steal the design ideas now.

What to steal from Ando even if you never use it

Regardless of which chat surface wins, these patterns are correct and you should build them into your own agent stack today:

1. Give every agent a name and a role, not a function. "Invoice bot" is a function. "Jordan (AR)" is a teammate. This isn't fluff — naming forces you to scope the agent's responsibilities tightly and makes governance conversations trivial ("what does Jordan have access to?").

2. Make the DM the primary steering surface. Every agent should have a direct-message channel with its owner where corrections, overrides, and context can be dropped in plain language. This beats an admin panel by a mile.

3. Enforce least-privilege at the agent level. Not at the app level. Jordan gets QuickBooks read + Gmail send-as-finance. That's it. If you need a second AR use case, spin up a second agent with its own permissions, not a mega-agent that does everything.

4. Keep agents quiet by default. Agents post when they have something worth saying (a summary, an approval request, a genuine question). They stay silent otherwise. Assume every unnecessary post costs you attention.

5. Log everything the agent did in a channel humans can audit. Not "Jordan sent 3 emails today." Actual thread links, actual drafts, actual outcomes. If you can't audit it, you can't trust it.

Here's the minimal agent identity spec I use for BizFlowAI client work, expressed as a config you can adapt:

{
  "agent_id": "jordan_ar",
  "display_name": "Jordan (AR)",
  "role": "Accounts receivable follow-up",
  "owner_email": "founder@example.com",
  "surfaces": {
    "slack_dm": true,
    "slack_channels": ["#finance"],
    "email_inbox": "jordan@example.com"
  },
  "tools": [
    {"name": "quickbooks.read_invoices", "scope": "overdue_only"},
    {"name": "gmail.send_as", "identity": "finance@example.com"}
  ],
  "policies": {
    "approval_required_above_usd": 2500,
    "quiet_hours": "20:00-08:00 America/New_York",
    "escalate_to_human_on": ["dispute", "legal", "refund_request"]
  },
  "memory": {
    "type": "vector",
    "namespace": "ar_followups",
    "retention_days": 365
  }
}

Whether you deploy this on Ando, on Slack via a custom bot, or on your own dashboard, the shape is the same.

The MCP angle: why this pattern is now cheap to build

The other thing worth flagging: what Ando is building on-platform, the Model Context Protocol makes achievable on any chat surface. MCP gives you a standard way for an agent to hold tools, identity, and context across systems. Combine MCP with a well-scoped LLM (Claude, GPT, whatever fits) and a slim Slack or email connector, and you can ship the Ando pattern into a Slack workspace this quarter.

The build looks like:

# Rough stack for an agent-as-teammate deployment
- LLM: Claude Sonnet / Haiku with tool use
- Identity layer: MCP server per agent (isolated toolset)
- Chat connector: Slack bot user, one per agent
- Memory: Postgres + pgvector, namespaced per agent
- HITL: DM approval flow via Slack Block Kit
- Audit log: append-only table, one row per tool call

Two weeks of focused work gets you a Jordan in Slack. The reason most SMBs don't have one isn't cost — it's that nobody on the team has time to build it.

How BizFlowAI approaches this

This is the pattern we've been shipping for clients for the last year: Claude-based agents with MCP-scoped toolsets, each with their own Slack (or email) identity, each owned by a specific human, each with a DM inbox for corrections and approvals. Not because Ando told us to — because when you actually run this in production for a 5-person ops team, the "agent as teammate" model is the only one that survives contact with real work. The bot-as-app model produces integrations. The agent-as-identity model produces coworkers.

If you're looking at Ando and thinking "I want that, but on the tools I already run," that's the discovery call we take every week. We'll map two or three concrete workflows in your business — AR follow-up, lead qualification, support triage, whatever's actually bleeding hours — and tell you honestly which ones are worth building an agent for and which ones are a checklist and a Zap.

The takeaway

Ando's bet isn't that team chat needs another Slack. It's that agents deserve first-class seats in the room where work happens, and the current chat platforms weren't designed for that. Whether Ando wins or Slack absorbs the ideas, the pattern is durable: agents with names, inboxes, scoped tools, and human owners will beat anonymous workspace-wide bots on every metric that matters — trust, adoption, and actual work completed.

Build for that pattern now. The chat surface you deploy it on is a detail that will change three more times before this decade is out.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.