You built a search system using the latest, greatest models, and maybe you were thrilled with the outcome. But what happens if the search results were… sort of… bad? Your first instinct might be to invest time and resources in a bigger, better reranker. Maybe you thought, “We just need a better way to bubble the best result to the top of the heap.” That could be true. Or you may need a different approach altogether.

The problem with devoting all your energy toward improving your reranker is twofold. First, large-scale reranking gets expensive fast. It also increases latency as your system meticulously combs through a mountain of candidate results. Second, your reranker can’t surface better results if it never had them to begin with. Before dedicating efforts solely to a better reranker, check whether the right results are making it to your candidate pool and the overall cost of reranking everything. You may want to take a different approach.

Join Vespa.ai on October 13 to learn how to reframe your retrieval process as an efficient funnel instead of one expensive step.

Join the live conversation: On October 13, Vespa.ai’s Director of Product Marketing Bonnie Chase and Senior Principal Solutions Architect Jenny Morris will walk you through creating a multi-stage retrieval process to maximize efficiency while minimizing cost.

Instead of one expensive reranking step, you can think of your retrieval process as a multi-stage funnel. Start with a large corpus of documents and generate a broad pool of candidate results using relatively inexpensive lexical, vector, or hybrid retrieval methods. From there, narrow the pool before passing a select group of likely choices to a more expensive reranking step that involves machine learning inference. This funnel approach provides wider coverage early on while limiting costly operations later in the process.

Of course, several tradeoffs come into play when designing your retrieval funnel. The interplay between recall, relevance, latency, and cost should inform your architecture. For example, retrieving more candidates may improve recall, but it also means you’ll have more results to evaluate and potentially rerank, which could impact cost and latency.

This funnel approach also applies to RAG applications. As RAG systems scale, retrieval becomes even more important to make sure the right information reaches the LLM in the first place. Even after you retrieve the right documents, you still need to decide which passages deserve space in the model’s context window. The same progressive narrowing approach can help there, too.

You can expect to learn about this retrieval funnel approach and much more at the upcoming live webinar, “Why the Best Reranker Can’t Fix Bad Retrieval.” You can ask experts from the Vespa.ai team your own questions, but they’ll also address practical questions such as:

• How many candidates should you carry from one stage to the next?
• When is lexical retrieval enough, and when does a vector or hybrid approach add value?
• How will you know if the expensive reranking is actually improving your results?
• How can this approach extend to RAG for passages to include in your context window?

If you’re ready to rethink your retrieval process or simply want to learn more about modern retrieval architecture, join us on October 13.

The post Think you need a better reranker? Check your retrieval first. appeared first on The New Stack.

With often hundreds of thousands of alerts a day, many tech organizations are buried in vulnerabilities and worn down by alert fatigue. The rise of AI has only made it harder to cut through the noise and to find actionable alerts. Manual security and site reliability engineering is not an option. 

The engineering team behind WHOOP‘s health and fitness tracker felt this pain, relying on multi-day, all-hands triage sessions to stay on top of the alert deluge. But, as a high-growth consumer health company handling sensitive user data, it couldn’t afford to miss anything. Which is why the team at WHOOP built an automated vulnerability-response workflow based on the company’s specific technical, operational, and trust considerations.

Join The New Stack on Wednesday, October 7 to learn from WHOOP staff engineer Vinay Raghu and Datadog senior product engineer Amber Tunnell how WHOOP built and implemented this workflow using Datadog Bits AI and Workflow Automation for faster, at-scale response. 

Join us on October 7, 2026, for a live Datadog x TNS event

DevSecOps, security, and cloud/platform engineers should bring their questions to this live demo-slash-case study to learn how to reduce friction between developer velocity and security requirements without increasing headcount. 

What you’ll take away from our live webinar

Raghu and Tunnell engineers will share how they were able to:

1. Focus on real exposure vs. scanner noise. Not everything is critical. You’ll learn how WHOOP used Datadog’s Software Composition Analysis (SCA) to analyze runtime code execution and prioritize active threats.
2. Route the right vulnerability to the right engineer. WHOOP automated vulnerability mapping to microservice owners, so developers received tickets with full context attached.
3. Build automated guardrails for devs to self-resolve. This let security engineers pivot from frustrating gatekeeping and ticket-pushing to more proactive, systemic work that adds value. 
4. Maintain a human in the loop. With such sensitive data and a demand to be always-on, WHOOP isn’t ready to automate the engineer out. Learn how they decided their team’s response had to change.

And then, of course, we will end the live discussion with how to measure it all. Don’t miss out and register to attend on October 7.

The post Vulnerability alert fatigue nearly swamped WHOOP. But its fix still keeps a human in charge. appeared first on The New Stack.

Security operations centers have struggled with alerts for years, and AI agents offer a new way to tackle it: Enable machines investigate some of those alerts themselves.

That’s already starting to happen: Security teams are experimenting with AI that can pull together signals from different systems, investigate suspicious activity, and recommend next steps to humans in the loop.

There’s an obvious appeal: SOC analysts have finite time and attention, while the volume of potential threats does not come with the same constraint. Attackers are also getting access to AI tools that can accelerate parts of their own operations. Simply giving analysts better ways to work through an ever-growing queue may only get security teams so far.

But moving from AI-assisted security to increasingly autonomous security creates a new problem: How much control are organizations actually prepared to hand over?

That question is at the heart of The New Stack’s AI-Speed SOC CISO Roundtable on September 15, where security leaders will discuss how far to let AI agents go — and when humans need the final say.

There is a big difference between asking an AI agent to investigate a suspicious login and allowing it to disable the account responsible for it. The same goes for isolating an endpoint, blocking network traffic, or making other changes that could immediately impact the business. An autonomous agent could potentially make those decisions much faster and at much greater scale than a human analyst.

The model is only part of the trust equation. Security teams also need to know what an agent is doing, when a human gets the final say and, crucially, whether they can undo a bad decision. That could mean putting some fairly hard limits on autonomy,  including a way to shut the whole thing down if an agent goes off course.

Giving agents more responsibility also changes the role of the people working alongside them. If AI handles a large chunk of routine investigation, analysts could spend less time working through queues and more time threat hunting, making judgment calls and overseeing the agents doing the repetitive work. The SOC analyst starts to look less like an investigator and more like an orchestrator.

Eventually, the bigger change may be to the SOC itself. “Continuous detection and response” has become familiar security language, but AI agents could make it something more literal. Instead of detection, investigation, and response being separate steps, an agent could move between them, with what it learns during one investigation feeding directly into how the next threat is detected.

That starts to look less like AI bolted onto the existing SOC and more like a different operating model altogether. It also presents CISOs with a familiar problem: tooling. Security teams already have sprawling stacks, and vendors are racing to add agents and AI capabilities to them. Organizations risk ending up with another collection of products to manage rather than the continuous system they were promised.

Join us on September 15, 2026

On September 15, I’ll be joined by Jami Hughes, deputy CISO at Zions Bancorporation, and Oren Saban, co-founder and CPO of Mate Security and former Microsoft Defender XDR and Security Copilot product lead, to discuss alert overload, autonomous agents, the future of the SOC analyst, and what continuous security actually looks like.

The session is limited to 20–25 security leaders, with applications reviewed to keep the group small and relevant. This isn’t a traditional webinar with hundreds of people listening in: everyone in the room will be expected to take part. Chatham House Rule will apply throughout, so participants can speak candidly about what’s working, what isn’t, and where they still have concerns.

Apply for a seat at the table

Because if attackers increasingly operate at AI speed, security teams need to work out how much of the response they’re willing to hand to AI, too.

The post How much control should AI get? A CISO roundtable takes on SOC autonomy appeared first on The New Stack.

Ask two experienced engineers about how to handle the flood of AI-generated code in their review queues, and you’ll get two different answers.

The debate remains very much unsettled. And on Tuesday, September 29, two industry leaders will join a live event to hash out what to do.

John Bristowe, Principal Developer Advocate at Octopus Deploy, will join Viktor Farcic, the platform engineering voice behind DevOps Toolkit, for the live conversation we’re calling “Human Review vs. Verified Pipelines: What Catches Bugs in the Age of AI Code.”

Here are the facts: Developers have adopted AI en masse. According to the 2026 DORA report, 90% of developers now use AI at work. The result? Developers are merging 98% more pull requests than they managed in the pre-AI era. 

But all that AI-generated code is leaving a mess. Bugs per developer are up 54%, and one analysis of 10,000 developers found that incidents per pull request have climbed a staggering 243%. Octopus Deploy’s own AI Pulse report found that while AI usage enables faster code creation, it can “degrade overall performance” because coding agents write large code updates that humans struggle to fully understand.

Part of the problem is that developers have adopted automated code generation faster than they have adopted automated code review, effectively moving the human bottleneck further down the software creation chain without removing it entirely. And AI code review may have the same shortcomings as the coding agents.

Bristowe argues that code review has quietly become little more than theater. No human reviewer can quickly audit a 40,000-line, agent-created pull request, since they were not part of the reasoning that produced it and cannot realistically understand everything it may change. 

What does Bristowe recommend? Moving the quality gate off the humans’ desks and into the delivery pipeline itself. Does that mean more AI? Not necessarily, with the developer advocate arguing that building robust “policy-as-code” rules into deployment standards can flag only what goes against those policies. Humans can handle those exceptions, without pretending they are “reviewing” the entire package.

Expect Farcic to press Bristowe on how well a policy-as-code setup can truly absorb judgment, and whether we’re simply creating another accountability sink in software development. The conversation will also explore the plight of the junior engineer, who can no longer expect to join a team of humans writing code that other humans review and discuss.

The debate kicks off at 2:30 p.m. Eastern/11:30 a.m. Pacific on Tuesday, September 29. It’s free to attend, and attendees will receive a companion resource built from Octopus Deploy’s AI Pulse data, available immediately for participants who show up live. Register today.

What you’ll take away:

• Why AI-generated code broke the assumptions code review was built on, and why more review isn’t the fix
• Why using AI to review AI’s own code doesn’t close the gap (same training data, same blind spots)
• How to build a pipeline that verifies every deployment against a defined set of rules, no matter who or what wrote the code
• Where code review still earns its keep, and where it needs to step aside for the pipeline

The post AI broke code review. Two experts disagree on what replaces it. appeared first on The New Stack.

AI agents are multiplying as corporations adopt the technology in record numbers. Smarter underlying models, better tool use, and improved multi-agent collaboration have pushed agents to evolve beyond impressive demos into practical technology that companies marshal in production environments. But the job’s not finished. 

As companies deploy more agents, more often, and against longer tasks, the plumbing that provides their AI ephemera with the required information is buckling.

Here’s the problem: AI agents are sending waves of queries against company data, creating concurrency issues and exposing just how difficult it can be to ensure a company’s AI-legible information is fresh, served only when relevant, and quickly available.

Join the live conversation: On September 24 at 12 p.m. Eastern/9 a.m. Pacific, Whit Walters, Field CTO and Lead Analyst at GigaOm and author of Defeating the Integration Tax report, joins Bonnie Chase, Director of Product Marketing at Vespa.ai, to discuss what happens when retrieval architecture meets that workload.

And crucially, they will explore in this live conversation what changes when a team rebuilds it as a unified layer instead of a fragmented one.

Register for our free event on September 24

You might be asking yourself: How has this problem not been solved yet? Google famously handles tens of thousands of search queries every second; how difficult can it be to serve agents the information that they need when we’ve solved the human version of the same problem? It’s no small challenge, and it’s why retrieval engineering is a labor category you’ll hear more about in coming quarters.

So, why is the problem worse with AI? Agents don’t ask a single question. They may retrieve data, reason against it, and then go back for more context. That doesn’t sound too complicated, until we recall that companies often stitch multiple systems together to provide their agents with required information. In practice, that means fusing vector databases, ranking tools, and serving layers into a single hybrid retrieval system that serves ever more agentic queries.

Worse, when several agents ping the same cobbled-together architecture at once, relevance drift becomes a real issue. You might do all the work to get your company or team up and running with agents, only to see the effort fail because of stale data, generic answers, or even truncated results as retrieval plumbing stumbles.

Your AI agents can’t scale successfully if they get dumber the more agents you deploy. So join the conversation on September 24, where we’ll break down how you can solve your retrieval engineering woes.

What you’ll take away:

• Why agent workloads create a fundamentally different retrieval challenge than added concurrency alone
• The specific failure modes at agent scale — latency stacking, stale context, relevance drift
• Why fragmented retrieval stacks amplify those failures
• What a unified retrieval architecture looks like in practice

The post Want to scale AI agents without breaking anything? Retrieval engineering is the answer. appeared first on The New Stack.