# Instacart Instacart Engineering - Medium This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Agentic Machine Learning Modeling at Instacart DevFeed: [Agentic Machine Learning Modeling at Instacart]() Original publisher: [Read original article]() Author: Tilman Drerup Published: 2026-09-03T16:05:30Z Content type: article Language: en Sources: [Instacart]() Topics: [AI Agent](), [Model Development](), [AI Development](), [Machine learning](), [Development]() Tags: [agent](), [agentic](), [ai](), [ai-agent](), [artificial-intelligence](), [development](), [instacart](), [machine-learning](), [models](), [research]() ### AI overview Instacart describes how its machine learning engineers are exploring AI-agent-assisted modeling loops. The approach keeps engineers responsible for defining problems and supervising work while agents develop hypotheses, implement experiments, and evaluate them. ### Source excerpt Tilman Drerup, Moe Moazzami, Shih-Ting Lin, Greg Reda (and many more) Introduction At Instacart, artificial intelligence is fundamentally changing the way our machine learning engineers operate. In a prior blog post, we used one of our teams as a case study to illustrate how the emergence of agents has reshaped what machine learning engineers spend their time on. The post below goes a few levels deeper and zooms in on the machine learning modeling process itself, an area where recent developments in AI-assisted research have opened up exciting new frontiers that we are now actively exploring. Based on the combined insights of a small horde of MLEs, we will share some of the big wins, the disappointments, and the surprises we encountered along the way. Let's jump in. Big Picture Machine learning models permeate Instacart's marketplace, powering everything from search results to replacement recommendations and expected delivery times. Each of these models is carefully built, maintained, and iterated upon by our crafty MLEs. And while the hours spent on modeling tend to be extremely impactful for the company, the process itself is quite time-consuming and requires an MLE to make a myriad of both small and large decisions. These decisions include, among other things, the right modeling architecture, the appropriate choice for a large number of hyperparameters, the feature set to include, or the most suitable loss functions. All of these decisions are often grounded in a fairly lengthy review of the associated literature as well as a good dose of MLE intuition. Unfortunately, given the combinatorial complexity of this problem and the constraints on human time, MLEs can typically only explore a small part of the entire universe of modeling options, often leaving substantial value on the table. For a few months now, MLEs across Instacart have been exploring the development of methods and tools to tackle this constraint through AI-agent-assisted modeling loops. What follows ## How Instacart Built Blueberry, a Slack-Native On-Call Reasoning Harness DevFeed: [How Instacart Built Blueberry, a Slack-Native On-Call Reasoning Harness]() Original publisher: [Read original article]() Author: Karthik Halukurike Published: 2026-07-14T16:39:20Z Content type: tutorial Language: en Sources: [Instacart]() Topics: [incident](), [Slack](), [context](), [dashboards]() Tags: [ai-agent](), [ai-agents-in-action](), [context](), [incident-response](), [on-call](), [reasoning](), [slack](), [software-development]() ### AI overview Instacart describes Blueberry, a Slack-native on-call reasoning harness that auto-triages qualifying alerts and supports follow-up investigations. It is designed to help teams reach a shared understanding and test theories more quickly during on-call work. ### Source excerpt How we built a Slack-native on-call reasoning harness at Instacart that shortens time to first insight, speeds up theory testing, and turns tribal knowledge into reusable infrastructure. Key Contributors: Karthik Halukurike, Gabe de Oliveira, Hassan Jallad, Alan Wong On-call work is a race to turn noisy signals into shared judgment. The hardest minutes of that race aren't the ones spent fixing the bug -- they're the ones spent figuring out what the bug even is, while everyone in the thread is asking the same question from a slightly different angle. Blueberry is the system we built at Instacart for those several minutes. It lives in the Slack thread where the team is already coordinating, picks up each alert as it fires, and lands a grounded explanation back in the thread in about three minutes -- thousands of times a month. On-call is mostly a clarity and speed problem Most on-call pain does not start with a major incident. It starts in the noisy window right after a page fires, when the thread fills with links, dashboards, guesses, and partial context. Someone asks whether a deployment caused it. Someone else asks how broad it is. A third engineer joins and asks what is going on. In that moment, the hardest problem is often not deep root-cause analysis. It is getting to a shared understanding quickly enough that the team can make a good next move. For us, that made two metrics matter most: time to first insight (TTFI) and time to test theories (TTTT). TTFI comes from auto-triaging every qualifying alert the moment it lands. TTTT comes from engineer-initiated on-demand investigations and follow-ups as the investigation deepens. Blueberry is a Slack-native on-call reasoning harness Blueberry was built for that first window of confusion. Blueberry lives in Slack because that is where on-call engineers already coordinate, ask clarifying questions, and make decisions under pressure. We wanted the system to work inside the shared operational conversation so the full team ## Variance Reduction Below the Randomization Grain DevFeed: [Variance Reduction Below the Randomization Grain]() Original publisher: [Read original article]() Author: Tilman Drerup Published: 2026-07-01T16:28:36Z Content type: article Language: en Sources: [Instacart]() Topics: [experiments]() Tags: [capacity](), [causal-inference](), [economics](), [engineering](), [experiment](), [experimentation](), [experiments](), [machine-learning](), [marketplaces](), [metrics](), [reduce](), [science](), [techniques](), [variance]() ### AI overview This article explains how marketplace experiments can reduce metric variance below the level at which treatment is randomized. It describes cluster-level randomization for containing interference and shows how fine-grained outcome predictability can improve statistical power and reduce experimentation time. ### Source excerpt Sergio Camelo, Caitlin Kearns, Matias Cersosimo, and Tilman Drerup As artificial intelligence increases the velocity of engineering and science teams, experimental throughput is set to become a bottleneck for many product decisions. Many companies can now build faster than they can experiment, with queues of good ideas running the risk of not being tested because of lack of experimental capacity. This problem is particularly severe in marketplaces, where the presence of spillover and cannibalization effects between experimental units requires cluster-level randomization techniques. That randomization, in turn, has the unfortunate tendency to substantially reduce statistical power and slow down experimentation. In this post, we show that the predictability of outcomes at fine grains can be exploited to reduce the variance of aggregate metrics, even when experiments themselves are run at a coarse level. Since statistical power depends on metric variability, this yields considerable reductions in experimentation time. The Interference Problem In marketplace settings, behavior and outcomes for individual participants are inherently intertwined. In a delivery marketplace like Instacart, for example, the dispatch system solves a bipartite matching problem between shoppers and customer orders. Since assignments are global and interdependent, matching an order to one shopper means that the same order cannot be matched to another shopper. As a result, changing the handling for a single order creates ripples that affect the orders around it. If an experimenter were to assign a treatment intervention to one of these orders while leaving neighboring orders as controls, the latter would evidently be contaminated. A common response to this problem is to randomize treatments at the level of a cluster, chosen so that interference can stay within it. In food and grocery delivery, that cluster is typically a geographical region. Since every order within a region sees the same treatme ## Leveraging PyFixest for High-Cardinality Marketplace Modeling at Instacart DevFeed: [Leveraging PyFixest for High-Cardinality Marketplace Modeling at Instacart]() Original publisher: [Read original article]() Author: Benjamin Knight Published: 2026-06-29T16:06:24Z Content type: article Language: en Sources: [Instacart]() Topics: [benchmarking](), [math](), [Algorithms, Complexity](), [Software](), [Programming](), [Routing (disambiguation)]() Tags: [benchmarking](), [bias](), [cardinality](), [data-science](), [delivery](), [efficiency](), [estimator](), [fixed-effects-model](), [instacart](), [linear-regression](), [measurement](), [memory](), [precision](), [pyfixest](), [regression](), [routing](), [speed](), [statistics](), [techniques]() ### AI overview This Instacart article explains why ordinary least squares regression becomes computationally impractical for marketplace experiments with high-cardinality categories. It presents the mathematical basis for using Fixest and Pyfixest, discusses switchback experiment designs for addressing treatment spillover, and describes benchmarks comparing processing speed, memory efficiency, and estimator precision. ### Source excerpt Benjamin S. Knight Scaling Marketplace experiments requires specialized statistical techniques. We examine why standard ordinary least squares regression (OLS) becomes computationally intractable when controlling for high-cardinality categories. We then dive into the underlying math and demonstrate how modern packages -- specifically Fixest and Pyfixest -- bypass these limitations. We conclude by benchmarking these methods to show their real-world impact on processing speed, memory efficiency, and estimator precision. At Instacart we strive to give our customers access to all the fresh foods and ingredients that they would normally get from a trip to the grocery store, but without the hassle of driving, finding parking, waiting in line, etc. Instacart's Marketplace team is responsible for surfacing customers' orders to shoppers, aligning Instacart's delivery windows with shoppers' projected availabilities as efficiently as possible. This entails a careful balancing act. If we offer delivery windows that are sooner / more popular, then we risk overextending shoppers' ability to fulfill those orders on time. If we are too conservative in our delivery option offerings, then we risk losing potential orders. Accurately measuring the impact of changes in our batching and routing algorithms requires thoughtful experiment design and software. Better predictions of future demand / time-to-fulfill allow Instacart to offer more convenient delivery windows.Experimentation on Marketplace One of our primary concerns in Marketplace is treatment spillage. For example, if we adjust our batching algorithm and increase the rate at which multiple orders are combined into batches in Brooklyn and Queens, then we face a real risk of also influencing the rate of batch creation / completion in Staten Island, the Bronx, and Manhattan. In this case the treatment impacts the control group -- a classic source of measurement bias as a consequence of violating the Stable Unit Treatment Value Assumpt ## From Scoring to Spelling: Rebuilding Ads Retrieval at Instacart DevFeed: [From Scoring to Spelling: Rebuilding Ads Retrieval at Instacart]() Original publisher: [Read original article]() Author: Karuna Ahuja Published: 2026-06-02T18:50:19Z Content type: article Language: en Sources: [Instacart]() Topics: [Transformer](), [recommendations](), [systems](), [context](), [real-time]() Tags: [bert](), [context](), [generative](), [inference](), [machine-learning](), [model](), [real-time](), [recommendation-system](), [recommendations](), [retrieval]() ### AI overview Instacart describes rebuilding its ads retrieval system by moving from a product-scoring encoder to a generative model that predicts product IDs token by token. The system uses contextual shopping sessions and a BERT-like transformer to retrieve sponsored and organic recommendations. ### Source excerpt Key Contributors: Karuna Ahuja, Marko Avdalovic, Soroush Sobhkhiz, Shrikar Archak, Xiyu Wang, Ji Chao Zhang, Hao Yan Introduction Every time a user opens Instacart, they see product recommendations: on the retailer home page, in search results, and alongside their cart. Many of these recommendations are sponsored products surfaced by a retrieval model that decides which products to show from a vast ads product catalog. A relevant ad helps users discover products they didn't know they needed; a less relevant one generates friction. Two years ago, we introduced Contextual Recommendations (CR), a BERT-based sequence model powering retrieval for both ads and organic recommendations across all major browse surfaces. In this post, we'll focus on our ads retrieval. We will detail how we rebuilt the system, by moving from an encoder that scores products to a generative model that spells them out, token by token. By doing so, we unlocked a new level of contextual matching -- ensuring brands appear exactly when users want them, while simultaneously opening up discovery of thousands of relevant products the previous system couldn't retrieve. Contextual Recommendations: A recap At its core, CR treats grocery shopping as a language modeling task, where atomic product IDs function as tokens and, the finite subset of the catalog it is trained on, acts as its 'vocabulary'. The model leverages the user's real-time session, which includes product views, item page visits, and cart additions, as a sequence of these product tokens. A BERT-like transformer is then trained on millions of authentic shopping sessions to predict the next token (i.e. singular product) in the sequence. This process allows the model to learn and capture complex purchasing patterns, such as the tendency for users who add pasta and olive oil to frequently add garlic next. This single retrieval layer replaced multiple ad-hoc systems and powers recommendation carousels across all major browse surfaces, serving both ## Semantic IDs: Product Understanding at Scale DevFeed: [Semantic IDs: Product Understanding at Scale]() Original publisher: [Read original article]() Author: Shrikar Archak Published: 2026-06-02T16:58:00Z Content type: article Language: en Sources: [Instacart]() Topics: [recommendation systems](), [data](), [systems]() Tags: [embedding](), [ids](), [machine-learning](), [model](), [product](), [recommendation-system](), [recommender-systems](), [retrieval](), [scale](), [vector]() ### AI overview Instacart describes how it built semantic IDs to capture relationships among grocery products that a hierarchical taxonomy misses. The approach uses product embeddings, residual vector quantization, catalog structure, contrastive training, and separate precision and discovery strategies to address cold-start products, sparse categories, and catalog-quality issues. ### Source excerpt Key Contributors: Shrikar Archak, Karuna Ahuja, Soroush Sobhkhiz, Marko Avdalovic, Xiyu Wang, JiChao Zhang, Hao Yan, Chris Hartley Introduction Operating a grocery catalog at Instacart's scale means managing millions of products across thousands of categories. Every product is assigned to a category in our hierarchical taxonomy like "Dairy > Cheese > Parmesan". These categories provide broad classification, but they miss the connections that drive how customers actually shop. For example, a customer is building a cheese board. They've added Parmigiano Reggiano, and now they need accompaniments. Our taxonomy puts it in "Dairy > Cheese > Parmesan," so a category-based system can suggest other parmesan cheeses. But it can't connect them to the Castelvetrano olives in Pantry > Condiments > Olives, the olive tapenade in Deli > Olives Dips and Spreads, or the crudité and pre-assembled cheese tray in Deli > Prepared Meals > Party Trays. These products live in completely different branches of the catalog, with no shared ancestor below "Food." But any customer would tell you they belong together. This cross-category blindness shows up in three ways. Cold start: new products arrive with zero purchase history. We can assign them to the right category, but a category alone can't connect them to the products customers would actually consider alongside them, so they stay invisible. Tail category coverage: recommendation models learn from volume, so they skew toward popular grocery staples. Products in sparse categories lack the interaction data to surface, and the taxonomy gives the model no bridge to related items in other branches. Catalog quality at scale: with millions of products, mislabeling is inevitable -- a protein bar filed under "Candy," a sparkling water under "Soda." A rigid tree has no way to flag these because the only signal is the label itself. In this post, we walk through how we built semantic IDs at Instacart to address these problems: the embedding choices, th ## How AI Changes the Role of Applied Scientists DevFeed: [How AI Changes the Role of Applied Scientists]() Original publisher: [Read original article]() Author: Tilman Drerup Published: 2026-05-22T17:40:32Z Content type: article Language: en Sources: [Instacart]() Topics: [Artificial Intelligence](), [Data Science](), [AI, ML & Data Engineering]() Tags: [ai](), [analysis](), [applied-science](), [artificial-intelligence](), [changes](), [coding](), [economics](), [machine-learning](), [math](), [statistics]() ### AI overview Instacart's Economics Team examines how artificial intelligence is changing the work of applied scientists. The article frames the role as a bundle of tasks and proposes analyzing changes in the team's project portfolio from 2023 onward, with potentially larger effects on coding than on causal inference. ### Source excerpt Levi Boxell, Tilman Drerup, Alexandr Lenk The Economics Team at Instacart is an applied science team that operates at the intersection of machine learning engineering and economics. Similar to other applied science teams, our work involves a good chunk of engineering, steeped in statistics, math, theory, and strategy. And while that is still at the heart of what we do today, the surprisingly rapid emergence of artificial intelligence has also fundamentally altered our work in ways that we did not see coming. With this post, we want to provide a brief check-in and share an analysis of the patterns we are seeing from a distinctly economic perspective. To do so, we analyze the empirical dynamics of our project portfolio between 2023 and today, looking at the evolution of both the nature and quantity of our work over time. To start, let's have a quick refresher of what economists at Instacart do and provide a theoretical framework to think about the impact of technological change through AI. Background & Theoretical Framework At Instacart, economists spend their day-to-day on a diverse portfolio of tasks and activities. Similar to other applied science teams within the company, our work relies on a blend of skills, including economics, statistics, math, machine learning, data manipulation, coding, and AI. Due to this versatility in tasks, the team's work provides a particularly rich testing ground for predictions derived from economic theories concerning the impact of technological change. But what does economic theory actually tell us? A useful theoretical abstraction for an applied scientist's role is to frame it as a bundle of tasks (Autor, Levy, and Murnane, 2003), with each task characterized by its own production function (Acemoglu and Autor, 2011). Slightly simplified, a production function tells us how much output we can produce for a given level of input in a specific task. Comparisons of production functions across tasks in turn determine how we allocate our t ## Scaling Personalized Marketing for Multi-Tenant Commerce Platforms DevFeed: [Scaling Personalized Marketing for Multi-Tenant Commerce Platforms]() Original publisher: [Read original article]() Author: Brent Scheibelhut Published: 2026-05-14T23:53:27Z Content type: article Language: en Sources: [Instacart]() Topics: [Multi-tenancy](), [personalization]() Tags: [architecture](), [multi-tenancy](), [personalization](), [platforms]() ### AI overview Instacart describes how it adapted its marketing automation infrastructure for Storefront Pro, a white-label e-commerce platform serving more than 350 retailers. The architecture adds multi-tenancy and scaling capabilities to support personalized, lifecycle, and self-service marketing while preserving retailer branding, tenant isolation, performance, and operational independence. ### Source excerpt TL;DRBackground: Marketing Across Marketplace and Storefront Instacart operates across two distinct commerce experiences: Instacart Marketplace, our first-party consumer marketplace Storefront Pro, our white-label e-commerce platform for retailers For years, our marketing automation infrastructure was built primarily to support Marketplace use cases. That model worked well in a first-party environment, where the product experience, customer relationship, and brand were all centrally managed by Instacart. Storefront Pro introduced a very different set of requirements. As the platform scaled to more than 350 retailers, we needed to support hundreds of independent brands, each with its own brand identity, customer base, and marketing strategy. Retailers wanted the same level of personalization and lifecycle marketing sophistication that is available on the Instacart Marketplace, but in a way that preserved their own brand and operational independence. That raised a core architectural challenge. How do we deliver Marketplace-grade personalization and lifecycle marketing capabilities to hundreds of retailers without sacrificing tenant isolation, performance, or ease of use? To succeed, the platform needed to let retail marketers: Launch onboarding, winback, and promotional campaigns Customize branding and messaging Target specific customer segments Measure performance and iterate quickly At the same time, we could not simply extend a single-tenant marketing system to a multi-tenant environment without introducing serious risks, including: Cross-retailer data leakage API rate-limit bottlenecks Manual operational overhead Inconsistent brand experiences Tight vendor coupling Solving those constraints required rethinking the architecture so that it could support self-service marketing at scale while preserving the isolation and reliability each retailer expects. Architecture Overview Our solution builds on a third-party marketing automation platform, while adding critical mu ## Empowering Carrot Ads with Domain Adaptive Learning DevFeed: [Empowering Carrot Ads with Domain Adaptive Learning]() Original publisher: [Read original article]() Author: Xiyu Wang Published: 2026-05-04T19:11:17Z Content type: article Language: en Sources: [Instacart]() Topics: [recommendation systems](), [Artificial Intelligence](), [data](), [Optimization](), [Website]() Tags: [advertising](), [ai](), [data](), [domain](), [machine-learning](), [optimization](), [ranking](), [retail]() ### AI overview The article explains how Instacart applies Domain Adaptive Learning to Carrot Ads to address the cold-start problem for new retail partner websites. It describes transferring knowledge from Instacart Marketplace data to target domains to improve click-through-rate prediction and ad ranking with limited partner-specific interaction data. ### Source excerpt Authors: Trey Zhong, Xiyu Wang Contributors: Joseph Haraldson, Sharad Gupta, Sarah Lamacchia Introduction Carrot Ads is Instacart's omnichannel retail media solution that allows retailer partners to build and scale their own advertising businesses on either their owned-and-operated (O&O) websites and apps or their whitelabel Storefront hosted by Instacart. Carrot Ads empowers retailers and CPG brands to accelerate revenue, while improving the customer experience, engagement and Ads return on investment. It features enterprise-grade infrastructure, AI-powered optimization, years of proprietary first-party data and flexibility to choose from retailer-sourced Ads demand, Instacart-sourced demand from 7,500+ CPG brands, or both. However, onboarding a new partner onto Carrot Ads introduces a key challenge: the 'cold start' problem, where limited historical interactions make it difficult to predict user behavior accurately. To serve performant ads, our systems rely on predicting a user's Click-Through Rate (CTR) to generate a ranking score. On the Instacart Marketplace, we have billions of historical signals to train a model to do so. But when a partner launches a new ads experience on their O&O e-commerce site, there is often little to no interaction history for that property, so training an accurate model becomes challenging. User behavior can vary dramatically between websites -- for example, browsing patterns on a grocery site differ from those on a pet supply or electronics site. Training a model from scratch for a new domain is data hungry. Conversely, directly deploying Instacart's existing Marketplace model often fails to capture the nuances of the partner's specific inventory and user base. To address this, we developed a Domain Adaptive Learning approach that transfers knowledge from Instacart's data-rich environment to new partner environments. By treating the Instacart Marketplace as a source domain and the partner's website as a target domain, we can transfer ## Our Early Journey to Transform Instacart's Discovery Recommendations with LLMs DevFeed: [Our Early Journey to Transform Instacart's Discovery Recommendations with LLMs]() Original publisher: [Read original article]() Author: Moein Hasani Published: 2026-02-26T18:55:35Z Content type: article Language: en Sources: [Instacart]() Topics: [recommendation systems](), [LLMs](), [Generative AI](), [personalization](), [User Experience](), [Artificial Intelligence]() Tags: [ai](), [discovery](), [generative-ai](), [instacart](), [large-language-models](), [llm](), [llms](), [machine-learning](), [personalization](), [recommendation-systems](), [recommendations](), [recommender-systems](), [systems](), [user-experience]() ### AI overview Instacart describes its early effort to use large language models in the Shopping Hub, an app surface for personalized product discovery. The article covers an AI-native platform for content generation, evaluation, and retrieval, and reports that generative models show promise for improving recommendations at scale. ### Source excerpt Key Contributors: Moein Hasani, Hamidreza Shahidi, Trace Levinson, Guanghua Shu Introduction At Instacart, we are laser-focused on improving the user experience by making shopping feel easy, engaging, and personalized. Our discovery surfaces play a central role in bringing this to life. Alongside explicit Search intents, discovery is our opportunity to meet customers' implicit needs, presenting them with the most relevant and inspiring content we have to offer. The main discovery surface within the Instacart app, referred to here as the "Shopping Hub", is one of the most critical in this regard. This is the surface a customer lands on within the Instacart app after selecting their desired retailer, guiding them along their entire journey. What users see here shapes not just what they buy, but how intuitive and enjoyable their experience feels. Given its importance, our team runs dozens of Shopping Hub experiments per year, constantly evaluating new ways to enrich the discovery experience. Historically, these experiments have been constrained by static content libraries feeding our recommendation systems. With the rapid advancement of generative AI, a critical opportunity began to emerge: rather than incrementally improving a swath of legacy systems, could we leverage LLMs to rethink how content shows up for a user from the ground up? Which new primitives could we build to uplevel quality, personalization, and cohesion across the page? This blog post walks through our early journey to answer these questions. By investing in a new AI-native platform for content generation, evaluation, and retrieval, we have found generative models to show real promise in improving recommendations at scale. Below, we highlight the approach we took in developing this platform, a few key learnings so far, and where we're most bullish moving forward. Limitations of Traditional Recommendation Engines Our Shopping Hub page is constructed from multiple subcomponents called placements. Each p