Scope that is 'answer questions'
An agent pointed at everything is confidently wrong about most of it. Useful agents own a narrow, repeated, verifiable job — and defining that job is the work people skip because it is less interesting than the demo.
Agentforce · AI in Slack
An agent in Slack is easy to switch on. The work is deciding what it owns.
Slack is an unusually good surface for agents, because it is where the questions are already being asked. It is also unusually unforgiving: an agent that answers confidently and wrongly in a channel does it in front of everyone. The difference is scope, grounding and knowing which decisions a human keeps. Narrow jobs, real grounding, and a baseline you measured first.
12+
500+
250+
15+
Trusted by 500+ organizations — including teams putting agents where the questions are already being asked.
What We Work With
- Salesforce Partner
- Agentforce
- Slackbot
- Salesforce Channels
- Grounding & Content
- Permissions & Guardrails
- Deflection Measurement
- Agentforce Sales
What goes wrong between the demo and the channel
Agent projects rarely fail technically. They fail because nobody decided what the agent was accountable for, or how anyone would know it was working.
Grounded on whatever was lying around
Pointed at a wiki nobody has updated since 2023 and a folder of decks. The answers reflect the source faithfully, which is the problem. Content ownership has to be settled before grounding, not after the first wrong answer.
No guardrail on consequential actions
An assistant that drafts is a different risk from one that sends, updates a record or commits to a customer. Where that line sits is a decision, and leaving it undecided means it gets set by whatever the default was.
No baseline, so no verdict
Nobody counted how many of these questions were asked, or what answering them cost, before switching the agent on. Afterwards the only available assessment is whether people feel it is helping.
No owner for wrong answers
The agent says something incorrect in a channel. There is no route to report it, nobody owns the correction, and trust drops faster than it built — usually permanently.
Built around a product name that changed
This surface has been renamed and restructured more than once within a year. Anything designed around a specific feature rather than the job it does needs revisiting every release.
What an agent in Slack actually needs to work
An agent in Slack is a narrow, named job — answering a class of repeated question, triaging an inbound request, summarising a thread, or pulling a record into the conversation — grounded on content someone owns, with an explicit boundary around what it may do unattended, and a measured baseline to judge it against. Everything that makes it work is decided before it is switched on.
What the platforms provide. Salesforce made a reimagined Slackbot generally available in January 2026 and added a large set of AI features in March 2026. Slackbot acts as an MCP client and can route a request to an Agentforce agent or another app, which makes it an orchestration layer as much as an assistant; Agentforce agents themselves run across multiple surfaces, Slack among them. Slack documents setting this up here. This surface moves quickly — the legacy Channel Expert was deprecated during 2026 — so we confirm current capability against your org and the current release rather than from a deck.
What Twopir does. We pick the jobs worth giving an agent, settle content ownership before grounding it, set the line between drafting and doing, instrument it so you can tell whether it worked, and give wrong answers a route back to a named human.
What the client gets. A small number of agents doing verifiable jobs, with evidence. We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges.
Five candidates — ordered by how much can go wrong
Start at the top of this table. The first two are where agents earn trust; the last is where they lose it if the first two have not been proven yet.
| Job | Why it suits an agent | Grounded on | Human stays in the loop for |
|---|---|---|---|
| Answering repeated internal questions | High volume, narrow domain, and the right answer is checkable. | Approved internal content with a named owner per document. | Anything the source does not cover — it should say so rather than improvise. |
| Triage and routing | A classification task with a finite set of outcomes and a clear escalation path. | Your routing rules and the record, not general knowledge. | The judgement call when confidence is low, rather than a guess. |
| Summarising a thread or a record | Bounded input, and the reader can see the source to check it. | The thread or record itself, nothing beyond it. | Anything that becomes a customer-facing commitment. |
| Drafting a reply or an update | Draft-and-review is the safest shape for an agent doing customer-adjacent work. | The record, the history and your tone guidance. | Sending. Always — drafting and sending are different risk classes. |
| Updating a CRM record | Possible, and the highest-consequence item on this list. | The record, under the acting user's own permissions. | Field-level limits and an audit trail; not every field should be agent-writable. |
Capability verified September 2026; this surface changes fast and is re-checked per engagement
Pick the job from the evidence
We read the channels where the questions are actually asked and count them. The job worth automating is the one being asked forty times a week, not the one that demos well — and that count doubles as the baseline you will measure against.
Ground it on content someone owns
Every source document gets a named owner before it is indexed. An agent grounded on unowned content produces confidently stale answers, and the fix is editorial rather than technical.
Draw the line at doing, not drafting
Drafting is low risk and immediately useful; sending, updating and committing are not. Where an agent does act, it acts under the requesting user's own Salesforce permissions so sharing rules and field-level security still apply and the audit trail names a person.
Measure deflection, not satisfaction
How many of the counted questions were resolved without a human, how many escalated well, and how many were answered wrongly. Without the baseline taken first, none of those numbers mean anything.
The work inside an agent engagement
Six workstreams. The first two decide whether the rest should happen, and we have ended engagements at that point.
Job selection and baseline
Reading the channels, counting the repeated questions, and picking jobs that are narrow, frequent and verifiable. The count is the baseline, so this phase pays for itself even if nothing is built.
Content and grounding readiness
Which sources are current, which have an owner, and which must be fixed or excluded before grounding. Usually the least glamorous and most decisive part of the engagement.
Guardrails and permissions
The line between drafting and doing, what the agent may never do unattended, and action running under the requesting user's own Salesforce access rather than a service account.
Agent build and orchestration
Configuring the agent for the chosen jobs and connecting it to the Salesforce data and actions it needs, with routing to the right agent or app where several exist.
Measurement and feedback loop
Deflection, escalation quality and wrong-answer rate against the baseline, plus a route for people to report a bad answer to a named owner who fixes the source.
Rollout and trust management
A pilot channel before a workspace, clear labelling of what is an agent, and honest communication about what it does not do — because trust lost early is not recovered.
From interesting to accountable
Four phases. The first two are deliberately unglamorous and are the reason the fourth produces a number rather than an impression.
Count what is actually being asked
Read the channels, classify the questions, count them. This produces both the shortlist of jobs worth giving an agent and the baseline you will judge it against — and occasionally it shows the volume does not justify the project, which is a useful outcome.
Fix the grounding before building
Identify the source content, assign owners, retire what is stale, and exclude what cannot be trusted. An agent cannot be better than what it reads, and no amount of configuration compensates for an unowned wiki.
Build narrow, with the guardrails first
The chosen jobs only, with the draft-versus-do line set explicitly, actions running under the user's own permissions, and a clear statement of what the agent will refuse.
Pilot, measure, then widen or stop
One channel, measured against the baseline for deflection, escalation quality and wrong answers. Widen if the numbers support it; stop if they do not, which is a legitimate result and cheaper than a workspace-wide rollout nobody trusts.
The foundation agents actually need
Agent work depends on the integration underneath being correct. These are delivered Salesforce and Slack engagements; the figures are the ones published on each case study.
★★★★★
The goal was never to replace Salesforce — it’s still the system of record. We just made sure the team never had to leave Slack to know what was happening in their pipeline.
Twopir Project Lead SaaS technology client · 2025 Slack Sales Elevate
Slack Sales Elevate · Salesforce Integration
The prerequisite for any agent acting on CRM data in Slack: users mapped correctly, permission sets scoped per role, and Salesforce still the system of record.
5 User groups scoped to their own access
5 Systems connected into one workflow
6 Rollout problems found and fixed
Slack Workspace · 75+ Field Crews
A workspace where SOPs and site knowledge were deliberately made findable rather than left in personal text threads — the editorial groundwork any grounded agent depends on.
75+ Field and office staff onboarded
4 Operational gaps closed
Mapping is an AI prerequisite
An agent acting on CRM data inherits whatever identity model is underneath it. Incorrect user mapping was one of six problems found on a live rollout — and an agent acting through a broken mapping is a permissions problem, not just a missed notification.
2 Of six problems were access problems
We scope agents narrowly, and measure them
The difference between an agent that earns trust and one that burns it is almost entirely in how narrowly it was scoped and whether anyone took a baseline first.
We count before we build
The shortlist of jobs and the baseline come from reading the channels and counting the questions. It occasionally shows the volume does not justify the project, and we say so.
We fix grounding before configuration
An agent cannot be better than what it reads. Assigning owners to source content and retiring what is stale is editorial work, it is unglamorous, and it decides the outcome.
We draw the draft-versus-do line explicitly
Drafting is low risk and immediately useful. Sending, updating and committing are not. Left undecided, that line gets set by whatever the default was.
We keep actions in the user's context
Where an agent acts on Salesforce data it does so under the requesting user's own permissions, so sharing rules and field-level security still apply and the audit trail names a person.
We name the job, not the product
This surface has been renamed and restructured within a year, and the legacy Channel Expert was deprecated. Designing around the job rather than the feature is what stops your build needing revisiting every release.
Answers before the first call
As of September 2026, Salesforce has made a reimagined Slackbot generally available and added a large set of AI features during the year. Slackbot acts as an MCP client and can route a request to an Agentforce agent or another app, so it works as an orchestration layer as well as an assistant, and Agentforce agents run across multiple surfaces including Slack. This area changes quickly — the legacy Channel Expert was deprecated during 2026 — so we confirm current capability against your org and release at the start of an engagement rather than working from a deck.
With the questions your teams already ask each other repeatedly in channels. Count them for a couple of weeks. The most-asked, narrowest, most checkable category is your first agent job, and the count is the baseline you will use to judge whether it worked. Starting from 'what can the technology do' instead produces a demo rather than a deployment.
That is a design question, not an accident. There should be a visible route to report a bad answer, a named owner who fixes the underlying source rather than patching the agent, and clear labelling so people know they are reading an agent. Wrong answers are survivable; wrong answers with no correction path are how trust is lost permanently.
Possibly, and it is the highest-consequence thing on the list, so it comes last rather than first. Where an agent does act, it should act under the requesting user's own Salesforce permissions so sharing rules and field-level security still apply and the audit trail names a person — and not every field should be agent-writable. We would want the read-only and drafting jobs proven before moving here.
By measuring deflection, escalation quality and wrong-answer rate against the baseline you took before switching it on. Without that baseline the only assessment available is whether people feel it helps, which is not something you can take to a renewal conversation. Taking the baseline is phase one for exactly this reason.
For anything acting on CRM data, yes. An agent inherits whatever identity and permission model sits underneath it, so incorrect user mapping becomes a permissions problem rather than just a missed notification. Mapping, permission sets and record access should be correct before an agent is given anything consequential to do.
Fundamentally, yes. Deterministic automation — a Flow, a Workflow Builder workflow — does the same thing every time and is tested by asserting that. An agent is non-deterministic, which means different guardrails, different testing, and a success measure expressed as a rate rather than a pass or fail. Where a job can be done deterministically, it usually should be, and we will say so.
Next Step
Tell us what your teams keep asking, we will tell you if an agent should answer it
A readiness call covers the questions being repeated in your channels, whether the content behind them is owned and current, and whether your Salesforce access model is ready for an agent to act on it. You leave with a shortlist and an honest view on timing.
Narrow jobs, owned content, and a baseline taken first
