Agentic Feature Engineering: Cutting Cycles by 60% with AI Agents

Summary

McAfee built an autonomous feature engineering agent on Databricks Agent Bricks that cuts ML engineering cycles by 60%, directly addressing the bottleneck where data science teams spend 60–80% of their time manually engineering and validating features.
The three-phase architecture uses a discovery agent to profile data and route tasks to parallel specialist agents for subscription, device, and behavioral signals, followed by a validation layer that tests candidate features against real model performance before promotion to the feature store.
McAfee generated 54 million dollars in incremental revenue over five years through AI-assisted and agentic feature stores powering propensity and pricing models, with MLflow tracking every iteration and Unity Catalog governing the feature store.

Agentic Feature Engineering: Cutting Cycles by 60% with AI Agents

Feature engineering remains the biggest bottleneck in ML production, consuming 60-80% of data science team time. McAfee faced this challenge head-on: manual feature exploration, validation, and testing cycles were slowing innovation on propensity and pricing models. To accelerate time-to-value, they built an autonomous feature engineering agent on Databricks Agent Bricks that cuts engineering cycles by 60%.
Discover the three-phase agentic architecture: a discovery agent that profiles data and routes work to specialist agents, parallel feature miners for subscription, device, and behavioral signals, and a validation layer that tests features against real model performance. Learn how MLflow tracks every iteration, Unity Catalog governs the feature store, and Databricks managed agents provide enterprise-grade infrastructure. See the framework that's reproducible across industries, and how McAfee generated 54 million dollars in incremental revenue over 5 years with AI-assisted and agentic feature stores.
🤝

Chapters

FAQs

What is agentic feature engineering?

Agentic feature engineering uses autonomous AI agents to automate the discovery, creation, validation, and promotion of features for machine learning models, replacing the manual work that typically consumes 60–80% of data science team time. McAfee's implementation uses a three-phase architecture: a discovery agent that profiles data, parallel specialist agents that mine features by domain, and a validation layer that tests features against real production model performance thresholds.

How does McAfee's three-phase agentic architecture work?

The discovery agent analyzes available Unity Catalog tables, builds a data profile, and routes feature generation tasks to specialist agents aligned to domains like subscription data, device data, and behavioral signals. Each specialist agent mines its domain in parallel, then the validation layer tests all candidate features against production accuracy and precision thresholds before any feature is promoted to the shared feature store.

How does MLflow support the agentic feature engineering workflow at McAfee?

MLflow tracks every feature generation iteration, recording which agent produced each feature, what data it was derived from, and how it performed against validation thresholds. This lineage is essential for diagnosing when schema drift or data migration degrades a feature, because the team can trace the issue back to its origin without manual investigation across multiple pipeline stages.

What business impact did McAfee achieve with AI-assisted feature stores?

McAfee generated 54 million dollars in incremental revenue over five years by using AI-assisted and agentic feature stores to improve the accuracy of propensity and pricing models for personalized offers, churn prevention, and customer lifecycle engagement. The automation also freed applied science teams from repetitive engineering work, accelerating the delivery of new model iterations.

Full transcript

[00:09] So, today I'm going to share some harsh truths about feature stores and feature engineering in general. And the good news is that I'm going to show you some ways to navigate those challenges that we have in in the world of feature engineering.
[00:24] Good afternoon, everyone. I'm Arun Barathi. I'm the senior applied science manager at McAfee. I have been leading ML teams and shipping personalization solutions for more than a decade. And at McAfee
[00:40] specifically, we have been transforming personalization using various propensity-based and pricing-based ML models where we provide various personalized offers to users. We intervene for the churn
[00:56] churn prevention and various other customer life cycle engagement initiatives. To to call this I would like to call this first this session as the first step towards agentic ML. There is a reason
[01:11] that why I call this because you would you would see in the upcoming slides where we are moving and what's the gap that we have in terms of feature engineering in production. So, let's talk about the feature engineering problem, right? I feel
[01:27] or most of the researchers in this even in the year of 2026 feel modeling could be solved, but features aren't. And you will see why, right? The first thing to start with is the bottleneck. We talk about the time that we invest in
[01:44] feature engineering around maybe even 60 to 70% or in some cases 80% of the time applied science teams spend in engineering the features that they would need. And if there is a duplication or any schema drift that occurs or any
[02:00] migration in terms of data set occurs, then it again it takes weeks for us to process those changes to kind of test and validate those those feature catalogs into the model pipelines and check the check whether it breach it breaches the
[02:16] thresholds of our accuracy and precision that we have in our production systems. And moving into the reality, the manual feature engineering reality that we had at McAfee or we have at McAfee partially is we have let's talk about the bronze and
[02:32] silver layers, right? So, you have these Unity catalog tables. At McAfee in our context, we have device dimension, we have heartbeat events, we have messaging and email data, we have product feature usage, we have subscription data. So, all these
[02:49] accumulate a lot of columns and we would need to say if we are designing for 10 feature category plan. So, when I say feature category, like the messaging engagement is one category. And the device profile is one category.
[03:07] They can be owning high-end devices, they can be owning basic laptops. So, as per the categories that we have, we might need to run the feature this entire manual process of exploration. We need to explore the schemas. We need to
[03:23] develop and write SQLs. We need to test functions. And then we need to validate them. We need to check for nulls, sparsity, cardinality. We need to then materialize these tables as feature stores in Databricks. So, this has been the case, right? Like
[03:40] mostly most of the companies, we have been doing feature engineering this way. And through this approach, we have developed around 1.5k features surrounding the customers. So, both across OE like we call it as trial user base and retention or the paid user base. So,
[03:57] McAfee has both environments where we serve for both like expiry trial audience where you have a lot of users who are who have the trial app installed and they're trying to convert and you have paid group where they pay for our subscription and
[04:15] whether we need to look into upselling the package or like in some cases cross-selling some package or enhancing their production and all those things. So, this would take weeks of exploration and in case like months of deployment and we have to
[04:32] also do this parallelly this feature ideation amidst various deliverables that we would be having. So, a recent research shows us the opportunity and hope of where we need to move or take feature engineering into,
[04:47] right? How many here knew the Tab Arena benchmarks? Uh great. So, for others who who might be new to this, so Tab Arena is an open-source benchmark where
[05:03] where various researchers and various like models are tested against established data sets and they score and they kind of test the performance of each models or algorithms. There is a new paper that has been released called Tab Prep this year which
[05:19] showcases that automated feature engineering is so unexplored in this research space and most of the research has been done in algorithmic optimization and hyperparameter tuning.
[05:35] And Tab Prep just worked on some automatic feature I mean automated feature engineering which is nothing but pure mathematics. They are not using LLMs, they are not using any context engines or agents or nothing. Pure mathematical combinations and
[05:50] statistical loops that creates feature augmentation. And if if you could see in every other benchmark, they have showcased that they could beat the existing benchmarks in Tab Arena. Which is an I would say in the field of
[06:06] feature engineering, this should be an important paper that everybody should look at. Why we get the hope and also the gap that the industry still face we need to invest a lot in more automated not just automated, but
[06:21] also intelligent feature engineering. So here today, I'm going to show you how we can take our first step towards that. And hope you guys can learn and also kind of discuss more and keep this conversation going in in the field of feature
[06:37] engineering. So when we move into agentic feature feature engineering, we need to have three core modules in our mind that mostly like we should like everyone would be aware of here when when we start building multi-agent architectures. The first is the context layer, right? So this is where I think
[06:54] we should profile the data, we should we should perform schema scans, sparsity checks, uh entity relationship between tables and all those things. The next is a feature miner context, right? This uh module This module is I would say the most important
[07:10] module of uh agentic feature engineering workflows. So you need to discover device-based, temporal-based, session-based, behavioral-based interaction between two different dimensions need to be researched or
[07:26] mined here. And what not? It's It's going to be really good if you try to link this in an LLM reasoning format and not just about human intuition format. So the third one
[07:42] is the selection and iteration. Say that you've built your context layer, you're mined for your features, but you need to select which one makes the cut, which one needs to be in production, which one needs to be pruned, or which one needs to be added to the backlog. So, be So, maybe a new use case uh the marketing
[07:59] team could come up with a new use case in 6 months for that use case, those backlogged features can be reused and retested. So, let's first start with the solution. This is an end-to-end uh architecture a base architecture framework that we would need to build
[08:17] agentic feature engineering. And when I say this is not tied to one particular use case, you would see why. So, this is not just tied to McAfee's use case. Th- This is an actually an repeatable framework that we could kind of deploy and explore in various domains. But,
[08:33] let's first start with what we uh what we see in this architecture. I'm going to deep dive and zoom in into specific components slowly. Let's first start with um the mission brief, right? The mission brief has say, for example, how many feature categories you would need.
[08:49] And how many tables do you have? Five bronze or three silver? How many columns do they have? Like So, this this is actually the corpus. You you feed in all your Confluence documents about your the metadata that you have regarding those tables and data dictionary,
[09:06] whatever dimensions, the context that you would need should be fed into this mission brief. And then we move into the discovery agent phase. This is the phase one is most important phase where this the discovery agent scouts for tables, maps categories
[09:22] to tables, and routes various work to the specialist agents that we need to spin up. And in our case, we have taken four specialist agents. And the thing about these specialist agents is that they need to work in parallel. They
[09:38] don't need to work sequentially. The reason is these agents are designed in a way that you might need to focus on one set of tables. These like for example, let's take a subscription specialist. It's going to mine for subscription related features like time
[09:54] to paid, what acquisition channel the user came through, what's the payment funnel, the device detail specialist, RAM size, the disk, the processor size. The product usage, message behavior. So all these agents, right? All these features can be grouped to one set of
[10:11] master tables. So you don't need to do multiple scans that we need to hop through multiple tables in a duplicated manner. If you can group these specialist agents based on the core table that they are mining from,
[10:26] then it becomes easy in a parallel uh parallel processing perspective. Then we move on to the synthesis specialist. So the reason why I call this as synthesis is once you have parallelly created these specialist tables, you need to combine them or you
[10:42] need to create interaction terms between them and this is going to be the core piece of creating the final cut of the feature store draft. Then we'll enter into the phase of validation where you need a critic to look into the various temporal leakages you could have, various uh label
[10:59] leakages that you could have. So the all this validation check should happen in the phase three. And the phase four is about performing sample training. We don't have to perform the whole data training, but it's going to be a sample training where you take a 10 to 20% of your your
[11:16] training data and you create samples and you train your model and you log those benchmarks. The next is evaluation where you perform feature importance, you rank those features and you get to know what features to prune, what features move
[11:32] the needle in terms of the objective function that you are solving for. And last comes the materialization phase, where you materialize these and ship as feature tables. So, now, taking a pause, I would like to first move on to the discovery agent
[11:49] because this is really important in terms of how do you establish this, right? So, say that the mission brief has the number of source tables, the uh the objective function that you need to solve for. In our case, it could be conversion propensity or renewal
[12:05] propensity. And then, you have uh the discovery agent spinning off some simple UC catalog methods. So, what you got to check for is exploring the table, you need to profile the columns, you need to check the join quality, you need
[12:21] to query the data to get a sample of this. So, this is more like an hypothesis-driven framework and not more like a schema-driven framework. So, whatever it that you do in terms of manual exploration can be automated in a way that you expose this to an LLM reasoning
[12:38] at standpoint and try to create these join mappings for these tables. So, then you get an output as a discovery brief, where it it has a table inventory, it has a join map, and then you have like how do you route these tables uh to the
[12:54] specialist agents. And the discovery agent is a phase where you even decide how many specialist agent you would need for your own use case. And in our case, this we like we could tackle this with four different specialist agents at that I have already
[13:11] mentioned to you, but to kind of zoom in, you could see we have a subscription agent, where that going to mine for subscription-related information, like how the time to paid, the days to paid, the registration type, the click source
[13:26] the user came in, the paid what what type of subscription they are, and all those things. And then in our case we have a device agent where you could have an unified uh perspective of what device the users are using. So, for example, the RAM size, the CPU size, and the demography
[13:43] from which the device was activated, uh and and all those things. And then the usage agent that that shows about how they use McAfee as a product, right? Uh what is the scan count, the threat detection, the feature usage. So, we have an um daily snapshot table that we
[13:59] would be pointing this agent to, and it creates an uh adoption or an engagement journey from that. And then there is a behavioral agent in terms of how users behave to our messages, how users behave to our um emails. So, that's about
[14:16] whether they are a responder, what could be the like uh like the typical time to take to respond, or they close our messages, or they the time out on our messages and all those things. So, I hope everyone has a question now. This
[14:33] could be fitting for McAfee, but how could it could it could be replicable for your own use case. Say that you're an e-commerce retail or any kind of SaaS business, right? So, that's a key insight. What I'm going to show you is is just patterns, and they are not
[14:49] prescriptions. So, the pattern here is the framework that you got to build is the core piece called the specialist agents. So, when you build your discovery agent, you need to let, I mean, add some few
[15:04] few short prompting examples in terms of how what are the core dimensions that you would like to model your users. So, this is not a completely automated machine automated workflow. This is where your human intelligence goes in, right? So, I would say this is where one
[15:20] of the human in the loop component happens, how do you want to describe or what are the categories that you want to design for your modeling use case? And this is where most of the creativity goes, right? So, in our use case, we have subscription, device, behavioral, and all those things, but in an
[15:37] e-commerce use use case, you could have user profile, purchase behavior, web session engagement, and all those things. Maybe in an fintech example, you can when you have tables like accounts, transaction, fraud events, and loans, and support tickets. You could have like
[15:54] different specialists that tackles on transaction behavior, their risk and fraud score, their lending and credit default score. So, it could be more reproducible when you sit and configure where you're configuring your discovery agent. And
[16:11] discovery agent is where it's going to lead you to the category routing, and the category routing will lead you to how many specialists you would need in this framework. So, let's let's move on to how do we deploy it? That there are a bunch of
[16:26] ways to deploy it, right? Like we we have an open source way using a Databricks infrastructure. We also have Databricks managed agents infrastructure. So, one way we could do that is using agent orchestration, the Open AI agents SDK. You could use the
[16:42] agent loop features, and we could use the tool calling features where you could even configure Unity Catalog methods in these function calls. And moving on to LLM inference, you could use the foundational models that we have in Databricks, or we can also
[16:58] bring our own models. We can select which models we're going to use. Um and the deployment is going to be straightforward. Like we could deploy this as a Databricks apps, and that's how like that that that's the best way to launch it because there are different
[17:13] ways that you can actually access this uh uh this workflow, and I'm going to show you in the next slide. So, the full tracing can be done using MLflow for for the same agentic feature engineering loop. So, the key insight here is that OpenAI agents SDK
[17:30] orchestrate the agents in this, but Databricks provides the infrastructure enterprise infrastructure for this. Moving on to the the next one, there are three ways you could access this feature engine agent-based feature engineering. One is scheduled pipelines. You can run
[17:47] this in a weekly manner, whenever you see a drift, or whenever in a monthly manner, or you could actually trigger this using a self-service portal. You can create a Streamlit UI and try to select which tables you need to mine more for, identify what are the gaps,
[18:02] you can prompt uh you can add a prompt to the discovery agent and you can create more specialist. This is The third way is uh using an more Yeah, the the chat interface way, like using natural language and trying to generate features, right?
[18:20] So, moving on to what we see as a business impact of feature store. So, what you see here is uh the impact The first you see in the first section is about what our ML models through feature stores have contributed to our use cases, right? It has nothing to do with
[18:37] agent-based feature engineering. It has to do with manual and AI-assisted engineering. That has given us shown us a great promise in terms of where we started. Over a 5-year waterfall revenue of 54 million, which constitute to 13 million per year, and this is
[18:52] constituting to propensity and pricing models that we have in production. Now, think about it, if we had built this in agentic feature engineering, which we are working on now, we could actually save 60% of time and effort reduction by unified orchestration.
[19:07] And the And the interesting side here is there are new patterns that you could establish and innovate that you don't have the time to do when you're delivering your models because if the data scientist job is to manage between innovation and delivery and I feel this
[19:24] could be a pathway where we could find new patterns to accomplish. So, thank you everyone. Please connect if you have any questions, but I hope you get to learn something here. Yeah.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.