October 7, 2026

Receipt vs Slackbot: An Assistant Inside Slack, or an Execution Layer Behind It

Slackbot works inside each person's Slack permissions and inherits Slack's admin stack. Receipt runs agent work behind Slack, on organization-governed connections, with one hash-chained record shared by web, Slack, Teams, the CLI and MCP clients.

A week after an incident, someone usually asks who changed what. If an AI agent made the change, the answer depends on where that agent lives. Slack rebuilt Slackbot as an agent inside Slack. It reads what each person can see and, through MCP, acts in other apps as that person. Receipt sits behind the chat as a separate execution layer, and Slack is one of several ways in. This Receipt vs Slackbot comparison is about that placement: where identity, execution and the record of agent work end up. For enterprise AI agents that touch GitHub, Jira or a CRM, placement decides who holds the access and who can account for the result. What follows covers both products, the architecture, an incident walk-through and a decision guide.

What Is Slackbot?

Slackbot is the agent built into Slack, rebuilt on large language models. It has been generally available since January 2026 for Business+ and Enterprise+ customers; Free and Pro get a limited sample. It opens in its own panel on desktop and mobile, and since September 2026 it also runs in Salesforce Lightning. It suits organizations that already run on Slack, Salesforce customers above all.

The Slackbot AI agent starts from what the person asking can already see: channels, threads, files, canvases and lists. Permissions are checked at request time, so answers never include content that person could not open. It searches, summarizes, drafts, builds canvases and slides, runs Python in a sandbox, and carries out scheduled tasks and reusable skills.

It also acts in other systems. It can take Salesforce actions, which members always review and approve first. Slack has since added an MCP client for Slackbot. Developers package remote MCP servers in Slack apps, and Slackbot calls their read and write tools, such as one that creates a Jira ticket.

Business+ members get 15 Slackbot messages a week; Enterprise+ has no weekly cap. Tagging Slackbot into channels was in early pilot as of September 2026.

What Is Receipt?

Receipt is Kentron's hosted agent product at app.kentron.ai. Its customers are organizations, which contain workspaces, and each workspace owns its connections to apps such as GitHub and Jira. People reach Receipt from a web app, Slack, Microsoft Teams, the receipt command-line tool, and MCP clients such as Claude Code, Codex and Cursor.

In Slack, someone @mentions Receipt in a channel thread. A routing model either replies directly, without tools, or starts a durable background run. Dedicated workers execute the run in a per-run sandbox container, and Receipt posts progress and the result back to the thread.

For most connectors, agents call apps through Receipt's gateway. It checks the connection's allowlist, writes a receipt, and only then calls the provider with a credential attached on the server. Receipts are SHA-256 hash-chained.

In Slack, each person links their own Receipt account, and their requests run under that account's workspace permissions. Slack routing requires the organization's own OpenAI key.

The Architectural Difference

Once an agent can act, three placements matter: whose authority it uses, where the work runs, and where the record lands. Slackbot keeps all three inside Slack. Receipt keeps them behind it.

In Slackbot, authority belongs to the person. Slack's June 2026 post on MCP security says "every MCP call is made as the authenticated Slack user." For third-party servers, Slack brokers OAuth and issues per-user tokens that admins can revoke centrally. The work runs in the conversation, where the person can watch each step and stop it. The record lands in Slack's audit log, beside everything else Slack tracks. The design is coherent: Slack becomes the system of record for agent work, and the controls Slack admins already run cover it.

In Receipt, authority comes from workspace connections that the organization governs operation by operation. Each gateway receipt names the person who asked, while the downstream app sees the account that connected it. The work is a queued job that dedicated workers execute outside any chat session. The record is written at the gateway before each call leaves, and the call is refused if that write fails. Run state is derived from those receipts rather than stored beside them.

The difference shows once work starts outside Slack. In one Receipt workspace, a Slack run, a Teams request and a coding agent calling Jira over MCP pass the same allowlists. Their calls land in the same stream. That is the AI agent governance choice: anchor control and evidence to the chat platform, or to the connection layer underneath it.

Receipt vs Slackbot

Here is how the two designs compare.

Dimension	Receipt	Slackbot
Where it runs	Hosted service behind web, Slack, Teams, CLI and MCP clients	Inside Slack on desktop and mobile, and in Salesforce Lightning
Acts as	The requester's linked Receipt account, over workspace connections	The invoking Slack user, with that user's permissions
App credentials	Held in Receipt's integration server; attached server-side on gateway calls	Per-user OAuth tokens in Slack's credential infrastructure, revocable by admins
Context it reads	The thread it is mentioned in, plus connected apps	All Slack content the user can access, plus Salesforce and MCP apps
Tool access	Per-connection allowlists; writes off until an owner or admin enables them	Admin app approval; per-server and per-tool rules on Enterprise Grid and Enterprise+
Approvals	Optional; one decision before a whole background run starts	Per app or per tool: always allow, needs approval, or blocked
Execution	Durable background run in a per-run sandbox	Multi-step work in the conversation, scheduled tasks, Python sandbox
How actions are recorded	Intent receipt before each gateway call, outcome after; SHA-256 hash-chained	Audit log entries marked `acting_agent: Slackbot`, on Enterprise plans
Enterprise administration	Fixed roles; no SSO, SCIM or retention controls	SSO, SCIM, DLP, EKM, data residency, retention, legal holds

A Real-World Example

Ana is on call for an incident with its own Slack channel. She asks the agent to check recent GitHub deploys, find the related Jira issue, open a follow-up ticket and post a summary. A week later, the security lead asks who created the ticket, what was sent to Jira, and on whose request.

With Slackbot. Ana opens Slackbot beside the channel, since channel tagging is still in early pilot. It acts as Ana, reaching GitHub and Jira through admin-approved MCP apps with Slack-brokered tokens from her own OAuth connections. If she set Jira's write tools to need approval, Slackbot asks before creating the ticket. It works in her conversation and drafts the summary for her to share. For the review, the same Slack post says: "Every AI action generates an audit log capturing the acting user, the action taken, and the relevant context." On an Enterprise plan, the lead filters the audit log for Ana's entries marked acting_agent: Slackbot, and Jira's history shows Ana as the creator. How much of the request each entry keeps is not described in Slack's documentation.

With Receipt. Ana @mentions Receipt in the incident thread. It acts for her linked account over the workspace's GitHub and Jira connections, whose credentials stay server-side for gateway calls. Reading deploys is allowed by default; creating a Jira issue works only because an owner or admin enabled that write. With run approval on, Approve and Deny buttons appear in the thread; Ana or a workspace owner decides once, for the whole run. A worker runs it in a sandbox, and progress and the summary come back to the thread. The gateway writes an intent receipt with the full input before the Jira call, and an outcome receipt after it. A week later, the lead opens the run's replay from the thread link: each call in order, with requester and approval. The workspace's gateway activity shows the same call. Jira shows the connection's account, so the receipt is what names Ana.

Where Slackbot Wins

Slackbot is already where people work. Business+ and Enterprise+ customers have nothing to deploy and no model key to supply. In its own panel, it answers across every channel, file and canvas a person can open, within their permissions. Receipt's Slack app is narrower: it answers @mentions in channels and threads, with no DMs, slash commands or App Home. It reads only the thread it is mentioned in, and its Slack routing needs the organization's own OpenAI key.

Slackbot also inherits Slack's enterprise administration: SSO, SCIM, DLP, enterprise key management, data residency, retention and legal holds, many on Enterprise plans. On Enterprise Grid and Enterprise+, every MCP app needs admin approval, and admins can set access per server and per tool. Individual users can require approval for a single tool, a finer gate than Receipt's run-level one. Salesforce customers can use it inside Lightning too. Slack hosts the models in its own cloud and says customer data is never used to train them.

Where Receipt Wins

Receipt wins when work has to outlive the conversation. A background run is a durable job in its own sandbox container. It can be picked up again after a worker restart and reports back to its thread.

It wins when Slack is one door among several. Connections belong to a workspace, and owners and admins choose the operations each one exposes. Writes stay off until enabled, and membership is re-checked on every call. Those rules hold for requests from the web, Slack, Teams, the CLI or an MCP client such as Claude Code.

It wins on the AI agent audit trail. Before each gateway call, Receipt writes an intent receipt and refuses the call if that write fails. Receipts are hash-chained, and the runtime rebuilds run state from them, so the record is what the system runs on. The replay view walks a run step by step without re-running anything.

The limits are real. Receipts are tamper-evident when verified, not signed. The record covers gateway calls, not shell commands or native CLIs in the sandbox. Approval is one decision per run, and requesters can approve their own. By default an organization runs one sandbox at a time, and Receipt does not offer SSO or SCIM.

Which Should You Choose?

Choose Slackbot if most agent work starts and ends in Slack: search, summaries, drafts and app actions under each person's own access. It is also the better pick if you need Slack's compliance controls around AI now, or want no new vendor or model key.

Choose Receipt if agents must do multi-step work in GitHub, Jira, cloud accounts or CRMs on connections the organization controls. It fits best when requests come from beyond Slack, and one record should cover a Slack co-worker and individual coding agents alike.

Use both when the jobs differ. Keep Slackbot for personal search and drafting, and @mention Receipt when a request needs a durable run and a receipt.

Conclusion

Slackbot answers a question every Slack customer has: how should people use AI where they already work? Receipt answers a different one: once agents act from several places, where should the organization's control and evidence sit? If the answer is Slack, Slackbot's design is hard to beat. If work also arrives from Teams, the web and coding agents, a record tied to one chat surface sees only part of it. Receipt writes its record at the gateway, before each call leaves, whichever door the request came through.

Slackbot details are based on its official documentation and announcements as of October 7, 2026; Receipt details reflect the product as shipped on that date. Both change quickly, so check the sources below for current behavior.