Deep Hat Sift makes skipping an agent run a decision someone must approve

An operations agent can do an excellent job reviewing an alert and still spend most of its day concluding that nothing needs to happen. At enough volume, those correct but uneventful runs become a system-design problem.

Kindo announced Deep Hat Sift on October 28, 2026, a System One decision model that learns from an agent's verdicts and scores which incoming events deserve a run. It begins in shadow mode, passing everything through, and only starts withholding after a person approves the threshold. Kindo's announcement.

The interesting part is the approval around an absence: a run that never starts. This guide explains that decision, compares it with simpler cost controls, and outlines a pilot that measures the important misses alongside the calls avoided.

University of Maryland’s physical-security monitoring center, published in 2008. Historical alert-monitoring context; this does not show Kindo, Sift or a cybersecurity dashboard. Photo: UMD-Eskin, public domain; resized with margins. Image source · License and image notes. Official product reference.

Saving a run changes what the system gets to observe

When every event reaches an agent, the system can inspect every verdict. Once a filter begins withholding events, that simple feedback path changes. The events judged least interesting become the ones that no longer receive the agent's full attention.

This makes filtering different from choosing a cheaper model for the same request. A cheaper model still produces a result for each event. A withholding decision removes an execution from the ordinary path. The measurement plan must account for that missing result.

Our take: skipping is a product behavior with its own owner. Someone must decide what evidence makes it acceptable, which kinds of event remain protected, and what happens when the source changes. Treating it as an invisible optimization makes those decisions harder to review.

Think of the filter as a dispatch desk. Its useful job is to send the right work onward while keeping a record of what stayed behind. The quality of that dispatch matters because the downstream specialist cannot investigate something it never receives.

For a pilot, define the agent's job before defining the filter's success. Does the agent identify incidents, request more context, route tickets or prepare an investigation? “Needs a run” should correspond to that job. Otherwise, a model can learn a consistent decision that does not match the team's operational purpose.

Original explanation of the shadow-to-approval workflow described in Kindo's announcement. It is a simplified operating view, rather than a deployment diagram.

Shadow mode creates a comparison before it changes delivery

Kindo's October 28 release describes an initial observation period in which Sift scores events while all of them still reach the target agent. It then previews proposed withholding against that source's results; approval includes a written reason, and a random sample continues through after activation to expose misses. Announced operating method.

That order gives an operations team a useful counterfactual. Before changing delivery, it can ask which historical runs would have disappeared at a proposed operating point. The question is concrete enough to review with the people responsible for the source and the agent.

The preview should include examples as well as an aggregate. A large group of routine events can dominate a headline rate, while a small but important category behaves badly. Ask the approver to inspect events whose omission would be costly and events that sit near the proposed boundary.

The duration of observation should follow coverage. A busy weekday can look different from a weekend, a release day or an unusual incident. A calendar period is useful only if it contains the conditions that matter to the decision. Avoid treating a certain number of quiet days as a universal readiness signal.

Approval should name the intended operating condition. A record such as “approved for this source and agent, with these exclusions and this review interval” is more useful than a bare yes. It gives the team something to revisit when the source schema, agent prompt or operational priorities change.

Three illustrative queues require different kinds of caution

A repeated infrastructure alert can be a good bounded starting point

Imagine an SRE queue receiving many repetitions of a known notification during routine maintenance. The team already understands the source and has a documented route for urgent exceptions. A pilot could examine whether an agent is repeatedly spending time reaching the same no-action verdict.

Begin by separating known duplicate handling from the new decision. If a simple correlation rule already collapses identical events, retain that baseline. Use the model evaluation to examine the remaining variation that makes a full agent run expensive or unnecessary.

During shadow observation, compare proposed skips with what the agent actually did. Look for changes in severity, affected service or context that make a superficially similar event different. The useful question is whether the filter preserves the distinctions that operations already considers important.

An illustrative success criterion might require a specified review rate and no missed events in a protected category during the evaluation. Those conditions are chosen by the team; they are not universal Sift guarantees. The exercise should produce a clear decision about one source rather than an immediate organization-wide rollout.

A phishing-report queue makes the cost of a miss more visible

Consider an illustrative security team whose employees report suspicious messages. Many reports may require no further action, but a rare actionable message can matter disproportionately. The filter's economics depend on that asymmetry.

For this source, inspect examples that resemble ordinary correspondence while containing the signs the team cares about. Keep the downstream security tools and incident process in place. A filter in front of an AI agent should be evaluated for that routing decision, rather than treated as the entire detection program.

The evaluation should involve the analysts who understand the consequences of a missed investigation. A finance stakeholder can help quantify run cost, but cannot alone define acceptable incident coverage. The threshold is a shared operating choice whose approval needs the right expertise.

Also review the agent's own mistakes. Learning to predict an agent's dismissal can reproduce an agent's blind spot. A separate analyst-reviewed set can reveal cases where the agent and filter agree with each other while both disagree with the team's desired outcome.

A ticket queue needs a definition of useful action

In an illustrative service desk, a ticket may look routine but still require acknowledgement, a service-level timer or a routing step. “No investigation required” and “no agent run required” may therefore be different labels. Define exactly what a withheld execution is allowed to omit.

Keep mandatory workflow actions outside an ambiguous decision where necessary. For example, the ticketing system can retain responsibility for required receipts while the model helps decide whether a particular investigative agent should run. That makes the boundary easier to explain.

Test tickets from different teams, languages and request types. A filter trained mostly on one department's routine requests can be poorly matched to another department's escalation patterns. Source-specific evaluation is more useful than assuming that volume alone makes two queues equivalent.

For this pilot, the output may be a cleaner investigation queue rather than fewer tickets. Measure the human handoff and the time to the next meaningful action. That keeps the evaluation connected to service quality rather than a narrow count of model calls.

Four cost controls answer different questions

The following comparison describes design choices a team can evaluate. It does not claim that a particular vendor implementation wins every category. Several controls may belong in the same system because they operate at different points.

This comparison starts with the decision, which helps avoid double-counting savings. If a correlation rule already removes a repeated event, the filter cannot also claim to have prevented the same downstream run. Define the baseline after existing controls, then calculate incremental effects.

Include the filter's own operating cost. Hosting, monitoring, sampled runs and human review all belong in the pilot's accounting. A smaller bill for one provider endpoint is useful, but it is only one component of the complete workflow.

Quality belongs in the same conversation as cost. A threshold that saves many calls while hiding useful work has changed the service. The team should be able to explain that tradeoff in the language of its actual queue, rather than a single generic accuracy percentage.

Use the sampled misses to ask better questions

Kindo's FAQ, checked November 2, describes a default 3% leak-through sample, configurable from 1% to 5%, and an initial default label floor of 400 verdicts. It says drift or a breached trigger ceiling returns the system to shadow behavior. These are published operating defaults, rather than a guarantee of sufficient evidence for every workload.

An illustrative calculation shows why sample coverage matters. Suppose 10,000 events would be withheld and 3% are sampled; that produces about 300 sampled events. If important cases are rare, the team still needs to examine whether the sample represents the categories whose misses would matter. This arithmetic illustrates the sampling question and does not estimate Sift's actual error rate.

Report at least two denominators in your own evaluation. One describes actionable events that the filter would miss. Another describes the share of withheld events later judged actionable. These answer different operational questions: coverage of important work and contamination of the skipped set.

Inspect slices by source type, severity, team and changing input format where those are relevant. An aggregate can improve while a small category degrades. The categories should reflect the operation's risks and workload, rather than whatever grouping makes the chart easiest to draw.

Finally, keep the agent's verdict separate from an independently reviewed outcome. Agreement with the agent measures how well Sift predicts that agent. It does not, by itself, establish that the agent's judgment was correct. Both measures can be useful when their meanings remain explicit.

Original decision-review aid. It illustrates what an operator should compare and contains no measured savings or accuracy values. Sampling and approval are documented on Kindo's product page.

The current deployment has limits a pilot must include

As of November 2, Kindo describes Sift as a self-hosted service for Kindo agents. Its FAQ lists a single-host Docker Compose deployment, no clustering or failover, and local accounts without SSO or MFA. There is no separate Sift free trial or usage tier. Current-release FAQ.

Those conditions affect where a pilot fits. Review the deployment boundary with the people responsible for identity, availability and incident response. A successful scoring demonstration cannot answer whether the service fits the organization's operational requirements.

1. Name one source, agent and decision owner. Write what the agent does and what a skipped run would omit. Retain existing detection and ticketing responsibilities.
2. Review the current deployment requirements with Kindo. Confirm the available hosting arrangement and the operational support your team would own.
3. Define an approved baseline. Include existing rules, correlation and model routing so the pilot measures incremental value.
4. Begin in shadow mode. Collect representative verdicts and inspect proposed withholding across important categories before changing delivery.
5. Review errors independently. Include analyst-reviewed examples and protected cases, rather than relying entirely on agreement with the target agent.
6. Approve a specific operating point and reason. Record the scope, reviewer, sampling plan and conditions that require another review.
7. Exercise the return-to-shadow path. Confirm what operators see and how the full stream reaches the agent again. Keep cost, quality and availability in the final assessment.

The result should be a bounded operating decision with an owner. If the pilot reveals an uncertain category, keeping it on the full-analysis path is a useful outcome. The point is to learn where withholding is justified, not to maximize skipped events at the first opportunity.

An avoided call is valuable when you can explain the work it did not hide

Sift brings an important question into the agent workflow: which events deserve a full execution, and who is responsible for that boundary? Its shadow-first approach gives teams a place to examine the decision before using it to change delivery.

The durable measure is whether the operation can show the runs saved, the misses observed and the reason the current threshold remains appropriate. That is what turns an absence of activity into a decision someone can stand behind.

Sources

• Kindo's Deep Hat Sift announcement, distributed through PR Newswire, October 28, 2026, 09:00 ET.
• Kindo: Deep Hat Sift product details and current-release FAQ, checked November 2, 2026.

Preserve the material behind a decision

Telli.sh is one option for keeping authorized source material alongside the notes you have reviewed. Create a note workspace.