Lumi Lounge Recap: 3 Takeaways from Splunk .conf26

Sep 24, 2026
Matt Morrissey

The Imply Lumi Lounge sat directly across the street from Splunk .conf26 and reached venue capacity on both days. Digital signs around the Colorado Convention Center pointed attendees our way with a simple message: “Federated search, done right. Full SPL. Less spend.”

Our team spoke with hundreds of Splunk users, security leaders and technology partners. One question came up again and again: How can we search more of our security data without moving it all into Splunk or giving up the workflows our teams depend on?

The timing mattered. Lumi Loglake became generally available just days before Splunk introduced Machine Data Lake and expanded Federated Search, giving attendees the opportunity to compare two approaches to the same problem side by side.

Here are my three biggest takeaways.

1. The economics of security data require a new architecture

Splunk was candid about a problem its customers already know well: There is a practical limit to how much data they can afford to ingest and retain.

In a .conf26 blog, Mangesh Pimpalkhare, senior vice president and general manager of the Splunk Platform, wrote that the traditional model of moving massive datasets into one centralized repository “is breaking.” He described it as slow and cost-prohibitive.

That validates the architectural shift already taking place across the security market. Teams need a more economical place to retain growing volumes of data, and that data has to remain available whenever an analyst or AI agent needs it. Getting there is the harder part, because search-in-place is not a new promise. What separates the approaches is how much work the data needs before analysts, detections and agents can use it.  And that’s where Machine Data Lake and Loglake take different approaches.

Imply Chief Architect Eric Tschetter showed the Loglake approach in our opening session, “Federated Search Done Right.” Working from the Splunk dashboard, where Lumi operates as a federated provider, he used standard SPL to query more than 200 million lines of nested JSON stored in Amazon S3. There was nothing to define, catalog or rehydrate before the search began.

Loglake lets teams search logs where they already live in their data lake and get results back as native Splunk events. They can continue using their existing dashboards, alerts, detections and Splunk applications while making more of their history searchable.

Splunk’s Machine Data Lake takes a different path. Supported data is routed into raw tables and discovered through Splunk’s Catalog. Teams promote selected data into a Splunk index or analytics table when they need it for dashboards, alerting or other analytics.

Teams with logs already in their own data lake should ask whether they search those logs now, or have to move them into a new data path?

2. Teams want to keep Splunk, not start over

In our conversations at the Lounge, Splunk customers made it clear they are not looking to throw away the workflows they have spent years building.  They want to keep SPL, dashboards, alerts, and detections, with a better economic model underneath them.

BTG Pactual has already put that model into production.

During our customer fireside chat, Victória Mai, a cybersecurity engineer at BTG Pactual, explained how one of Latin America’s largest investment banks expanded its security operations without leaving Splunk.  She said the idea of expanding coverage while reducing costs initially sounded too good to be true.

 

From the analysts’ perspective, very little changed. They kept searching from the Splunk interface with the same SPL, and their data models and dashboards kept working without being rewritten, even as the scope of what the team could take on grew dramatically.

BTG extended searchable retention from 90 days to one year and added more than 45 data sources. It also brought seven additional companies from the BTG group into its SOC, which now supports more than 15 business units and group companies and processes more than 17 terabytes of additional data per day.

At the same time, BTG reduced its security data costs by more than 70%.

As Victória put it, “everyone assumes that greater coverage means higher costs. With the hybrid architecture, Splunk plus Lumi, it wasn’t like that. The conversation moved from ‘Do we have the budget for that?’ to ‘What can we do to enhance security?’”

3. The agentic SOC starts with the data layer

AI and agents were everywhere at .conf26. Splunk introduced new capabilities for its Agentic SOC, and speaker after speaker described a future in which humans and agents work together to detect, investigate and respond to threats.

The question that received less attention may matter more than which agent a security team chooses: Can that agent search the data it needs?

Imply co-founder and CTO Gian Merlino closed our program with a session on what comes next for security analytics in an agentic SOC. His central point was that agents do not query like detections do.

Scheduled detections typically examine recent data using predictable queries and known lookback periods. Teams know when those searches will run, what data they will touch and how much compute they are likely to need.

Agents follow the evidence instead.

A possible malicious login might lead an agent to investigate the user, device, IP address and similar activity across weeks, months or even years of history. Every answer raises another question, and one alert can produce dozens of searches that nobody could have anticipated in advance.

That makes historical access more important. Much of the context an agent needs is in logs that organizations cannot afford to keep in their SIEM. If those logs are in a data lake but difficult to search, the agent still cannot use them during an investigation.

Gian demonstrated the idea using an experimental AI SOC that an Imply engineer built in a single day.  The agent itself mattered less than what it could do once it had access to more of the organization’s security history through the data layer underneath them.

Your data architecture determines which questions analysts and agents can ask during an investigation. If cost has already forced you to discard the relevant history, even the smartest agent cannot recover that missing context.

The big picture

Splunk spent .conf26 telling customers that the old model of centralizing security data is breaking.  Most of the people who crossed the street to the Lounge already knew it. They wanted to know if they could make more of their data searchable without giving up the Splunk workflows they depend on.

BTG Pactual’s answer was yes. It kept Splunk, extended searchable retention to one year and reduced its security data costs by more than 70% by changing the architecture underneath it.

See you next year at the Lumi Lounge.

Want to see Loglake in action? 

Learn more about Lumi Loglake or request a demo.

Other blogs you might find interesting

No records found...
Sep 13, 2026

Lumi Loglake is now generally available in Imply Lumi

Search unstructured logs in place in your data lake

Learn More
Jul 24, 2026

Why You Shouldn’t Have to Delete Your VPC Flow Logs

When a security incident happens, investigators almost always start with the same questions: Which systems communicated? Where did the traffic originate? What changed before the incident? Was data exfiltrated?...

Learn More

Ready to change the engine beneath your SIEM?
No workflow changes. No migrations. More data, less spend.

Request a Demo