Slack dates assistant_view for February 2027 and the migration is a one-way door

Summary. On 20 August 2026 Slack put a date on a deprecation it had left open for two months: the Assistant messaging experience (assistant_view) ends in February 2027. Two methods are replaced — assistant.threads.setStatus becomes agents.sessions.setStatus, and assistant.threads.setTitle becomes agents.sessions.rename, both on chat:write at Tier 3 rate limits of 50+ per minute. Existing calls keep working through a compatibility bridge with no published end date. Three things make this harder than a method rename. Switching the manifest from assistant_view to agent_view "cannot be reversed" and, for a distributed app, "will require going through Marketplace review." The loading state no longer clears when you post a message, so an app that does not explicitly set active leaves the session spinning for a full hour. And the reference docs Slack links from its own announcement still say assistant_view will be deprecated "eventually," with no date at all.

What changed on 20 August 2026

The changelog entry, tagged both Announcement and Deprecation, states it directly: "The Assistant messaging experience (assistant_view) will be deprecated in February 2027. The assistant-related methods that power it are being replaced by a new set of API methods: the Agent Sessions API."

The method map is short:

Note that setTitle maps to rename, not to setTitle. A mechanical find-and-replace across a codebase will miss it.

The session model itself is new. Per the agent sessions guide, a session carries one of four statuses: active ("the agent is alive and ready for the next prompt or task"), processing ("the agent is working on a user's task. A stop button is shown to the user"), suspended ("the agent cannot make progress until the user intervenes"), and closed. Only apps declared as agents in app settings can create sessions, which "requires the assistant:write scope," with chat:write also required "to manage thread-based sessions."

The two changes that break working apps

Neither of these is in the changelog. Both are in the migration guide.

The first is the loading state. Verbatim: "Unlike assistant.threads.setStatus, the loading UX no longer disappears automatically when your app posts a message to the thread. We expect apps to call agents.sessions.setStatus with status: \"active\" when they finish their work; otherwise the session stays in processing until it times out after one hour."

Most Slack agents written against the old API set a status, do the work, post the answer, and stop. Under the new model that app shows a spinner next to a completed answer for sixty minutes. Nothing errors. The user sees a bot that appears stuck. This is the same shape of failure we have written about in AI agent evals that fail silently in CI/CD: the code path succeeds, the observable behaviour is wrong, and no test catches it because no test asserts on the state you forgot to clear.

The second is the stop button. From the `agent_session_stopped` event reference: "All apps that manage agent sessions must handle this event; supporting stop is not opt-in." And: "The session status does not update automatically when the user clicks stop. Your app is responsible for transitioning the status." An app that ignores the event keeps streaming into a session the user has already stopped, and keeps the session in processing on Slack's side.

There is a related timing constraint worth designing around. "Sessions in processing time out after one hour and automatically transition to active. Setting processing again restarts the one-hour timer." For a long-running agent, a heartbeat that re-sends processing is now a requirement rather than a nicety. Slack also removed a customisation: "While a session is in processing, Slack shows a standard 'Working…' loading UX. Custom loading messages are not supported."

The manifest switch cannot be undone

This is the part that changes how you schedule the work.

From the migration guide, verbatim: "Once you change your app's manifest from assistant_view to agent_view, you can't revert to the Assistant messaging experience. After the change, users will need to hard refresh Slack to see the Agent messaging experience. If your app is already distributed, this change will require going through Marketplace review."

So for a distributed app the migration is not a deploy. It is a deploy plus a review queue you do not control, with no rollback. The app manifest reference repeats the constraint and adds that "New apps can only use agent_view," and that agent_description is required inside the agent_view subgroup with "Maximum length is 300 characters." The nested assistant_description field is renamed to agent_description in the switch.

The guide's own five steps are: switch the manifest, detect DM opens via app_home_opened with tab set to "messages" instead of assistant_thread_started, move suggested prompts to the top of the Messages tab, move from assistant.threads.* to agents.sessions.*, and implement the stop button. The guide then notes that step 4 "is not yet required to switch experiences," so the manifest change and the method change are independent. Do the method work first. It is reversible; the manifest change is not.

Minimum tooling was set back in the 30 June 2026 changelog that introduced agent_view: "The Slack CLI v4.4.0, Python SDK v3.43.0 with Bolt Python v1.29.0, and @slack/web-api@7.18.0 (for the Node Slack SDK) are required to access the Agent View feature." If your SDK pins predate those, the migration starts with a dependency bump — the same class of upgrade covered in our notes on the Slack Node SDK v8 and Socket Mode v3 migration.

Slack's own docs do not agree on the date

The 20 August changelog says February 2027. The pages that changelog points readers to were not updated to match.

The app manifest reference still reads: "Apps that already use assistant_view can continue to do so for now, but assistant_view will eventually be deprecated, and we'll ask existing apps to migrate to agent_view." The 30 June changelog uses the same word. So does the opening of the migration guide.

One page carries a date. Three pages say "eventually." Until the reference documentation catches up, February 2027 should be read as an announcement, not as a contract.

There is a second, quieter gap. The compatibility bridge has no end date anywhere. The changelog says "For now, your existing calls keep working through a compatibility bridge." The migration guide says Slack "plan[s] to deprecate" the two legacy methods. The method reference pages for assistant.threads.setStatus and assistant.threads.setTitle carry no deprecation banner at all. February 2027 attaches to the manifest field, not to the API bridge, and no Slack page links the two. Nor does any page say what "deprecated" means in failure terms for assistant_view apps that have not migrated by then.

That open-endedness has precedent on this exact method. A 5 March 2026 changelog entry warned that "The assistant.threads.setStatus API method will eventually no longer accept the assistant:write scope in favor of the chat:write scope exclusively, so update your app soon!" Five months on, that is still undated. It also explains why the replacement methods are chat:write only.

Slack has slipped this kind of deadline three times

Worth knowing before you reprioritise a sprint around February 2027.

The classic apps deprecation, announced 30 September 2024, moved four times. The original date was September 2025. An 11 April 2025 entry says "we have decided to push back the deprecation date to May 25, 2026." A 29 July 2025 entry pushed it again "to November 16, 2026." Then on 8 December 2025: "Based on feedback from our customers and developer community, we have decided to pause this migration. Classic apps will continue to work for the foreseeable future."

Three slips and then an indefinite pause, all documented on Slack's own pages. The reasonable planning posture is to do the method-level work now, because it is reversible and it fixes real bugs today, and to treat the irreversible manifest switch as a scheduled decision rather than a February deadline you must hit.

India-specific considerations

For Indian product teams shipping Slack agents to global customers, the Marketplace review requirement is the schedule risk, not the code. A review queue sits outside your release calendar and cannot be rolled back once you enter it, so the manifest switch should not land inside a festive-season change freeze or immediately before a customer go-live.

On data handling, the new session model surfaces conversation titles that users can rename at any time, delivered to your app as agent_session_title_changed. Titles written by users can contain personal data. If you persist session titles for recall or analytics, that store falls under the Digital Personal Data Protection Act 2023 like any other user-generated field, and it is new storage that did not exist under the thread-title model.

What to do this quarter

Move assistant.threads.setStatus and assistant.threads.setTitle to agents.sessions.setStatus and agents.sessions.rename now. This is reversible and independent of the manifest.

Add an explicit setStatus call with status: "active" at every exit path, including error paths. Assume the spinner never clears on its own.

Subscribe to and handle agent_session_stopped, and transition the status yourself. Handle agent_session_title_changed if you cache titles.

Add a heartbeat that re-sends processing for any task that can exceed one hour.

Bump the SDKs to at least Slack CLI v4.4.0, Python SDK v3.43.0 with Bolt Python v1.29.0, or @slack/web-api 7.18.0.

Schedule the manifest switch deliberately, with the Marketplace review lead time booked, and only when you are ready to never go back.

What is still unknown

Slack has not published an end date for the assistant.threads.* compatibility bridge, has not stated what happens to unmigrated assistant_view apps in February 2027, and has not said whether adopting agent_view triggers a reinstall or consent prompt for existing users. No rate-limit tier is documented for event delivery. Given the classic-apps history, the February date may move; the irreversibility of the manifest switch will not.

FAQ

How eCorpIT can help

We handle this kind of platform migration as scoped engineering rather than a search-and-replace: move the methods first because that part is reversible, add the status and stop-button handling that the new model requires, then schedule the irreversible manifest change around the Marketplace review window. Our senior engineering teams build and maintain production Slack agents, and we design data handling aligned with DPDP Act 2023 requirements where session titles and conversation content are stored. eCorpIT is CMMI Level 5, MSME Certified and ISO 27001:2022 certified. Reach us through /contact-us/.

References

1. Slack changelog, 20 August 2026: the next wave of Agent messaging experience — the February 2027 date and the method replacements.

1. Slack agent sessions guide — session statuses, scopes, one-hour timeout.

1. Migrating to Agent messaging — five migration steps, irreversibility, Marketplace review, loading-state change.

1. Slack app manifest reference — agent_view, agent_description, and the "eventually" wording.

1. `agents.sessions.setStatus` reference — scopes, arguments, Tier 3 rate limit.

1. `agents.sessions.rename` reference — title length limits and errors.

1. `agent_session_stopped` event reference — mandatory handling and payload fields.

1. Slack changelog, 30 June 2026: introducing the Agent messaging experience — minimum SDK versions.

1. Slack changelog, 2 July 2026: agent context has landed — the app_context_changed event.

1. Slack changelog, 5 March 2026: setStatus scope update — the undated assistant:write to chat:write change.

1. Slack changelog, 30 September 2024: classic apps deprecation — the original deadline.

1. Slack changelog, 11 April 2025: classic apps extension — first slip, to 25 May 2026.

1. Slack changelog, 29 July 2025: classic apps extension — second slip, to 16 November 2026.

1. Slack changelog, 8 December 2025: classic apps deprecation paused — indefinite pause.

1. Ministry of Electronics and IT, Digital Personal Data Protection Act 2023 — obligations referenced in the India section.

_Last updated: 20 August 2026._