sequenced.ai
Articles/Agents & support/Blueprint//8 min read

Traversal: AI incident workers and production context

Understand Traversal’s Incident Workers, production model and knowledge tools, with beta boundaries, custom pricing and remediation controls.

By Sequenced deskAI-assisted, source-led · how we work
Visit Traversal website ↗
Incident WorkersGenerally available
Alert WorkersPublic beta
Production modelSystem context
Knowledge BankInspectable context
Traversal mark
Traversaltraversal.com · independent research

Represent this company? Verify your work email to access its workspace, or send the desk a factual correction.

Traversal builds AI agents for production incident work, using connected telemetry, code and system context to investigate failures. Its current offer combines a production model, a knowledge layer and Workers that participate where responders collaborate. The decision is whether that system can maintain an accurate account of a changing environment and help an incident team reach a justified conclusion. The attractive promise is continuity across a long incident; the practical test is whether the agent’s evidence stays useful as the situation changes.

In brief
  1. 01The platform Traversal combines agents with a model of production systems, dependencies and operational context.
  2. 02The experience Incident Workers operate in Slack, Teams or web sessions and maintain a shared investigation record.
  3. 03The distinction Incident Workers are generally available; Alert Workers remain public beta in the reviewed announcement.

01 / ProductProduction context supports an ongoing incident worker

Traversal’s Production World Model page describes a connected representation of applications, services, infrastructure, APIs, dependencies, code and changes. The company says this context is updated from the environment. That is the foundation of its product claim: an investigation should reason about the relationships between systems rather than search isolated log messages without understanding their role.

The Workers page describes an incident participant that operates in Slack, Microsoft Teams or the web. A live scratchpad maintains the working synthesis, and private chat lets a responder ask questions without adding to the incident channel. These are interaction features around an investigation; they do not establish that every conclusion is correct or that every incident can be resolved automatically.

The availability announcement makes an important distinction: Incident Workers are generally available and become the default incident experience, while Alert Workers are in public beta. The latter continuously triage alert channels. A buyer should not transfer the release status of one mode to the other simply because both use the Workers name.

02 / AudienceFor organizations where context is spread across teams

Traversal is relevant when an incident crosses application, infrastructure and organizational boundaries. A service may fail because an upstream dependency changed, a configuration drifted or an operational assumption became false. The people who know those details may not all be on the same call. An agent that preserves context can help, provided the team can inspect and correct what it has learned.

The Grafana Labs blueprint offers a useful comparison for the telemetry and investigation environment already used by many engineering teams. The New Relic blueprint helps frame another observability platform with AI assistance. Traversal should be evaluated for the additional production reasoning and collaboration it provides around the tools a team already trusts.

An organization should also be ready to name service owners and define incident authority. A worker can assemble evidence, but it cannot resolve a disagreement about who is allowed to change a shared database. If that authority is unclear, a proactive agent may make the ambiguity more visible without solving it. The pilot needs an owner who can settle both technical scope and operating rules.

03 / WorkflowA proposed investigation that survives a responder handover

Consider a proposed pilot for a recurring search-latency incident that spans two engineering shifts. This is an illustrative evaluation, not a deployment we tested. Start with a historical incident containing a misleading early hypothesis and a later discovery. Give the worker only the information available at each stage, so the evaluation tests whether it updates its reasoning rather than simply recognizes the final postmortem.

At the beginning, ask for the affected request path, the time window and the relevant changes. Compare the worker’s account with the available traces and deployment record. If it claims that a dependency caused the slowdown, require evidence showing the connection. Two metrics changing together are a lead; they are not automatically a causal explanation.

Use the live scratchpad as the handover artifact. It should separate confirmed observations, working hypotheses, attempted mitigations and unresolved questions. When the next responder joins, ask whether they can understand the incident without replaying the full channel. The useful measure is preserved understanding, including uncertainty, rather than the length or polish of the summary.

Traversal’s Knowledge Bank exposes several kinds of context: an automatically maintained wiki, memories from investigations, uploaded documents and reusable skills. The page describes comments as a way to correct wiki content. In the proposed pilot, introduce a changed dependency and check whether a correction reaches the next investigation instead of remaining an isolated chat message.

Keep investigation separate from repair during the first phase. A responder can use the evidence to decide whether to roll back a release or change a configuration through the normal operational process. Then ask the worker to verify recovery against the affected service, including the original slow request path. An improvement in an aggregate dashboard may hide a remaining problem for one customer segment.

Finally, inspect the postmortem that evolves from the investigation. A useful record explains what was observed, why the final cause was accepted and what remains uncertain. It should not rewrite an unsuccessful mitigation as part of a smooth success story. That record can become a future test case and a source of operational knowledge, provided the team retains a way to correct it.

04 / PricingThe quote depends on the environment and work assigned

Traversal’s pricing page starts with a personalized review of the environment. It asks about alert and incident volume, severity, telemetry footprint, team structure, connected systems and rollout scope. The reviewed page does not publish a numerical subscription or per-investigation tariff. A meaningful comparison therefore requires a proposal for the same workload used in the pilot.

Ask how an incident that runs across several shifts is counted, whether repeated alerts create additional work charges, and how the public-beta Alert Worker mode is priced relative to Incident Workers. Also establish whether a pilot includes only investigation or any remediation capability. These are commercial questions for the vendor, not inferred fees from the product architecture.

The security page describes private or on-premises deployment, bring-your-own-cloud and bring-your-own-model options. Their availability does not mean every arrangement is included in a standard price. Ask the proposal to separate platform fees from customer-managed infrastructure and model costs, then compare the whole arrangement with the existing incident process.

RoutePublished positionConfirm before rollout
Incident WorkersGenerally available; custom pricingVolume, connected systems and pilot scope
Alert WorkersPublic betaEligibility, limits and commercial treatment
Private / BYOC / BYOMDeployment options describedInfrastructure, model costs and support

Commercial scope from pricing, deployment options and release status, accessed 21 October 2026. No numerical tariff verified.

05 / DistinctionsContinuity and correction are more useful than a one-off answer

A worker that remains involved through an incident can preserve the connection between a hypothesis and the later evidence that supports or defeats it. This is especially useful during shift changes or when several teams join at different times. The quality bar is whether a new responder can act on the current state without inheriting an outdated assumption.

Knowledge Bank makes retained context a visible part of the evaluation. A runbook, an observation from a prior incident and an automatically inferred dependency are different kinds of information. They should not all carry the same authority. A team should be able to ask where a belief came from and whether a newer observation has superseded it.

The Workers design also includes a way to remove a worker from a channel and a promise to avoid unnecessary interruption. That is worth testing during a simulated high-pressure incident. Helpful timing is part of operational quality: a correct but distracting message can still slow the team, while silence is only useful if urgent evidence reaches the right person when needed.

06 / QuestionsRead-only context and enabled remediation need separate controls

Traversal’s security page uses broad read-only language, while the self-healing page describes applying and verifying fixes when that capability is enabled. It also describes choosing what can run autonomously and what should arrive as a pull request for review. These pages should not be compressed into a claim that all platform operations are always read-only or always autonomous.

Before enabling remediation, ask for the concrete permission model for each tool and the conditions under which a person approves a change. Confirm how an automatic action is stopped, how the system verifies the resulting state and how an ambiguous result is escalated. The proposed investigation pilot deliberately avoids relying on those write capabilities until their controls have been reviewed.

The company publishes scale and outcome claims, but we did not independently test them or inspect customer deployments. Test missing telemetry, stale knowledge and a false initial hypothesis on your own system. Also confirm the current release status of the specific Worker mode: an incident capability described as generally available does not remove the operational uncertainty of a separate public beta.

07 / DecisionChoose a worker for a sustained, inspectable investigation

Traversal is worth evaluating when incident understanding is lost between tools, teams or shifts. Start with one service boundary and a historical case that contains real ambiguity. Judge whether the worker maintains an accurate, correctable account through the whole incident. Expand to proactive alert work or remediation only after the team understands the release status, permissions and commercial scope of those additional jobs.

Long incidents

Test a responder handover

Use the scratchpad to separate confirmed facts from hypotheses and inspect what survives a shift change.

Evaluate continuity
Operational knowledge

Challenge one stale assumption

Check whether a correction updates the context used in a later investigation.

Test correction quality
Autonomous repairs

Define the permitted action set

Confirm each tool permission and approval rule before enabling self-healing.

Separate diagnosis from action
What should we explore next?

A business worth understanding.

Suggest your business or one you find interesting. Tell us what you want to understand about its product, positioning, design or workflows.

Suggestions are free. Selection and publication stay with the desk.

Sources
Filed under Agents & supportCompany TraversalNot affiliated with TraversalRequest a correctionRequest a refresh by email

Continue reading

All in this category