Vercel Logo

Add Slack

The shop's mechanics live in Slack all day. Making them open a browser tab to ask the dispatcher anything seems rude. So let's meet them where they already are.

Here's the test of whether eve's "an agent is a directory" is real: adding Slack should not touch a single tool, the skill, the state, or the approval logic. A channel's whole job is narrow, normalize the incoming message, own the conversation's resume handle, and decide how replies go back. Everything the dispatcher does is already built. We're adding one file in channels/ and letting Slack become another client of the same agent.

The one genuinely new thing is credentials, and eve hands those to Vercel Connect so you never touch a SLACK_BOT_TOKEN.

Outcome

The dispatcher answers @mentions in Slack, in threads, with no changes to any tool, skill, or state.

Hands-on exercise

Set up Connect. Slack delivers events to a public URL and needs a verified bot token to reply. Vercel Connect brokers both, so there's no signing secret or bot token in your code. Connect authenticates your deployment by its Vercel project's OIDC token, so first link the project and pull a development token:

vercel link
vercel env pull

Now create a Slack connector and attach it to the project, with its webhook trigger pointed at eve's Slack route:

vercel connect create slack --name spoke-and-mirror --triggers
vercel connect attach slack/spoke-and-mirror --triggers --trigger-path /eve/v1/slack

Note --triggers appears on both commands, and both matter:

  • create … --triggers registers the connector and turns on webhook forwarding for it. Your browser opens to set it up and authorize the Slack app for your workspace. Without --triggers here, no events ever flow, even if you register a destination, and attach will warn you about exactly that.
  • attach … --triggers registers this project as the destination Connect forwards verified events to. --trigger-path /eve/v1/slack is required because the default is /slack and eve serves its Slack route at /eve/v1/slack.
Triggers are enabled in two places

Enabling triggers on the connector (create --triggers) and registering a destination (attach --triggers) are separate steps, and you need both. If you create the connector through the browser instead, make sure the Triggers toggle is Enabled on the configure screen, it defaults to off. A silent bot with a registered destination almost always means the connector itself has triggers disabled.

Re-running `create` installs a new Slack app each time

Every vercel connect create slack installs a fresh Slack app into your workspace, and vercel connect remove deletes the connector on Vercel's side but does not uninstall that app from Slack. So if you recreate the connector a few times while debugging, you'll end up with several identical bots in the @-mention list. Before re-creating, uninstall the stale ones in Slack under Manage apps (https://app.slack.com/manage), so you're only ever mentioning the live one.

Connect is a beta on all plans

vercel connect ships with the Vercel CLI, no feature flag needed. If your CLI reports connect as an unknown subcommand, update it (npm i -g vercel@latest) and retry; the command surface is documented under vercel connect.

Write the channel. Install the Connect helper and create agent/channels/slack.ts:

npm install @vercel/connect

The channel needs three decisions: where its credentials come from, when to dispatch a turn, and how to deliver the reply.

  • Credentials: connectSlackCredentials(process.env.SLACK_CONNECTOR ?? "slack/spoke-and-mirror") returns the bot token and webhook verifier, both managed by Connect. Reading the uid from SLACK_CONNECTOR keeps it out of code; the fallback matches the connector you just named, so it works without setting the variable.
  • Dispatch: onAppMention decides whether a mention becomes a turn. Use defaultSlackAuth to stamp workspace-scoped auth (the same auth the per-tier playbook reads), and ignore bot chatter.
  • Delivery: on message.completed, post the final reply to the thread, skipping interim tool-call narration.
The continuation token is the thread

You don't manage Slack threading by hand. The Slack channel maps a thread to a durable session, so a follow-up mention in the same thread resumes the same conversation, the channel owns that resume handle, exactly the role the continuationToken played in 1.3.

Because Slack delivers over the public internet, you can't exercise this one on localhost. You'll deploy to get a URL. We cover deployment properly in Section 5; for now, ship it with npx eve deploy, which wraps vercel deploy --prod, installs dependencies, and pulls your environment:

npx eve deploy

Try It

In a Slack workspace where the app is installed, mention the bot in a channel:

@dispatcher my commuter's front brake is rubbing, what's that cost to fix?

It replies in a thread, runs lookup_service, and quotes the real price, the same dispatcher you've been talking to all along, now in Slack. Reply in the thread and it continues the same session. And the approval gate still holds: ask it to book the Full Overhaul and the approve/deny prompt renders as Slack buttons, which a mechanic can tap from their phone.

Bot shows up in Slack but never replies? The usual culprit is triggers. First confirm forwarding is enabled on the connector itself: vercel connect attach warns Triggers are not enabled on this connector if you created it without --triggers, and the fix is to recreate it (vercel connect remove slack/spoke-and-mirror --disconnect-all --yes, then create … --triggers and re-attach). Then confirm the destination: --triggers on attach, and --trigger-path exactly /eve/v1/slack. If it responds but can't read earlier thread messages, that's expected, the channel hands the model the triggering mention, not the whole backlog, unless you opt into thread context.

Done-When

  • A Connect Slack client is attached with trigger path /eve/v1/slack.
  • agent/channels/slack.ts exports slackChannel with connectSlackCredentials.
  • @mentioning the bot returns a real, tool-backed answer in a thread.
  • An expensive booking renders approve/deny as Slack buttons.

Solution

agent/channels/slack.ts
import { connectSlackCredentials } from "@vercel/connect/eve";
import { defaultSlackAuth, slackChannel } from "eve/channels/slack";
 
export default slackChannel({
  // The connector uid lives in SLACK_CONNECTOR (set it on the project, or leave
  // it unset). The fallback matches the connector you named with `vercel connect
  // create slack --name spoke-and-mirror`, so this works out of the box.
  credentials: connectSlackCredentials(
    process.env.SLACK_CONNECTOR ?? "slack/spoke-and-mirror",
  ),
 
  // Answer @mentions from a real user; ignore bot chatter. defaultSlackAuth
  // stamps workspace-scoped auth, which is what the per-tier playbook reads.
  onAppMention: (ctx, message) =>
    message.author ? { auth: defaultSlackAuth(message, ctx) } : null,
 
  events: {
    // Post the final reply to the thread, skipping interim tool-call narration.
    // Event handlers receive (eventData, channel, ctx); Slack handles live on `channel`.
    "message.completed"(eventData, channel, ctx) {
      if (eventData.finishReason === "tool-calls") return;
      if (eventData.message) channel.thread.post(eventData.message);
    },
  },
});

We now have two entrypoints to the same agent, web and Slack, and the agent didn't change for either. The final step before we ship is to add auth, to make sure the people getting in the door are authorized.

Was this helpful?

supported.