Ethan Rosenthal's AI engineering team at Square works with product managers to find smart features for Square Messages, including chatbots and suggested replies.
2
Large language models let one model handle several natural language tasks, but updating that model creates trade-offs across use cases and makes retraining and versioning harder.
3
Ethan Rosenthal argues that streaming databases such as Materialize could support parts of feature stores and model monitoring from the same data and computation layer.
Summary
Ethan Rosenthal describes his work leading AI engineers on Square's Conversations Team, which builds smart features for Square Messages. His team develops chatbots and suggested replies, while working closely with product managers to decide which opportunities are useful and safe. They use large language models across several natural language tasks, but combining tasks into one model creates difficult trade-offs when a change improves one use case and harms another. Ethan also explains why model deployment needs business metrics, human review, and safeguards for personally identifiable information and bias. The conversation then turns to his proposal for building feature store and model monitoring capabilities on streaming databases. These systems could calculate real-time aggregates and preserve their historical values in one place, avoiding duplicated logic across specialized tools. Ethan is candid about the limits of this approach, especially at large scale, and discusses his earlier attempt to build a monitoring startup before joining Square.
AI engineering teams need a shared working relationship with product managers
Ethan Rosenthal says his team sits between obvious business requests and new ideas that AI engineers discover themselves. Product managers may bring features to build, while non-technical stakeholders may not know what machine learning can do. The team therefore works with product people and designers to test whether an idea can become a real product. Ethan says a strong product manager is especially valuable because machine learning products require business judgment alongside technical understanding. He advises engineers to explain systems through business metrics rather than terms such as area under an ROC curve, unless the audience already uses those measures.
Large language models can combine many natural language tasks
Square uses large language models in production, including for natural language features in its messaging products. Ethan says tasks that once needed separate solutions, such as question answering and text classification, may be handled by the same model. His team is deciding how many use cases to put into one model. This can reduce operational work, but it also makes automatic retraining more difficult. Ethan stresses that the technology remains uncertain, since it is still unclear how many tasks can be combined successfully in a single model.
Human involvement determines how conservative a model needs to be
Ethan describes safeguards around suggested replies. Filters suppress text that may contain personally identifiable information, and the team considers how biased training data might appear in generated suggestions. The chatbot is more automated, but it alerts a business owner when it cannot handle a situation. Suggested replies have a human reviewing them before they are sent, so an imperfect suggestion is less dangerous than an automated action in a fraud system. Ethan connects this human-in-the-loop design to the cost of mistakes. A wrong lipstick recommendation is tolerable, while a wrong fraud decision can be expensive.
Both engineers and product managers must understand the business context
Ethan says machine learning engineers should step outside their narrow technical domain and describe model performance in business terms. He also says product managers need enough technical and data science intuition to make good decisions. The two groups need a shared vocabulary because even technical terms can mean different things across statistics and computer science. Ethan expects the difficult work to involve understanding how a model interacts with the wider product ecosystem, since building and deploying models is becoming easier while judging their effects remains demanding.
One model across many tasks creates portfolio-level trade-offs
When several tasks share a model, an update may improve one task while making another worse. Ethan says the team must evaluate the model as a portfolio rather than focus on one score. The same issue appears within a single task when performance changes across population groups after retraining. He also describes the engineering cost of component-level changes. Teams may need to version fine-tuned components, pretrained embeddings, and downstream tasks separately. Updating embeddings can create a cascade of updates. Separate models are simpler to change, while a central model has lower infrastructure overhead and may learn from more data.
Few-shot learning reduces labeling work while expanding the range of tasks
Ethan explains that few-shot learning lets a model perform a classification task from a small number of labeled examples. Traditional supervised systems require people to annotate large amounts of data, which costs time and creates quality-control work. Large language models can learn from only a few examples, and sometimes from none in a zero-shot setup. Ethan says this lowers the cost of labels and makes it easier for a team to apply one model to many different tasks. It also adds to the need for decisions about which tasks belong together.
Streaming databases could support feature stores and model monitoring together
Ethan's database-bundling argument applies to feature stores, machine learning monitoring, and metrics layers. All need to calculate aggregates quickly from event streams and retrieve those values from earlier points in time. A feature store might calculate a merchant's transaction count over a recent window, while monitoring might calculate model accuracy over a trailing period. Historical values are also needed for training and analysis. Ethan says streaming databases such as Materialize could provide these capabilities from one data layer, although he is clear that the approach is still experimental.
Keeping tools close to the source data avoids duplicated business logic
Ethan would rather have a monitoring tool come to the data than send data into a separate system. Model performance often depends on complicated business definitions that are already expressed in warehouse queries. Rebuilding that logic inside a monitoring product can produce two versions of the same metric. A shared database could let production features, monitoring values, and analytics use the same computation. Ethan also accepts the trade-off: specialized tools provide predefined metrics and workflows, while a general data layer reduces silos but leaves teams more work to define and manage those metrics.
"I think I think eventually feature stores will become more unanimous and then possibly for the lower end use cases the streaming databases will be able to solve for that."Ethan Rosenthal37:47
Who should watch
You are building AI features inside an existing product and need a better way to work with product managers.
Your team is deciding whether to use one language model across several tasks and needs to reason about shared updates, metrics, and human review.
You are comparing specialized feature store or monitoring products with a database-centered approach to real-time aggregates and historical data.
