Skip to main content
Traversal Workers are proactive AI SREs. Rather than waiting for you to reach for Traversal, a Worker joins a channel and works alongside your team like a teammate — reading the situation and doing what’s worth doing on its own. You never have to catch the right moment or learn how to prompt it. There’s no way to use it wrong. It just works. A Worker runs on Traversal’s Causal Search Engine and Production World Model, the same engines behind every Traversal investigation. It belongs to the channel rather than to you, so everyone sees the same investigation and the same running picture of where things stand — nobody re-explains the incident to whoever just joined.
Read the launch announcement.

​
Three kinds of Worker

Incident Workers are for high-severity incidents. One joins the moment the incident is declared and helps the team all the way through to resolution, driving down MTTR.

Proactive in Slack. Nobody tagged it.

Alert Workers are for the alert channels a team works out of on an ongoing basis. They help you catch incidents sooner, cut the time you spend triaging alerts, and improve your system over time.

Every alert triaged autonomously, so you can focus on the ones that matter and catch incidents sooner.

Custom Workers are for the work that is neither an incident nor an alert feed. You give one a mission in plain language when you deploy it, and it follows that channel and acts on your direction — watching a rollout in a deployment channel, surfacing the recurring problem behind a run of customer reports in a support channel, or keeping a running picture of ongoing work in a team or project channel. In every case, a Worker follows the full channel including threads, grounds every conclusion in evidence from your connected systems, and takes plain-language custom instructions and schedules.

​
Where Workers run

  • Slack and Microsoft Teams channels, where they work alongside responders.
  • The Traversal web app, where you can start a shared Worker when the work isn’t tied to an existing channel.
You never have to summon a Worker — but you can always talk to one. Mention @Traversal or reply in a thread and it answers, with everything it already knows about the channel behind the response.

​
Running a fleet from the web

The Workers console gives you a single pane of glass into all your Workers, so you don’t need to open every channel and read dozens of threads. It’s synthesized for you. Each Worker reports a one-line summary of what it’s doing and a status it sets for itself: Urgent, Attention, or Stable. Sort by status and go straight to the situations that are deteriorating. The console is also where you deploy Workers and set auto-deploy rules.

Each Worker keeps its own status current, so the console tells you where to look first without opening anything.

Opening a Worker adds what the channel doesn’t hold: a scratchpad with its working synthesis of the channel, a searchable activity feed, and private chat for questions that shouldn’t add noise to the response. Schedules and custom instructions are set there too.

Workers console

Deploy Workers, set auto-deploy rules, and track the fleet.

Worker features

Scratchpad, activity feed, private chat, schedules, and instructions.

​
Getting started

Open Workers in the Traversal web app and scan your workspace — Traversal reviews the channels it can already see and recommends where to deploy. You can also deploy to a specific channel, or set an auto-deploy rule that covers every future inci- channel.

​
FAQ

The channel it’s deployed to, and the observability, code, ticketing, and knowledge context you’ve already connected to Traversal. Workers operate within the same Slack scopes described on the Slack page — read-only wherever they can be. Traversal can also be configured to follow the transcript of a live incident call, giving a Worker the same real-time context as the people responding.
No. A Worker reads, reasons, explains, and recommends. It never modifies your alerting, paging, or routing, and it does not take destructive action. You stay in control of what happens next.
Restraint is the design. In an incident channel a Worker holds back until it has something evidence-backed and worth the room’s attention, and threads its replies so the main channel stays for findings everyone needs.In an alert channel it answers every fire, but quietly — each response goes in that alert’s own thread, so the channel reads exactly as it did before, just with a verdict on each alert.
You shouldn’t need to — a Worker is good out of the box, and most teams never change a thing. But when you have an opinion, custom instructions let you set it in plain English.Set them on a single Worker to shape how it behaves in that one channel, or on a channel pattern so every future channel matching it inherits them — which is how you give a Worker in an inci- channel different marching orders from one in a retro- channel, without configuring either by hand.
Yes. Click Stop proactive mode on the message it posts when it joins, or use Edit Worker in the web app. Stopping it halts new proactive work; its activity and scratchpad stay available for review.You don’t lose Traversal in the channel by doing this. Mention @Traversal any time you have a question and it still answers — it just stops acting on its own.
The Workers console — the fleet view, each Worker’s scratchpad and activity feed, private chat, schedules, and custom instructions. Workers also run in Microsoft Teams now, you can start one directly from the web when there’s no channel for it, and Alert Workers are new.

​
Support

Questions or issues? Email support@traversal.com.