Deploying Rapidflare

Deploying the Rapidflare AI Agent over email

Give your agent an email address and it answers questions the way a colleague would: someone writes in, the agent replies in the same thread with an answer and the sources it used. This guide covers both ways to set that up. It is an admin flow.

Prerequisites

  • Admin access to the Rapidflare Admin Dashboard
  • A hub with knowledge sources already ingested, so the agent has something to answer from
  • For the mailbox option only: someone who can sign in to the mailbox with Google

Two ways to connect

You pick one when you enable email. They differ in which address people write to, and in who sends the reply.

Rapidflare addressYour own mailbox
The addressyou@agents.rapidflare.aiAn address you already own, e.g. support@acme.com
Setup on your sideNoneSign in to the mailbox once with Google
Who sends repliesRapidflareYour own mail provider, from your address
DNS changesNoneNone
Ready inImmediatelyA few minutes

One address per hub

A hub answers on one address at a time, and one hub per organization has email enabled. If you try to enable email on a second hub, the dashboard tells you which hub currently holds the address so you can disable it there first.

Fastest to set up, and nothing to arrange with your IT team.

Step 1: Open the deployments page

  1. Go to the Rapidflare Admin Dashboard
  2. Select the hub the agent should answer from
  3. Open Deployments
  4. Find the Email row and click Enable

Step 2: Choose the Rapidflare address

Click Use a Rapidflare address.

Step 3: Pick the name

Enter the part before the @. If you enter support, the agent answers on support@agents.rapidflare.ai. The domain is fixed; only the name is yours to choose.

Letters, digits, dots, dashes and underscores are allowed, and it must start with a letter or digit.

Step 4: Say who may write

See Choosing who may write below, then click Enable.

The agent is live as soon as you save. Send it a question to check.

Option B: Connect your own mailbox

Use this when replies need to come from an address your customers already recognise. The agent reads and replies through your own mail provider, so messages leave from your real address and your domain's email reputation carries them.

The mailbox needs a sign-in

You connect by signing in to the mailbox with Google, so it has to be a mailbox someone can sign in to.

A group alias that forwards to several people, or a shared mailbox reachable only by delegation, cannot be connected this way — there is no account to sign in as. Mailboxes on providers other than Google are not supported yet either. In any of those cases, use Option A.

Step 1: Open the deployments page

Same as Option A: DeploymentsEmail row → Enable.

Step 2: Choose your own mailbox

Click Connect my own mailbox. A Google sign-in window opens.

Step 3: Sign in to the mailbox

Sign in as the mailbox the agent should answer on, and approve the access Rapidflare asks for.

This does not have to be you. If a colleague holds the mailbox, they can sign in on your screen — they do not need a Rapidflare account, and signing in here gives them no access to your dashboard.

If your organization blocks third-party apps

Google Workspace administrators can block apps for the whole organization. If sign-in is refused, ask your Workspace admin to allow Rapidflare, then try again.

Step 4: Say who may write

Once the mailbox is connected, Rapidflare fills in the address from the mailbox itself — there is nothing to type. Set the sender lists as described below, then click Enable.

Choosing who may write

Both options end at the same screen: Who can write. This decides which senders the agent answers, and it is worth a moment's thought, because an email address is public the moment anyone learns it.

By default the agent answers nobody outside Rapidflare. A brand new address is closed until you name someone. That is deliberate: an address should not answer the whole internet in the gap between enabling it and configuring it.

You have two lists, and a sender passing either one is answered:

Allowed sender domains — everyone at a company. Enter domains without the @, separated by commas or new lines:

acme.com
partner.example

Allowed sender emails — specific people, without opening their whole company:

jane@acme.com
procurement@partner.example

Opening the address to anyone

To let anybody write in, put a single * in Allowed sender domains:

*

Use this when the address is meant to be public — a support address on your website, for instance. Do not use it for an internal-only agent, since anyone who learns the address can then reach it.

Changing the lists later

Open Deployments, click the Email row (or its gear icon), edit, and save. Changes take effect on the next message.

The lists replace rather than merge, so what you see in the form is exactly what will apply after you save. Clearing both puts the address back to answering Rapidflare staff only.

What the agent sends back

A reply arrives in the same thread, so the conversation reads normally in any mail client. It contains:

  • The answer, formatted for email
  • Links to the sources the answer drew on
  • A link to open the full conversation in the dashboard
  • Thumbs up / thumbs down links for feedback

Replies in a thread keep their context, so a follow-up question does not need to repeat what was already asked.

Every conversation appears in the hub's History, the same as questions asked through the web widget, Slack or Discord.

Turning it off

Two different things, both from the Email row on Deployments:

  • Disable releases the address. The hub stops answering and the address becomes available again, including to another hub.
  • Editing and clearing both sender lists keeps the address but narrows it back to Rapidflare staff only.

If you connected your own mailbox, disabling stops Rapidflare reading it. You can also revoke Rapidflare's access from your Google account at any time, which has the same effect from your side.

Troubleshooting

The agent did not reply. Check the sender's address against the two lists — a sender in neither is not answered, and by design nothing is sent back to say so. Also confirm email is enabled on the hub you expect, since only one hub per organization holds the address.

"Email is already connected to another hub." Another hub in your organization already has an address. Open that hub's Deployments, disable email there, then enable it here.

Sign-in fails when connecting a mailbox. Usually one of two things: your Workspace administrator blocks third-party apps, or the address is a group alias or delegated mailbox with no account to sign in as. The second cannot be worked around — use Option A instead.

Replies stopped arriving on a connected mailbox. Rapidflare's access may have been revoked or expired. Reconnect from the Email row on Deployments.

Previous
Discourse