We tested two agentic SOC architectures in parallel across 36,822 real Agent Builder conversations. One won by 5.7x: a specialized workflow triaging alerts for $0.69 each, against $3.42 for a single agent juggling 14 Skills. The data and the decision framework are both below.

Multiple specialized agents versus a single agent with skills

Customer Zero: How Elastic InfoSec runs Agent Builder in its own production SOC

How do you measure per-agent token cost in Agent Builder?

Token cost by investigation route

Inline methodology versus a skill-delegated agent: A matched test

Why does on-demand skill loading cost more at scale?

How to pick your agentic SOC architecture: A decision framework

What Elastic InfoSec runs in production today

Specialized agents versus skills: The bottom line for your agentic SOC

See the data behind a 5.7x cost cut in Elastic's agentic SOC: $0.69 vs $3.42 per alert, from 36,822 real Agent Builder conversations.

Use the `POST /api/agent_builder/agents/{agent_id}/consumption` endpoint with a date range. It returns total conversations, input tokens, output tokens, and a per-model breakdown for the period. For per-route investigation cost in a multi-agent workflow, sum the median token counts for each agent in the route. For a direct comparison against a unified agent, run matched-live tests: the same alert submitted to both architectures, with results recorded separately.

How do I measure how many tokens my Agent Builder agents actually use?

Each skill you invoke adds an LLM call for the file read, plus the skill's content bytes to every subsequent LLM call in that conversation. If your agent invokes three skills in one investigation, it pays three LLM calls just to load the skills before any forensic work starts, and those skill bytes grow the context window for the rest of the run. This is the correct behavior for on-demand flexibility. It becomes expensive only when you run the same skill combination hundreds of times a day on similar alerts.

Why does my single Agent Builder agent with skills cost more tokens than I expected?

Specialized agents for automated, repeatable triage. A skills-based agent for analyst-led interactive investigation where the direction may change mid-conversation. The deciding factor is whether methodology flexibility is a feature (analyst-led) or overhead (automation).

When should I use a single agent with skills versus multiple specialized agents?

Write the investigation methodology directly into the agent's system prompt rather than loading it from a skill at runtime. Inline methodology eliminates the reasoning-only LLM calls the agent spends deciding what to do, which is the primary source of nondeterminism and extra token cost in thin-prompt agents.

How can I make my SOC AI agent investigations reproducible across runs?

No. Skills are designed for on-demand loading, which is the right pattern for interactive analyst use where the agent may need to pivot to unexpected domains mid-investigation. The cost is worth the flexibility. Skills become expensive relative to inline methodology only when you invoke the same skill combination repeatedly in automated workflows where that flexibility isn’t needed.

Are Agent Builder skills inefficient?

With a workflow of specialized agents, we measure approximately 113k–243k tokens per investigation depending on the route: Endpoint Windows at the low end, Higher-Order threshold alerts at the high end. A unified agent with 14 skills ran at 532k–786k tokens across our five observed unified-agent runs, about 3–5.7× more for the same investigation. At EIS rates for Claude Sonnet 4.5, that translates to roughly $0.69–$1.48 per investigation for specialized agents versus $3.42–$3.82 for the unified agent.

How much does an automated alert investigation cost in tokens with Elastic Agent Builder?

Yes. We run the specialized workflow for automated batch triage and make the single agent with skills available for analyst-led interactive investigation. Both use the same Agent Builder deployment and the same EIS connectors. They serve different purposes and can coexist without conflict.

Can I run both architectures at the same time in the same Elastic environment?

Agentic SOC architecture: specialized agents cut costs 5.7×

Inside Elastic InfoSec's agentic SOC: When to inline your agent's skills for a 5× cost reduction

Elastic InfoSec tested this detection rule pattern on their own cloud fleet, filtering noisy curl and wget events with deterministic logic and LLM triage so only genuine threats reach an analyst.

Why curl and wget rules are noisy in cloud environments

How ES|QL COMPLETION filters curl and wget events

Why detection rules should filter by parsed destination, not raw command line

Redact secrets from curl and wget command lines before the LLM sees them

Preventing prompt injection from attacker-controlled command line strings

How to parse and filter ES|QL COMPLETION verdicts by confidence

ES|QL COMPLETION test results: wget rule over seven days

When to use ES|QL COMPLETION for detection triage

Why LLM triage keeps noisy detection rules trustworthy

ES|QL COMPLETION triages noisy curl and wget alerts with an LLM after deterministic filters, so only real threats reach an analyst. Full rule pattern inside.

Filter deterministically first, and then send only the surviving events to ES|QL `COMPLETION` for LLM triage. In our seven-day test, this reduced a noisy `wget` rule to three destinations, all classified false positive or below the confidence threshold, so none reached an analyst.

How do I stop a noisy curl or wget rule from flooding my security operations center (SOC) with false positives?

Cost scales with rows, because ES|QL `COMPLETION` sends one request per row. Aggregate by host and destination and add an explicit `LIMIT` before `COMPLETION` so a rule interval stays bounded, which keeps cost and latency predictable.

How much does it cost to run an LLM inside an ES|QL detection rule?

Use a strict one-line format, such as `verdict=<TP|FP|SUSPICIOUS> confidence=<0.0-1.0> summary=<reason>`. This lets ES|QL parse the response with `DISSECT`, filter by verdict and confidence, and store the result in alert fields.

What should the LLM return to the detection rule?

No. Allow-lists still remove known-good activity at low cost. ES|QL `COMPLETION` belongs after those filters, where the remaining events need contextual judgment that would otherwise require more exceptions or analyst review.

Does LLM triage replace allow-lists for noisy detection rules?

The main risks are cost, latency, prompt injection, inconsistent model output, and over-trusting the model's verdict. Reduce those risks by filtering first, limiting ES|QL `COMPLETION` row count, redacting secrets, treating command text as untrusted data, forcing structured output, and requiring analyst verification.

What are the main risks of using LLMs in detection rules?

Yes. The exact allow-list will be different, but the ES|QL `COMPLETION` rule shape is portable: select the behavior, parse the destination, filter known-good activity, redact sensitive fields, aggregate the survivors, parse the verdict, and alert only on results worth reviewing.

Can this pattern work outside Elastic's environment?

ES|QL COMPLETION: LLM triage for noisy detection rules

How Elasticsearch ES|QL COMPLETION turns noisy curl and wget rules into high-fidelity cloud security alerts

Elastic's InfoSec team built AI agents on Elastic Workflows that investigate every alert and assemble the case before an analyst ever opens it.

Alert triage with Workflows and ES|QL: closing alerts without AI

ES|QL enrichment: building the shared alert context every agent reads

The Initial Triage agent: automated alert triage in under a minute

Verdict: True Positive | Assessment: suspicious | Confidence: high

Opening a Kibana case and dispatching the Specialized agents

MacOS Forensics agent: an example investigation

The Final Review agent: the final alert triage checkpoint

Verdict: True Positive | Assessment: malicious | Confidence: high

What the analyst sees after automated alert triage

How to build an alert triage pipeline in your environment

Alert triage in under 3 minutes: the bottom line

Find out how Elastic's InfoSec team automates alert triage with Elastic Workflows and AI agents, cutting investigations from 30 minutes to under 3.

Alert fatigue comes from analysts spending time on alerts that turn out to be false positives. The most direct fix is automating the investigation steps that don't require human judgment: enrichment queries, infrastructure checks, and initial triage. When false positives close automatically and analysts only see alerts with a full investigation already assembled, the cognitive load drops significantly. This is the core design goal of the agentic SOC pattern.

How do you reduce alert fatigue in a SOC without hiring more analysts?

When using the Elastic Inference Service, inference requests are routed to trusted third-party model providers that operate with zero data retention and do not use inputs to train models. Per-model status is documented on the [EIS supported-models page](https://www.elastic.co/docs/explore-analyze/elastic-inference/eis-supported-models). For organizations with stricter requirements, the same pipeline can run against a model hosted on your own infrastructure, keeping all data and inference within your own network.

Is it safe to send security alert data to an AI system for triage?

A single broad agent has to decide at runtime what to investigate for each alert type, which adds cost and produces inconsistent investigation depth across different domains. Specialized agents with a fixed methodology produce consistent results at predictable token cost. A macOS forensics agent, for example, always follows the same process tree and ancestry trace steps. A broad agent is the right tool for analyst-led interactive investigation. For automated pipelines running hundreds of times a day, specialization produces better results.

Why use multiple specialized AI agents for alert triage instead of one general-purpose agent?

An experienced analyst investigating a complex alert manually typically spends 30 minutes or more gathering context before making a verdict. The automated pipeline described here completes the same investigation in a few minutes, including enrichment across more than 20 data sources, Initial Triage, Specialized agent forensic investigation per domain, and a Final Review synthesis report. High-confidence false positives close automatically at around 50,000 tokens with no analyst involvement.

How much faster is automated alert triage compared to manual investigation?

Yes. The pipeline can be configured to use a model hosted on your own infrastructure, keeping all data and inference within your own network. This is suitable for airgapped environments or organizations with strict data residency requirements. The Elastic Inference Service supports both cloud-hosted and self-managed model endpoints.

Can I run automated alert triage without sending data to a cloud AI service?

AI triage is only as good as the enrichment data it receives. Tag-based triage routing depends on detection engineers keeping rule tags current. A rule without the correct triage tag will skip some checks. Threshold alerts require a dedicated enrichment path because they lack the raw event fields that standard enrichment queries rely on. The system can also miss edge cases that a human analyst would catch through contextual judgment, so every automated closure should leave an auditable trail.

What are the main limitations of AI-based alert triage?

Every automated closure leaves a tagged audit trail: a reason code (Closed: Infra IP, Closed: New Employee, or the Initial Triage / Final Review verdict) and a timeline note on the alert. Analysts can review any closed alert and its reasoning at any time. The three-tier architecture adds multiple checkpoints: the Initial Triage agent only closes high-confidence false positives, and the Final Review agent only closes cases after reviewing all Specialized agent findings, which reduces the chance of a true positive being auto-closed. All tags are searchable and can be used to generate metrics and alerting.

What happens when the automated triage pipeline closes an alert incorrectly?

Alert triage in under 3 minutes with Elastic's agentic SOC

Inside Elastic InfoSec's agentic SOC: cutting alert triage from 30 minutes to under 3

This article details the internal Elastic Infosec team's process to optimize our endpoint data collection using Event Filtering and Advanced Policy Settings in Elastic Defend.

The environment: Worldwide Distributed Workforce

Step 1: Identifying the Noise

Step 2: Precise Event Filtering

Filter example 1: Elasticsearch file noise

Filter example 2: Linux Logfile modifications

Step 3: Optimizing Performance at the Source

Event Aggregation

Results

Conclusion

How Elastic Infosec Optimizes Defend for Cost and Performance

Learn how to automate detection rule tuning requests in Elastic Security. This guide shows how to add custom fields to Cases, create a rule to detect tuning needs, and use a webhook to create a frictionless feedback loop between analysts and detection engineers.

Author

Aaron Jewitt

Articles

Inside Elastic InfoSec's agentic SOC: When to inline your agent's skills for a 5× cost reduction

How Elasticsearch ES|QL COMPLETION turns noisy curl and wget rules into high-fidelity cloud security alerts

Inside Elastic InfoSec's agentic SOC: cutting alert triage from 30 minutes to under 3

How Elastic Infosec Optimizes Defend for Cost and Performance

Automating detection tuning requests with Kibana cases