| TL;DR: Finding the cause of a software failure often means connecting customer complaints with code changes and system errors scattered across different tools. Kosmos brings those possible connections and supporting evidence into Slack, where support staff and engineers can review them together. People confirm the cause, and Kosmos saves the finding for future investigations. As AI agents take on more work across business systems, they could use these confirmed root causes to guide future actions. That makes the quality of human review important long after the original incident. |
A customer tells support that a feature has stopped working. An engineer shipped an update that morning, and a Salesforce administrator is now looking into a failed automated workflow. Each person may have a clue, but nobody knows yet whether the events are connected.
Before support can explain what happened, someone has to compare the available evidence and talk to the people involved. A recent code change might look suspicious, but engineers still need to establish whether it caused the failure.
Kosmos designed its new Slack integration to cut down that legwork. It posts the possible connections, along with the evidence behind them, in a shared channel for review. This could reduce the time support staff and engineers spend tracking down information across different tools.
The explanation the team settles on in Slack may remain useful long after the incident is resolved. But how much of that explanation can software establish before a person has to stand behind it?
Different Symptoms Can Lead Back to the Same Failure
When one part of a company’s software infrastructure fails, the effects can show up across several services at once. The thing is, each problem can look unrelated and get noticed by a different group.
On June 12, 2025, Cloudflare suffered an outage that lasted two hours and 28 minutes. It began when a third-party cloud provider failed. The provider hosted storage that Workers KV depended on. When Workers KV stopped responding, the Cloudflare products that rely on it began failing too.
Cloudflare’s published timeline shows how its engineers found the cause. The group behind its WARP app declared an incident at 17:52 UTC, after new devices failed to register. At 18:05, the group running Cloudflare Access, its sign-in service, was alerted to a sharp rise in errors. A minute later, engineers traced the problems to Workers KV and merged the separate incidents into one.
Neither problem explained the outage on its own. Only when engineers connected them did the cause become clear.
Kosmos applies this approach to incident investigations. It compares customer complaints with code changes and system errors, then flags events that may share a cause.
Security investigations face a similar problem when the evidence is spread across different tools and previous cases. DragonClaw brings that information together to reconstruct incidents and explain why it reached a particular conclusion.
Evidence Reaches the Conversation Where Decisions Happen
Kosmos announced its Slack integration on September 14, timed with Dreamforce 2026, Salesforce’s annual conference. When Kosmos detects a potential problem, it posts a summary and supporting evidence to a designated Slack channel. Kosmos calls each flagged issue a “risk event.”
People in that channel can confirm or dismiss the event without leaving Slack, and Kosmos records their decision automatically. If a confirmed event needs a closer look, someone can open a full investigation into its root cause. Kosmos then posts updates and, once it finds the root cause, a summary in the same channel.
There’s another benefit here: the integration also brings more people into the investigation. Salesforce administrators and support staff may spot a problem before the engineers responsible for fixing it. Slack gives both groups a shared place to review the evidence.
In an interview, CEO and founder Sanjay Gidwani described how that conversation could go:
“The support lead can say, ‘That’s what three customers reported Tuesday,’ and the engineer can say, ‘That lines up with the 2 pm deploy.’”
Customer reports help establish when the problem started, while engineering records show what changed around that time. By looking at both, support staff and engineers can assess the evidence before confirming the root cause.
The announcement also introduced Salesforce Error Monitoring, a preview feature that detects failures within Salesforce, including automated workflows that stop working.
Without that visibility, those failures can stay hidden inside Salesforce until a customer runs into the problem they cause. With it, Kosmos can show them next to the related customer cases and code changes.
A Shared Channel Only Works When the Evidence is Strong
If the channel fills with unreliable alerts and guesses about root causes, support staff and engineers could spend more time sorting through them than investigating the actual problem.
Google’s guidance for engineers who keep its systems running explains how that plays out. When alerts arrive too often, people start to skim or ignore them, and a real problem can get lost in the noise.
Financial fraud teams face the same problem with alerts that repeatedly turn out to be harmless. Feedzai’s Farol can identify noisy detection rules and suggest where they may need adjusting, while the fraud team remains responsible for the final change.
Gidwani explained how Kosmos guards against that:
Kosmos compares event timestamps, ticket numbers, and error messages. It also checks whether a code change affected the part of the software that failed and whether the same person made related changes. Taken together, these details help teams assess whether a code change may have caused a problem or simply happened around the same time.
Testing software runs into the same distinction between seeing a failure and explaining it. QA Cafe’s CDRouter records test results, logs, and resource use along the same timeline so engineers can investigate what started changing before a device failed.
An Explanation Should Stay Useful After the Conversation Ends
Once support staff and engineers resolve an incident, they move on to other issues. The problem is that the reasoning behind the fix can get buried in Slack messages or become difficult to find when colleagues change roles.
Kosmos saves confirmed root causes so colleagues investigating future incidents can find them later. Gidwani said the platform stores these records whether someone confirms a root cause in Slack or directly in Kosmos. If a similar problem comes back, the next investigation can start from what people already found.
Google’s guidance on learning from incidents treats that kind of record as essential. At Google, each reviewed incident write-up goes into a shared library other engineers can draw on.
Kosmos also tracks fixes from the initial diagnosis through deployment, while engineers continue using their existing tools to make the repairs.
Gidwani said Kosmos plans to use dismissed events to help each organization fine-tune how the system weighs evidence. In other words, the goal is to make its assessments reflect the judgment of the people using it rather than rely on a generic default.
Faster Software Changes Make Shared Context More Valuable
As companies make software changes more frequently, investigators have more changes and system interactions to examine when something breaks. In Atlassian’s 2026 developer experience research, 87% of developers said AI helps them ship work faster. Yet 72% said they face as much friction in their daily work as before AI, or more.
Finding information remained the biggest source of friction. And during an incident, engineers have to find the relevant evidence quickly.
Gidwani expects AI agents to introduce new challenges as they make changes across enterprise systems. One example is a code commit written by an AI agent and merged overnight without a human author.
An agent’s action in one system could also trigger changes elsewhere. Each step might appear normal on its own, even though the sequence eventually causes a failure.
Gidwani also warns that small changes can accumulate over time and produce problems no one intended. He argues that these patterns are difficult to spot when each system is examined separately. He said:
Human review becomes especially important if AI agents later use these records to make decisions. An incorrect root cause could give an agent misleading information to act on.
A Confirmed Answer Outlasts the Incident
Software can now do much of the legwork in an investigation, from gathering evidence to suggesting a cause. Standing behind the answer is still a human job, and Kosmos treats that as the point rather than a gap.
As AI agents take on more changes, leaders will want to know who approved each explanation and on what evidence. Kosmos is betting that a recorded sign-off gives whoever makes the next decision, person or AI agent, firmer ground to stand on.
