Skip to main content
A We-Bot is an AI agent that belongs to your company. An admin owns it, it works in Flow alongside your admins, and it acts through the Fluid API with a permission grant of its own. It never holds more than the admin who owns it. Every We-Bot is trained on the Fluid knowledge base from the start, so it understands Fluid’s features and API from its first conversation. We-Bots are being released company by company. Until they’re on for your company, every We-Bot endpoint answers 404.
We-Bots are different from Flow’s response bots, broadcast bots and incoming webhooks. See Bots in Flow for how they compare.

​
Who manages a bot

Manage bots with an admin’s own session token, sent as a Bearer token (Authorization: Bearer <token>). A bot belongs to a person, so company API tokens, partner tokens and droplet installation tokens are refused with 403.
  • The owner is the admin who created the bot. The owner sets the bot’s permission limit and names its stewards.
  • Stewards are other admins who may rename, pause, resume and delete the bot, and change its settings. Add a steward to share the work. A bot has at most 20.
  • Everyone else gets 404 for the bot, as if it didn’t exist.
Reading bots needs the we_bots.view permission. Creating one needs we_bots.create, changing, pausing and resuming need we_bots.update, and deleting needs we_bots.delete. If the owner leaves the company or is locked out, the bot can’t run until someone gives it a new owner.

​
What a bot may do

Two controls decide what a bot does, and both start narrow. The grant is the set of permissions a bot’s runs hold. Every run holds its owner’s current permissions, so a permission the owner loses is gone from the bot’s next run. The owner can narrow that further with Set or remove a bot’s permission limit, to keys such as orders.view. Some keys a bot can never hold, such as those that manage roles, admins, bots or droplets. A refused key is named in the response. Capabilities are what the bot may do within its grant. A new bot has only use_ai enabled, so it can talk and keep its own persona and memory. List a bot’s capabilities to see the rest, and switch them on with Change a bot’s settings. Every change to a bot’s settings or profile is a new numbered version that names who made it. A run uses the version that was current when it started.

​
Where a bot talks

A bot talks to people only in Flow. Its owner or a steward seats it in a conversation they’re already in: a direct, group, channel or downline conversation. Email and SMS conversations can’t hold a bot. Open your direct conversation with a bot to talk to it one-to-one. Mentioning a seated bot wakes it, and so does writing to it where it’s the only other participant. It works for the admin who wrote. A bot works for admins, not members:
  • In a conversation that anyone other than an admin reads, it answers at most once a day that it works only for admins.
  • Its reply is withheld while anyone other than an admin is in the conversation, or while an admin there lacks a permission the run used. The bot leaves a short notice instead.

​
What wakes a bot

Besides being messaged, a bot wakes through its triggers. A bot has at most 20. A run a trigger starts acts for the bot’s owner and posts only into the trigger’s conversation. That conversation must seat the bot and be read only by admins. A bot can also add, change and remove its own triggers while it runs.

​
How much a bot does on its own

Every request a bot makes belongs to an action class. List the kinds of action a bot can take shows each class and its modes. The owner chooses a mode per class, and Fluid enforces it whatever the bot tries:
  • Reads always run.
  • Off classes are refused.
  • Approval classes wait on a card in the conversation. The owner or a steward who holds every permission the request needs approves or declines it. An approval covers one exact request, is used once, and expires after 72 hours.
  • Automatic classes run until their daily cap.
Moving money is never automatic. A refused request answers 403 and names its reason in the Fluid-Bot-Refusal header: action_off, approval_required or cap_reached. To stop a bot, pause it. Pause every bot is your company’s stop button: it pauses every active bot at once, including bots you can’t see.

​
Message customers with a bot template

A bot template is a reviewed bot that Fluid publishes: a profile, instructions, a permission bundle, playbooks and message copy. List bot templates, then install one. The bot you get keeps running the template version it installed until an upgrade is accepted. The bot never sends. A running bot asks Fluid to message a customer. Fluid then:
  1. Decides who’s eligible, and holds some people out as a comparison group.
  2. Renders the message from the template’s reviewed copy and adds tracked links.
  3. Checks consent, opt-outs, frequency and quiet hours.
  4. Sends it from your company’s own email identity.
Each playbook starts off. Change a playbook to shadow, which records what the bot would send and sends nothing, then to live. You set its holdout share, quiet hours and the gap between messages to one customer within the template’s bounds. Fluid records what was sent, what happened to it, and the orders it can tie to each message. It doesn’t credit wins. Get a playbook’s cohorts and Get a bot’s send counts give you the facts to compute results yourself. A We-Bot can also send one Flow direct message with Send a Flow direct message and its bot_id. That send is a message_customer action, so the owner’s mode for messaging people decides whether it waits for approval.

​
Connect tools

A bot can use outside tools through connectors:
  • App connectors such as Gmail, Google Calendar, Outlook and GitHub are allowed until an admin turns one off.
  • Remote MCP servers are off until an admin turns them on. Connect a remote MCP server and every tool starts switched off. Switch on the ones bots may use.
List the connectors bots can use shows what your company allows.