Agentic alert triage works. Anthropic and Databricks published the staffing bill.

Two credible engineering organizations have now documented internal agentic triage builds. The results validate the architecture. The build details explain why service providers need a different way to get it.

In May, Anthropic's Detection Platform Engineering team published details of CLUE, an internal detection and response platform built on Claude Code. CLUE triages every incoming alert, enriching each one with context from Slack conversations, internal documentation, code repositories, and data warehouses before assigning a disposition and confidence score. In its first 30 days it automated roughly 12,000 queries and 27,000 tool calls, work the team estimates at 1,870 analyst hours, and cut the false positive rate from about 33% to 7%.

This month, Databricks published its own version: 17 source-specific triage agents built on their platform plus a shared threat intelligence agent, running in real time with deterministic filtering in front of every model call. The results track closely. More than 18,000 low-severity alerts triaged at a 3.2 percent escalation rate, agent-escalated alerts roughly 10 times more likely to be true positives than the High and Medium queue, and more than 6,500 analyst hours saved in the first 30 days.

Two teams, working independently, converged on the same design: enrich alerts with environment-specific context before the model reasons, apply deterministic filtering so the model only sees what requires judgment, keep humans reviewing escalations, trace every decision end-to-end, and cap cost at multiple levels. The architecture question is settled. Agentic triage produces real results when it is built this way.

What the results cost to produce

Both posts are equally detailed about the investment behind the numbers, and that detail deserves as much attention as the results.

Databricks built 17 bespoke agents, each tuned to a single detection source with its own false positive patterns and behavioral baselines. Keeping them running required a shared framework for agent invocation, retries, disposition parsing, tool dispatch, token tracking, tracing, and prompt injection detection. Cost control required a custom tracker with per-batch spend caps, a daily ceiling, and per-category tool call budgets. Evaluation required MLflow tracing wired into analyst workflows so every human label becomes ground truth for testing prompt changes before they ship.

CLUE took Anthropic's Detection Platform Engineering team several months to build, on top of their regular workload, and the team writes candidly that the feedback loops for measuring accuracy are still under construction. This is a dedicated engineering function at a frontier AI lab, with unrestricted access to its own models, describing a system that remains a work in progress.

Both systems serve exactly one environment. The Databricks agents encode what abnormal looks like inside Databricks. CLUE's stated differentiator is access to Anthropic's own Slack, documentation, and repositories. Neither system generalizes, and that is by design. Source-specific context is the entire reason the approach works.

Now run the math as a service provider

An MSSP or MDR provider operates this problem multiplied by every customer. Forty tenants means forty sets of alert sources, forty definitions of normal, and forty environments drifting in different directions as customers change tooling, hire, and reorganize. Applied honestly to a service provider, the Databricks architecture means building and maintaining hundreds of source-specific agents and re-tuning them continuously as each tenant drifts.

Anthropic and Databricks each solved one environment with a funded engineering team whose job was the platform. Service providers have analysts and margins. That is the gap both posts leave open: the architecture is validated, and the staffing model behind it is unavailable to almost every organization reading about it.

Grid builds the fleet, then supervises it

Grid is LimaCharlie's agentic SecOps layer, and its core concept absorbs exactly the labor those two teams describe. When you onboard a forward deployed engineer (FDE) in Grid, you are creating an AI agent whose job is to build and supervise the worker agents for a tenant. You describe the outcome and the boundaries. The FDE connects the missing data sources, validates the real shape of the data in that environment, and constructs the solution as a mix of deterministic capabilities and AI reasoning, choosing whichever is cheaper and more reliable for each part of the problem.

The boundaries live in a charter. A maximum spend of two dollars per investigation and two minutes per run are the kind of parameters a charter encodes, which replaces the custom cost tracking layer Databricks had to write. Detection rules and false positive rules handle the predictable volume before any model is invoked, the same filtering discipline Databricks credits with suppressing the majority of alert volume at some sources. Escalations land in LimaCharlie case management for human review, mirrored to ServiceNow or Halo PSA if that is where your analysts already work. The full loop, a detection fires, an agent enriches and correlates, and a structured ticket with a risk verdict lands in a case, is documented end to end in an existing walkthrough built on the same infrastructure.

The two internal builds actually disagree on one point worth noting. Databricks found that tightly scoped, step-by-step agent instructions consistently outperformed broad prompts. Anthropic found that giving Claude tools and a goal, rather than a rigid sequence, surfaced context that prescribed paths would have missed. Both are right for their environments, which means the correct blend of deterministic scoping and agentic latitude is a per-problem engineering decision. In Grid, that decision belongs to the FDE. It picks the mix for each worker it builds and adjusts as false positive feedback accumulates.

The feedback loop itself is where the supervision model separates from both internal builds. Anthropic and Databricks close their loops manually: analysts label, engineers re-tune. In Grid, the feedback goes to the FDE directly. Tell it a specific department keeps triggering false positives and it writes the false positive rules. Tell it the cost ceiling can move and it updates the charter. It checks in on its workers on a schedule, reviews how they are performing, and raises what it finds through cases. One boundary is worth naming directly: both pipelines end where response begins. The Databricks agents filter, enrich, and assign dispositions, and the output is an escalation for a human to act on. CLUE investigates and hands its findings to an analyst the same way. That is the advisory pattern in its most capable form. For Databricks the limit is structural, since a data platform lets an agent read everything and change nothing. Grid workers operate on a SecOps platform, so the same agent that investigates a detection can isolate the endpoint, disable the account, or update the rule that fired, with sensitive actions gated behind human approval and every action governed by the same permission policy that applies to human operators.

What a service provider gets that an internal build never delivers

Everything the FDE builds is LimaCharlie infrastructure as code: inspectable, version-controlled, and portable. That changes what scale looks like. Test a detection change in your internal tenant, and after a day without false positives, push it to every customer. Agent memories are tracked as infrastructure and can move between tenants, so what an agent learns in one environment can seed the next onboarding. Per-model, per-rule, per-agent billing shows the cost of each tenant's automation as line items rather than a blended fee, which matters when automation cost is part of your service margin. Every agent action also surfaces in a readable case record, so the audit trail Databricks assembled from MLflow traces is a place your team can click into and read.

The substrate deserves a mention too. Grid agents run on the Claude Agent SDK, the same foundation Anthropic's own security team chose for CLUE, with your own API keys. LimaCharlie takes no percentage of inference spend and adds no markup on model costs, so you pay raw vendor rates and can negotiate them directly. The token economics stay visible end to end rather than bundled into someone else's per-alert pricing, which matters because a vendor whose revenue scales with token volume has little reason to help you drive that volume down.

Under future work, Anthropic lists proactive hunting and organizational memory built from stored investigations. Both are documented workflows on LimaCharlie today: a daily loop that simulates a kill chain, reviews what was detected, and writes rules against the gaps, and agent memories tracked as infrastructure that carry forward between runs and between tenants.

The two posts settle the question of whether agentic triage works. They also demonstrate what it takes to build and keep running: a dedicated engineering team, a custom framework, and continuous tuning against a single environment. Grid exists so that second part stops being the barrier. Onboard an FDE at grid.limacharlie.io for free and give it an outcome you’re looking for.