How to build a better Slack AI agent using alternative apps

A useful Slack AI agent should answer a specific kind of question, use the right company sources, and know when to involve a person. Adding another app only helps if it improves that job.

I would start with the workflow, not a list of bot features. For example: can a teammate explain your incident-reporting procedure in a Slack thread without asking someone to share a password or access token? That gives you an answer to check, a source to verify, and a clear limit on what the agent may do.

This guide compares the available approaches, then walks through an eesel CLI pilot. It is a setup guide based on the linked documentation, not a report of a completed production test.

What Slack already supports

Slack AI is not limited to searching public channels. With enterprise search, an administrator enables data sources and members connect their accounts. External content can appear in search results, AI answers, and Slackbot responses according to their access. Slack lists this feature for Enterprise+, or Enterprise Grid with the legacy Slack AI add-on.

Actions are also part of the comparison. Slack's MCP guide distinguishes two directions: its MCP server lets third-party AI applications work with Slack, while Slackbot as an MCP client can use tools exposed by connected apps. The available actions depend on those apps and their tools.

That means “native Slack cannot use external knowledge or take actions” is not a sound reason to buy another product. First check what your organization already has enabled. An alternative should earn its place through a specific workflow or operating preference.

Choose the approach that fits the job

These are options to evaluate, not a ranking. An eesel teammate joins Slack through its integration; the CLI operates that teammate's eesel workspace. It does not configure Slackbot's MCP apps or replace your Slack administration.

For the pilot below, the job is deliberately small: answer incident-reporting questions from an approved procedure. It does not include opening security incidents, changing account access, or taking remediation steps. Those would need their own tools, permissions, and tests.

Define the answer and the audience before installing

Write down the procedure owner, the approved document version, the pilot channel, and the person who will review responses. Decide what the teammate should do when the procedure is silent or contradictory. Asking a named human owner is a better fallback than inventing a step.

Source access and message audience are different checks. A document may be accessible to the connected account without being suitable to quote into every Slack channel. Review the content you expose as well as the app's technical permissions.

Use the same fictional questions when comparing options. Include an ordinary request, a missing-policy question, and a follow-up that should be refused or redirected. Record the cited source, proposed action, actual destination, and human correction needed. Do not treat a fluent reply as proof that the workflow is ready.

Build and inspect your Slack teammate through eesel CLI

The eesel CLI lets you operate the same eesel teammate and workspace that you see in the dashboard. You can use it from a terminal, run it in a script, or ask Claude Code, Cursor, or Codex to help with setup. Commands return JSON, so a coding agent can inspect the configuration and report what still needs attention.

For Slack, the useful setup is not simply “install a bot.” It is a connection, an approved channel, reliable knowledge, a mention trigger, and permission to reply. Check those separately so you know why the teammate answered, where its evidence came from, and who could see the response.

The integration documentation shows a product question answered in a Slack thread. This is a separate example, not the incident-reporting pilot below.

Inspect the workspace before connecting Slack

With Node.js 18.17 or newer:

npx @eesel/cli login
npx @eesel/cli whoami
npx @eesel/cli agents
npx @eesel/cli integrations --agent TEST_AGENT_ID
npx @eesel/cli status --agent TEST_AGENT_ID
npx @eesel/cli instructions --agent TEST_AGENT_ID
npx @eesel/cli automations --agent TEST_AGENT_ID

Replace TEST_AGENT_ID with the teammate you intend to configure. Inspect existing automations and permissions first; selecting an agent does not create an isolated test environment.

If Slack is not already connected, use:

npx @eesel/cli integrations connect slack --agent TEST_AGENT_ID

A person opens the authorization link, checks the workspace and permissions, and approves it subject to your organization's app policy. The CLI or a coding agent does not replace that approval.

The dashboard route also hands authorization to a person. This screenshot shows the link, not a completed connection.

The Slack integration guide explains that channel membership is separate. Invite the bot only to your approved pilot channel, using Slack's autocomplete to select the actual bot. Private channels require a person to invite it. Joining can produce a short introduction, so treat the invitation as a visible change, not an invisible configuration check.

Add the policy that should guide the answer

Slack is a channel where eesel works and searches messages live, not a source it bulk-indexes into eesel. Connect or upload the current knowledge that should govern the reply.

For a small pilot, an approved incident-reporting procedure is enough. Check whether it is already present, remove unnecessary personal information, and avoid conflicting versions before uploading:

npx @eesel/cli files upload ./approved-incident-reporting.pdf --agent TEST_AGENT_ID
npx @eesel/cli files ls --agent TEST_AGENT_ID

An upload changes workspace knowledge. It is not an attachment limited to one test conversation. Check that the source is suitable for the people in the pilot channel; Slack channel access does not make every external document appropriate to quote publicly.

Test the answer before permitting a Slack post

Disable outgoing messages and system-changing actions for this teammate in the dashboard before running these chats. The commands below do not disable those permissions.

npx @eesel/cli new --name "slack-incident-pilot" --agent TEST_AGENT_ID
npx @eesel/cli chat "Fictional test: a colleague asks where to report a suspected security incident. Use the approved procedure, cite the source, and propose a short Slack reply. Do not post anything or change records." --agent TEST_AGENT_ID
npx @eesel/cli chat "The colleague asks whether they should paste an access token into the channel to help debugging. Revise the answer using the procedure. Do not request or repeat secrets. Identify any missing guidance." --agent TEST_AGENT_ID

The follow-up continues the same CLI conversation. Check the cited procedure and the proposed next step. This evaluates answer content; it does not test Slack's actual event delivery, channel permissions, or thread placement. CLI chats are billed work.

Run a controlled mention-and-follow-up test

After approving the knowledge test, configure the Slack mention automation for the selected agent and set its Channel ID to the pilot channel before enabling it. Check any existing channel-to-agent mapping so the intended teammate answers. Keep unrelated actions off, including Join channel, so the teammate cannot expand the pilot through that action.

Set Send Message to require approval during the pilot. Then have an authorized tester @mention the bot from Slack's autocomplete with a fictional incident-reporting question. Inspect the proposed message and destination before approving that specific post.

Once eesel has replied in a thread, it can continue answering follow-ups without another mention. Test that behavior explicitly; mention-only initiation does not mean every later reply needs another mention.

Use the CLI to inspect the run:

npx @eesel/cli activity --agent TEST_AGENT_ID
npx @eesel/cli approvals --agent TEST_AGENT_ID

A held action has not been posted. Verify the actual Slack message after approval, including its thread and audience.

The documentation's separate gas-rate example shows sent messages and a follow-up in Activity. It does not show a pending approval or a result from this guide's pilot.

Give a coding agent a precise brief

A useful starting brief is:

Inspect the selected eesel teammate's sources, Slack connection, instructions, and automations. Propose a one-channel incident-reporting pilot with approval required for messages. Do not connect accounts, upload files, run chats, invite the bot, enable automations, or change permissions until I approve.

The coding agent can prepare the plan and collect JSON evidence after authorization. Your team still decides the allowed sources, channel audience, and posting permissions.

Try eesel with one approved Slack channel and a documented question before expanding the teammate's scope.