Slack is deprecating assistant_view in February 2027: what breaks and how to migrate

Slack says the Assistant messaging experience, assistant_view, will be deprecated in February 2027. The replacement is agent_view and the Agent Sessions API. This is the plan for an in-house assistant that still listens for assistant_thread_started and calls assistant.threads.*.

"What breaks" here means the behaviour that changes: where the conversation lives, how you detect an opened DM, and the loading state. Slack hasn't published an exact day in February 2027, and it hasn't said what happens to apps still on assistant_view after that. We'll update this page when Slack publishes a firm date.

Every claim below is from Slack's 30 June 2026 changelog, 20 August 2026 changelog, migration guide, Agent sessions guide, or DM experience note.

Short answer

• What's deprecated, and when. assistant_view will be deprecated in February 2027. Slack hasn't published the day, or what happens afterwards. New apps can already only use agent_view. Existing assistant_view apps can continue to use it for now.
• What to change. Point the manifest at agent_view. Listen for app_home_opened with tab == "messages" instead of assistant_thread_started. Move suggested prompts to the Messages tab. Call agents.sessions.setStatus and agents.sessions.rename. Subscribe to agent_session_stopped.
• What's one-way. Switching the manifest to agent_view can't be reversed. Users need a hard refresh. Apps distributed through the Slack Marketplace go through review.

Timeline: what Slack has announced, and what it hasn't

30 June 2026. Slack introduced agent_view. New apps can only use the Agent messaging experience. Existing assistant_view apps can continue to use it for now. Conversations move to the standard Messages tab.

20 August 2026. Slack named the deprecation. The Assistant messaging experience (assistant_view) will be deprecated in February 2027. The assistant methods are being replaced by the Agent Sessions API. agents.sessions.setStatus replaces assistant.threads.setStatus. agents.sessions.rename replaces assistant.threads.setTitle. For now, existing calls keep working through a compatibility bridge. Slack recommends moving to agent_view now.

February 2027. Slack has published the month, not a day, and hasn't said what happens to assistant_view apps after that date.

Slack also says it plans to deprecate assistant.threads.setStatus and assistant.threads.setTitle in favour of the sessions methods. No date is given for those two methods. The bridge is why they still work today. It isn't a promise that they keep working through February.

What changes for your bot

These are the differences Slack documents. Walk them before you edit the manifest.

One naming trap. The Agent sessions page header says agent_sessions.*. The methods on that same page are agents.sessions.setStatus and agents.sessions.rename. Call agents.sessions.*.

What keeps working for now: the compatibility bridge

You don't have to rewrite every call on the day you switch the manifest. Slack bridges the old methods onto sessions.

• assistant.threads.setStatus with a non-empty status string sets the session to processing.
• The same method with an empty status string sets the session to active.
• assistant.threads.setTitle applies that title to the session.
• Apps that already use chat.startStream and chat.stopStream get sessions automatically.

The bridge is why existing calls keep working for now. Once you call agents.sessions.setStatus with processing, posting a message doesn't set active. Slack recommends moving the method calls in the same change as the manifest, even though the bridge means that move isn't yet required to switch experiences.

Step-by-step migration

These five steps are Slack's order, from the migration guide. Do them on a staging app. The request bodies are Slack's own Web API examples. The Bolt handlers use those event names, and status updates call agents.sessions.setStatus through WebClient api_call / apiCall.

1. Manifest: assistant_view to agent_view

assistant_view becomes agent_view. The nested assistant_description becomes agent_description. You can do the same thing in App settings, on the Agent tab. Slack's example of the manifest block is:

{
  "features": {
    "agent_view": {
      "agent_description": "Your agent description here"
    }
  }
}

Once the app is on agent_view, you can't switch it back. Users have to hard refresh Slack. Marketplace apps go through review before users get the change.

2. Replace assistant_thread_started with app_home_opened

Subscribe to app_home_opened and check that tab is "messages". That replaces assistant_thread_started.

Bolt for Python:

@app.event("app_home_opened")
def handle_home_opened(event, say):
    if event.get("tab") == "messages":
        # The user opened a DM with the app.
        pass

Bolt for JavaScript:

app.event("app_home_opened", async ({ event }) => {
  if (event.tab === "messages") {
    // The user opened a DM with the app.
  }
});

Root messages change in the same step. They come from the user. They no longer carry subtype = "assistant_app_thread". Any branch that keys off that subtype won't see the threads it used to see.

3. Rework suggested prompts for the Messages tab

Prompts now sit at the top of the Messages tab, and thread_ts is no longer required. If the bot chose prompts from the thread it was in, review that logic before you flip the manifest. A prompt that only made sense in one conversation becomes the starting point for the whole DM.

4. Move assistant.threads.* to agents.sessions.*

Status and title are separate methods. A non-empty old status maps to processing, an empty one to active. There's no field for "is typing...".

Before, from Slack's migration guide:

POST /api/assistant.threads.setStatus
{
  "channel_id": "C123",
  "thread_ts": "1234123.232342",
  "status": "is typing..."
}

POST /api/assistant.threads.setTitle
{
  "channel_id": "C123",
  "thread_ts": "1234123.232342",
  "title": "Deep sea diving research"
}

After:

POST /api/agents.sessions.setStatus
{
  "channel_id": "C123",
  "thread_ts": "1234123.232342",
  "status": "processing",
  "title": "Deep sea diving research"
}

POST /api/agents.sessions.rename
{
  "channel_id": "C123",
  "thread_ts": "1234123.232342",
  "title": "Deep sea diving research"
}

When the work is finished, call setStatus with active. Use suspended when you need the user to answer, and closed when the conversation is done. If you only chat.postMessage, the loader stays up. The bridge still accepts the old methods. Slack still asks you to move them in this same change.

5. Subscribe to agent_session_stopped and implement stop

Slack shows a native stop button while the session is processing only if the app subscribes to agent_session_stopped. Without that subscription the user gets a loader they can't click, and agents.sessions.setStatus returns a missing_agent_session_stopped_event_subscription warning.

The click doesn't change the status for you. Your handler stops the work, tells the user, and moves the session off processing.

Bolt for Python:

@app.event("agent_session_stopped")
def handle_stop(event, client):
    # Stop in-progress work for this channel and thread, then leave processing.
    client.api_call(
        api_method="agents.sessions.setStatus",
        json={
            "channel_id": event["channel"],
            "thread_ts": event["thread_ts"],
            "status": "active",
        },
    )

Bolt for JavaScript:

app.event("agent_session_stopped", async ({ event, client }) => {
  // Stop in-progress work for this channel and thread, then leave processing.
  await client.apiCall("agents.sessions.setStatus", {
    channel_id: event.channel,
    thread_ts: event.thread_ts,
    status: "active",
  });
});

Slack's payload includes channel, thread_ts, user, and streaming_message_ts. That array can be empty, and an empty array still means you should stop work that wasn't a stream. team_id sits on the event_callback envelope. If your UI stores titles, also listen for agent_session_title_changed. It carries title and, when there was one, previous_title.

The four bugs we'd test for

Run these four on the staging app after the manifest change, then again after a hard refresh. Each of these can be broken while the bot still replies.

A spinner that never clears

Reply to a message after setting processing. If you never set active, "Working..." stays on screen until the one-hour timeout. The old setStatus cleared when you posted. This one doesn't.

A missing stop handler

With the session in processing, there should be a stop button. If not, subscribe to agent_session_stopped and reinstall. Click stop. The work should halt, and the status should leave processing. A handler that only logs the event leaves the loader up.

Suggested prompts gone, or in the wrong place

Open the DM and look at the top of the Messages tab, not inside a thread. Prompts you still attach to a thread_ts, or that you only set on assistant_thread_started, won't show where people now look.

Logic that relied on assistant_app_thread

The root message of a new DM should be the user's, without subtype = "assistant_app_thread". Search the codebase for that subtype and for assistant_thread_started before you call the staging test done.

Before you flip the manifest: a pre-flight checklist

The manifest edit is the point of no return. Run this list on the staging app first.

• Tooling. Slack CLI v4.4.0 or later. Python SDK v3.43.0 with Bolt for Python v1.29.0. @slack/web-api 7.18.0 or later for the Node SDK. Those are the minimums Slack names for agent_view.
• A separate staging app. Copy the manifest, switch that copy to agent_view, and run the four tests above. Don't learn the one-way change on the production app.
• Marketplace review. If the app is distributed, budget time for review before users see the new experience. The review is part of the update submission.
• Admin settings. Workspace admins can enable or disable the Agent experience per app, and the Slack client follows that setting. Confirm it's on for this app in staging, then in production.
• A hard-refresh note for users. After the production manifest ships, people need to hard refresh Slack or they will still see the old view.
• Scopes. Declaring the app as an agent adds assistant:write. Thread sessions need chat:write. Icon or username overrides on the loading state need chat:write.customize. Reinstall after scope changes so the token picks them up.

What we'd leave alone

We wouldn't rewrite the prompts or swap the model in the same release. The migration changes where a conversation lives and how status is signaled. If the answers also change that week, you can't tell a session bug from a model change.

Leave ticket routing and how you store tokens for another release. Our notes on routing Jira tickets from Slack and on running one Slack bot across workspaces cover those systems. They aren't steps in this migration.

Migrate yourself or get help

A small bot in one workspace can follow Slack's five steps in-house.

It gets wider when the same app is installed in more than one workspace, or when it's listed on the Marketplace. Review sits on the path, and the event change has to land everywhere assistant_thread_started lived. The API work is the same for a team of 5 or 100. What grows is the number of installs you reinstall after the scope change.

If you want a second pair of eyes inside the app, that's a discovery call, not a package we're quoting on this page. We build Slack bots and other automation inside your systems, and you own the code. The service page is Slack bots and automation. You can also write to us.

FAQ

When is Slack deprecating assistant_view?

Slack says the Assistant messaging experience, assistant_view, will be deprecated in February 2027. It hasn't published an exact day or said what happens to apps still on it afterwards. New apps can already only use agent_view. We'd plan the migration now and not wait for a firm date.

Do existing assistant_view apps keep working?

Existing assistant_view apps keep working for now, and assistant.threads.setStatus and setTitle calls are bridged to the new sessions system. Slack hasn't said what happens after February 2027. The safe move is to switch to agent_view and the Agent Sessions API before then.

What replaces assistant.threads.setStatus and setTitle?

agents.sessions.setStatus replaces assistant.threads.setStatus, and agents.sessions.rename replaces assistant.threads.setTitle. Sessions have four states: processing, active, suspended and closed. One change catches people out: the loading state no longer clears when you post. Your app has to set active, or it times out after an hour.

What replaces the assistant_thread_started event?

In agent_view, listen for app_home_opened and check that tab is "messages". That's how you know a user opened a DM with your app. Root messages also change: they come from the user and no longer carry the assistant_app_thread subtype, so any logic keyed on that needs updating.

Can I switch back to assistant_view after migrating?

No. Changing the manifest from assistant_view to agent_view is one-way. Users need to hard refresh Slack to see the new experience, and apps distributed through the Slack Marketplace go through review first. Test on a separate staging app before you change production.

How long does the migration take?

It depends on how much your bot relies on per-thread prompts, assistant_thread_started and the old loading indicator. A simple bot can follow Slack's five-step guide. If yours is multi-workspace or listed on the Marketplace, plan for review time too.

Sources, all from Slack: 20 August 2026, 30 June 2026, the migration guide, Agent sessions, and the DM experience note.