Slack built a general Recommend API because many teams needed recommendations for users and channels, rather than relying on one large recommendation use case.
2
Slack avoids using customer message text as a normal model feature because a model could reveal private business data across customers.
3
Slack chose to build some machine learning infrastructure internally when integrating an external service required more work than building a service that fit its own systems.
Summary
Aaron Maurer and Katrina Ni describe how Slack built a shared recommendation platform for many product teams. The platform exposes a simple API for requesting recommendations, while the ML Services team handles candidate retrieval, feature selection, weighting, model training, and serving behind it. They explain how this interface makes it easier for product managers and engineers to try ML without learning about embeddings or similarity search. Privacy shapes the system. Slack generally avoids building features from customer message text and prefers interaction signals such as relationships between users and channels. For cold starts, the team begins with hand-tuned models, logs the online features, and later trains ML models from that data. The conversation also covers Slack's vertically integrated ML engineering roles and the build-versus-buy decision. Aaron says Slack built internal serving infrastructure because integrating an external service was more difficult than building one that matched Slack's policies and existing systems.
Slack needed a shared recommendation system because teams had many smaller use cases
Aaron Maurer says Slack's recommendation work grew from a pattern that appeared across many products. Instead of one prominent recommender, teams wanted to recommend users or channels in many different contexts. Slack therefore created a generic API that other teams could call, then expanded the system into tools for building recommenders, training models, and producing training data. Search had been Slack's largest historical ML investment, and some data features could be reused, but recommendation had different needs and led to a separate approach.
A simple API helped product teams adopt machine learning
The recommendation platform hides concepts such as embeddings, cosine similarity, and nearest-neighbor search behind a basic request and response. Aaron says teams could ask for recommendations by sending a query with context about users or channels, then receive recommendations without handling the underlying ML system. Katrina adds that a new recommender could often be added within a week, with a test page that let product managers inspect results. Seeing useful output made it easier to compare the system with existing heuristics and build trust.
The platform reuses common features while allowing different candidate sources
Katrina explains that Slack commonly recommends channels and users, and the team has a shared signal service with features about both. A new use case usually requires deciding which features to use, how to weight them, and how to fetch candidates. Some cases can start with a simple operational database query, such as finding channels a user belongs to. Discovery use cases may need an embedding store to find nearby channels. Slack has reusable components, but the team does not use exactly the same retrieval process for every case.
Privacy rules out many direct uses of customer message text
Aaron says the damage from leaking customer data would outweigh the value of many ML features, since Slack contains business communications. The team therefore usually avoids creating features directly from message text and instead uses interaction patterns, such as which users and channels work together. Training also has to prevent models from learning customer content and reproducing it elsewhere. For autocomplete, Slack can extract likely suggestions from a team's own text and use aggregate signals such as how often a phrase appears, rather than training a generative model directly on team text.
Hand-tuned models solve cold starts and give teams an understandable baseline
Katrina describes starting each recommendation use case with a hand-tuned model. The team can explain a recommendation using familiar signals, such as how often two users interact, and product managers can understand why a feature received a larger weight. The online system logs the features it computes, which later provides training data for an ML model. Jake Noble says this approach also gives the team a benchmark to beat. Aaron adds that Slack keeps the hand-tuned model as a simple fallback if the serving system fails.
Logging online features avoids reproducing feature logic offline
Jake Noble describes Slack's approach as log and weight feature engineering. Features are computed online during serving and logged for later model training. This can avoid reproducing the same feature calculations in an offline pipeline, along with the associated backfills and training-serving mismatches. Jake says the method fits recommendation systems that can collect enough examples within a short training window. Aaron agrees that logging the online values can save substantial engineering time, although reproducing features offline can still be worthwhile in some cases.
Slack's ML engineers cover the full path from data to production
Katrina and Aaron explain that Slack's ML engineers work across data engineering, feature pipelines, model training, model serving, and application integration. People still develop different strengths. Some focus more on infrastructure or GPU systems, while others come from data science and spend more time exploring models. Aaron says the structure lets software engineers grow toward ML and data scientists grow toward software engineering. Pairing people with different strengths helps the team cover a wide technical surface without requiring every engineer to know every part equally well.
Large companies may build infrastructure when integration costs exceed implementation costs
Katrina says Slack replaced an external model-serving service with internal infrastructure after dealing with integration work, company policies, the Salesforce merger, and a long process for ending the external contract. Aaron frames the decision as a comparison between the work required to integrate a service and the work required to build one. He would prefer engineers to spend time on work specific to Slack, but infrastructure can still be specific enough to Slack's systems and constraints that building it is the easier option. Jake says the choice may change as ML infrastructure products become easier to integrate.
