The work gets discussed in a channel and done somewhere else. Zero closes that gap: mention it in the thread, approve what it may touch, and it reaches the systems the answer lives in — as the same agent you use on the web.
Mention Zero where the work is already being discussed and it reads that thread — the screenshot, the back-and-forth, the decision. It replies in a thread so the channel stays clean, and the ask, the answer, and anyone's correction stay visible to the team.

A bug reported in the channel becomes a GitHub issue, then a pull request, then a preview link — each one posted back into the same thread. Zero asks before it touches a service it is not authorized for, scoped to one permission and one period.

Slack is where the work gets raised; a channel is a poor place to read a long run. A thread that starts in Slack is also a thread on the web, tagged with where it came from and one click from the original message — the full log, the files, every call it made.
Run triage-bug-report on the thread I just sent you.
Same workflow as in #bug-report. Here is what I did.
Not everyone in the work is on the payroll. Invite Zero to a channel you share with a client or a vendor and it reads that thread the same way — pulling the ticket status, drafting the reply for one of your people to send. Guests get the answer, never your access.
Where did the migration land? We are briefing our team tomorrow.
@Zerocheck the migration ticket and draft me a status I can send
Three of five steps are done, the fourth is in review. Draft is in your DM. View the draft
Nothing changes about how your team already communicates, and connecting a service is an approval rather than a key handover.
Add Zero to Slack, then invite it to the channels it should be in. It only sees the channels it has been invited to.
@Zero in the channel for team-visible work; DM it for drafts and anything private. The reply lands in a thread, so the channel stays readable.
When a job needs a service Zero is not authorized for, it sends you the approval — one connector, one permission, for a period you choose.
"@Zero triage-bug-report" runs a saved workflow on the current thread, and scheduled ones post their results back on their own.
Zero is not there to run the conversation. It sits in the channels it was invited to, follows what is already being said, and moves at the handful of moments where a team's work usually stalls — the catch-up, the thing reported but never filed, the decision nobody wrote down.
A hundred messages happened while half the team was asleep. Ask in the thread and get five bullets, plus the decision that is still open.
Someone drops a screenshot in the channel and moves on. Zero pulls the repro steps, files the issue, and replies with the link before the context is gone.
Capture what the thread settled into the doc or tracker other people read, with the reasoning and the owner attached to it.
A person joining the channel mid-project can ask what happened and get the history without making anyone stop to retell it.
Customer replies, financial checks, and anything half-formed go to a DM. Same agent, same workflows, an audience of one until you decide otherwise.
Any saved workflow can be called by name from a thread, and it is the same workflow the web app runs — so the version someone got right serves the whole channel, and nothing is Slack-only.
A wide catalog is only useful if connecting something is a moment's work, and only safe if putting a workflow in front of the team does not put your accounts there too. Both are settled the same way.
When a job needs a service Zero is not authorized for, it posts the request into the same Slack thread rather than failing quietly. Pick the permission and how long it lasts, approve, and the job carries on from where it stopped — no console, no admin ticket.
Publish a workflow to the team and you have shared the instructions, not your Gmail or your CRM. Whoever calls it from a channel runs it against their own connected services, under their own grants, so it reaches exactly as far as the person running it and no further.
Connect by approving OAuth or by pasting a key; either way it is stored outside the environment the agent runs in and attached at the network boundary. It is not in the thread, not in the workflow, and not in anything the agent can print.
No. A Slack AI assistant only sees the channels you invite it to and the messages that mention it. Remove it from a channel and it loses that channel's history immediately.
Who sees it. In a channel the ask, the answer, and anyone's correction are visible to the team. A DM behaves like a web chat and is the right place for drafts and anything sensitive.
Yes. Channel, DM, and web run the same agent with the same workflows, connectors, and permissions. You can call a saved workflow by name from a thread and it behaves exactly as it does on the web.
Through the same connectors the web app uses. When a job needs one you have not authorized, Zero sends you the approval instead of failing quietly, scoped to one permission and one period.
Custom connectors cover most services with an API, including internal ones, so a tool that is not in the built-in catalog is not a dead end. It is reached and approved the same way as everything else.
Yes, if you invite it there. It reads the shared channel like any other, and the guests in it stay guests — they see what is posted to the channel and never inherit a connector, a workflow, or anyone's account.
Yes — that is the point. Describe the Slack workflow in a sentence and attach a trigger; automated Slack messages then post themselves. There is no canvas and no step editor.
@mentions and direct messages work on any Slack plan. The AI agent surface inside the Slack app requires a paid Slack plan.
Zero also covers workflows and automation, generative services, and team collaboration. See the built-in web services, the models you can switch between, and pricing.
Ask where the work is discussed and let the answer come back in the thread.