Where Agents Live: Slack, Teams, Google Chat and the CLI
The incident channel is already busy. Someone has pasted a graph, someone else a log line, and the one person with console access has typed "looking". The answer the team needs sits in a tool none of them has open.
Every tool that asks engineers to go somewhere else loses that moment. An agent can be right and still get ignored because it lives in a browser tab.
So CloudThinker's Frontier Investigation Agents live where the work already happens: Slack, Microsoft Teams, Google Chat and the terminal. The web app holds the full record. The other surfaces are doors into the same workspace.
Why the usual chat bot goes wrong
There are two common failures.
The bot is a separate product. It has its own credentials and permissions, and what it can do slowly drifts from the main app.
The bot doesn't know where it is. Every channel reaches every account, and a question asked in a social channel runs against production.
We designed around both. Every chat surface routes into a CloudThinker workspace, and the workspace is where connections, Auto Mode, approvals and history live. The surface decides nothing about what an agent may do.
01Where you type
Chat and terminal
- SlackChannels and threads
- Microsoft TeamsTeams and channels
- Google ChatDirect messages and shared spaces
- CLIHeadless chat and the Agent CLI
Decides nothing
02Mapping
Picks the workspace
- SlackChannel to workspace
- TeamsTeam to workspace
- Google ChatSpace or DM to workspace
- CLIOne stored credential per workspace
The real boundary
03CloudThinker workspace
Holds the rules
- ConnectionsWhat an agent can reach
- Auto Mode and approvalsWhat may run on its own
- NotificationsWhere results go
- HistoryEvery conversation and run
Same everywhere
The mapping is the boundary
Each integration maps a place in chat to a workspace. Slack maps channels. Teams maps teams. Google Chat maps direct messages and shared spaces. The mapping decides where an ordinary message runs, and so which connections it can use.
This is the setting to get right. In Slack, a message from an unmapped channel runs in the organization's oldest workspace, including its connections. Map every channel the bot can see, and remove the bot from channels that shouldn't run prompts.
Who a message runs as differs by surface.
01Slack channel
The mapped workspace
Ordinary messages run there regardless of the sender’s CloudThinker role.
02Slack war room
Linked users only
The sender must be an active CloudThinker user allowed to view incidents and use chat.
03Teams
Linked, or the owner
An unlinked sender runs as the workspace owner. With no owner, CloudThinker asks them to link first.
04Google Chat
Same Google account
Setup is confirmed with the Google account that sent the message.
War rooms are the strict case. A message in an incident war-room channel runs only when the Slack sender is linked to an active CloudThinker user with permission to view incidents and use chat. Otherwise CloudThinker replies that access was denied. The incident itself is covered in Resolve: An Incident From First Alert to Postmortem.
How a conversation works
The syntax is the same on every surface: @agent #connection your request, with / to run a skill or a command. Both the agent and the connection are optional.
In Slack and Teams, @CloudThinker starts a thread. Replies in that thread continue the same conversation without mentioning the bot again. Add a custom agent's @mention after the bot to route the request to it.
Alert destinations come from configuration, not from the prompt. You can ask an agent to raise an alert, but you can't tell it which channel to post in. Routing stays something a person set up and can review.
One notification matrix
Notifications map each event category to destinations: email, Slack, Teams or Google Chat, each with its own minimum severity. Slack at Medium and email at High is a normal setup. Preferences are per workspace.
A few rules shape it:
- In-app is always on. Channel switches only control external delivery, so the notification center stays the complete record.
- Slack notifications go to channels, not DMs. The team sees them in one place and members opt in by joining.
- External email addresses must verify before they receive anything.
- Google Chat direct messages never receive notifications. Only mapped shared spaces do.
Categories include agent interrupts (an agent paused for your action, such as approving a tool call), review findings, Optimize reports and the weekly digest, and connection health. Review findings arrive in each channel's own format: a Block Kit message in Slack, an Adaptive Card in Teams.
The terminal is a surface too
The cloudthinker CLI is in preview. One binary does two jobs.
Headless chat sends one prompt to CloudThinker and prints only the answer on stdout. Progress, the run ID and the continuation hint go to stderr, which keeps it pipeable. Exit codes let a pipeline branch without parsing text:
export CLOUDTHINKER_TOKEN="$CLOUDTHINKER_CI_TOKEN"
if cloudthinker chat -p "Review last night's failed deployments" --timeout 900 > report.md; then
echo "report ready"
else
case $? in
4) echo "still running, collect it in the next job" ;;
5) echo "waiting for an approval in the browser" ;;
*) exit 1 ;;
esac
fi
A client-side timeout never cancels the run. It keeps going server-side, and chat status collects it later from any machine. Exit code 5 means the run paused for an approval in the browser: a pipeline can't approve its own write.
The Agent CLI (cloudthinker agent) is a coding agent that runs in your terminal, in your repository. File edits and shell commands run on your machine. Cloud commands run in CloudThinker's Sandbox, with a connection credential injected for that run only and never sent to your laptop. A cloud write is a request the workspace decides, and there's no flag to bypass approval from a laptop.
Every Agent CLI session is mirrored into the workspace as a read-only conversation, so teammates can read what ran.
Design decisions
One workspace behind every surface. Slack, Teams, Google Chat, the CLI and the web app all run against the same connections and the same approval rules. A write requested from a thread gets the same decision it would get in the web app.
Integrations aren't connections. Adding CloudThinker to Google Chat doesn't grant access to other Google Workspace data. Drive attachments aren't downloaded, so upload the file to the message instead.
Setup takes two kinds of admin. A CloudThinker organization owner or administrator on the Team plan or above starts setup. On the provider side, a Slack Workspace Owner or app manager approves the app when App Approval is on, and in Teams a Global Administrator or Teams Administrator completes Microsoft provider approval and Entra consent. They can be different people, and neither side can wire it up alone.
Honest limits
- Google Chat is in early access for selected organizations. It can't upload generated files back into the chat.
- The CLI is in preview, and command names, flags and config formats may change before general availability. The Agent CLI runs on macOS and Linux and needs a paid workspace plan.
- An unmapped Slack channel falls back to the oldest workspace. That's the default you most need to change.
- In Teams, an unlinked sender runs as the workspace owner. Link accounts if that isn't what you want.
- Moving a Google Chat space to another workspace starts fresh conversations there. Earlier conversations stay in the original workspace.
Try it
Map one Slack channel or Teams team to a non-production workspace first. Then, in a thread:
"@CloudThinker which pods in the staging cluster restarted in the last hour, and why?"
"@CloudThinker summarize the open incidents for this team in five lines."
From a terminal, after cloudthinker login, send the same kind of question headless:
"Which S3 buckets have no lifecycle policy?"
Start a trial or book a walkthrough.