As reported by Elastic Security Labs, the team behind Elastic's internal InfoSec operations recently published a candid technical breakdown of how they reduced LLM calls per alert triage workflow by 60% — from 19 calls down to 8 — across a fleet of 14 production AI agents. This is one of the more instructive pieces of operational AI transparency we've seen from a major security vendor, and there's considerably more to unpack here than prompt engineering tips.

AI Security Alert: As reported by Elastic Security Labs, the team behind Elastic's internal InfoSec operations recently published a candid technical breakdown of how they reduced LLM calls per alert triage workflow by 60% — from 19 calls down to 8 — across a fleet of 14 production AI agents.

Why This Matters Beyond Elastic

Most AI-in-security conversations remain aspirational. Elastic is describing a running production system, and the inefficiencies they found — nearly 2.5x more LLM calls than necessary — are almost certainly present in every organization that has bolted generative AI onto alert pipelines without rigorous optimization. This isn't a fringe edge case; it's the industry norm. The gap between "we deployed AI agents" and "our AI agents are operating efficiently" is where most teams currently sit.

The implications ripple outward in at least three directions:

Why This Matters Beyond Elastic
Cost exposure: At scale, redundant LLM calls translate directly into API spend or compute overhead. A SOC processing tens of thousands of alerts daily with bloated agent workflows could be burning substantial budget on redundant inference cycles that contribute nothing to detection fidelity.
Latency and analyst trust: Slow agents get ignored. If an AI triage agent takes 45 seconds to return a verdict that a tuned agent could produce in 18 seconds, analysts route around it. Optimization is a trust-building exercise as much as a cost one.
Reliability and determinism: Each additional LLM call is another opportunity for hallucination, context drift, or inconsistent output. Fewer calls in a well-structured workflow generally means more predictable, auditable behavior — a non-negotiable requirement in regulated environments.

The Structural Problem With Naive Agentic Architectures

What Elastic's findings implicitly diagnose is a pattern we see frequently: AI agents are often designed by capability first and efficiency last. Teams stand up chains of prompts that work in a demo environment, then ship them without instrumentation. Without measuring call counts, token consumption, and task completion rates per agent, there's no feedback loop — and without a feedback loop, bloat compounds silently.

The difference between a 19-call agent and an 8-call agent isn't just prompt cleverness. It reflects whether the builder had visibility into what the agent was actually doing at each step.
This is fundamentally an observability problem dressed as an AI problem. Organizations that have mature APM and logging practices will adapt to agentic environments faster than those that don't, because the discipline of measuring runtime behavior transfers directly.

Broader Implications for the Agentic SOC Model

The "agentic SOC" is rapidly moving from concept to reality, and Elastic's transparency here is a valuable data point for CISOs evaluating this architectural shift. A few things stand out:

  • Agents require lifecycle management: Just like detection rules, AI agents degrade over time as threat patterns shift and tool integrations change. An optimization loop isn't a one-time project — it's an ongoing operational discipline.
  • Fleet management matters: Running 14 agents with different behaviors and performance profiles requires governance. Which agents are regressing? Which prompts were updated and by whom? Version control and change management for AI agents are nascent practices that security teams need to develop now.
  • Prompt templates are artifacts, not magic: The reusable prompt template Elastic provides is genuinely useful, but organizations should treat it as a starting point for their own structured optimization process — not a universal solution. Your threat model, data schema, and agent tooling will require adaptation.

Shield53 Recommendations

For Security Teams Running or Planning AI Agents

  • Instrument before you optimize: If you don't have per-agent LLM call counts, token usage, and task success metrics, start there. You cannot improve what you cannot measure. Integrate your agent framework with your existing observability stack.
  • Audit your current agents for redundancy: Map out the exact sequence of LLM calls each agent makes and ask: is each call acting on new information or new context? Calls that reprocess the same data are immediate candidates for consolidation.
  • Establish a structured optimization cadence: Treat agent performance reviews the same way you treat detection rule tuning — scheduled, documented, and tied to measurable outcomes. Monthly reviews for high-volume triage agents is a reasonable starting baseline.
  • Apply the principle of least context: Provide agents only the context required for the immediate task. Over-stuffed prompts increase cost, increase latency, and often reduce output quality. Structured, minimal context windows are a discipline worth enforcing from day one.
  • Plan for governance at scale: Before deploying more than a handful of agents, establish who owns prompt versioning, how changes are reviewed, and how regressions are detected. The operational debt of unmanaged agent fleets compounds quickly.

Elastic's willingness to share real operational numbers — including the inefficiencies — is the kind of practitioner transparency the industry needs more of as agentic security architectures become mainstream. The 60% reduction they achieved is attainable for others, but only for teams willing to apply the same measurement discipline that makes traditional security engineering effective.