Evidence at a glance
The Gap Behind the Meetings After New York
At AI Engineer New York, Anekha Sokhal introduced Moshi, a recommendation engine for institutional traders, with a particular focus on energy markets. It aims to connect the constant flow of market information to a trader’s positions and concerns. Sokhal previously traded energy derivatives at JPMorgan and describes Moshi as the tool she wished she had while trading. In the interview, she said meetings after her talk kept extending her planned stay in New York, with further conversations about energy taking her toward Houston.
A packed schedule after a conference shows that the problem can start conversations, but it does not by itself prove trading gains. The more useful point for technical leaders is the problem definition: traders do not simply lack information. They have to keep deciding what is credible, what matters to their book, and what merits further checking. Moshi is therefore betting on attention filtering, rather than building yet another chat box that waits for a question.
Bringing Market Feeds and Private Materials Together
According to the public descriptions of the product, Moshi is meant to bring in more than market prices. Futures data, fundamental and technical indicators, news, and social media are combined with traders’ subscriptions, emails, PDFs, and internal materials. The system is described as cleaning and transforming these different data types, tagging information with statistical and machine-learning methods, and organizing it in a graph intended to connect related items.
The key step is mapping those connections to a user’s positions. A news item is not merely returned as a search result; the system may identify it as relevant to a trading theme and point to possible downstream effects. A public talk summary describes this as connecting second- and third-order impacts, but does not disclose enough implementation detail to reproduce the method. The design could reduce the work of searching and piecing together material, but only if data integration, position context, and source management all hold together. A weak link in any of them can make a recommendation irrelevant.
Scale Is an Input, Not Proof of Performance
Moshi has made several public claims about data scale. Sokhal has said the system processes 220,000 data points per hour. Another interview cited more than 2.5 billion monitored data points, while a talk summary referred to 2.4 billion and described the system as learning “300 new things” in the time it takes to read a sentence. These figures come from the company or a summary of its presentation. Public materials do not establish a consistent definition of a data point, explain the time windows behind the 2.4-billion and 2.5-billion figures, or define what counts as one of those “new things.”
The company has also promoted a natural-gas calendar-spread case, saying the system flagged a major breakout three days ahead and describing the breakout as 70%. The available materials do not include a full trading record, a comparison baseline, or independent verification. It should therefore be treated as a company-reported example, not as evidence of predictive accuracy or returns. For a build-or-buy decision, such metrics indicate the scale at which the system claims to process and surface information. They cannot replace evaluation of false positives, missed signals, lead time, and practical value to the workflow.
The Difference Between Recommendations and Chat Is Who Does the Filtering
Moshi’s product claim is not that traders should keep prompting a model until they ask the right question. Instead, the system is meant to surface information that may matter to a user’s positions, after which the trader checks the evidence and makes the decision. Sokhal has compared the product to a combination of Bloomberg, Claude, and Netflix: market data, an interface for working with it, and recommendations tailored to an individual trader’s context. The analogy describes the intended combination of capabilities; it does not mean Moshi replaces a terminal, a general-purpose model, or the trader.
On the technical division of labor, Sokhal says statistical and deterministic models help judge whether market information is relevant to a user’s positions, while an LLM plays one layer in expressing the result more naturally. That is the founder’s description, and public materials provide no independent audit or model evaluation. She has also said that the system shows sources, claims, and assumptions, which can help users inspect the basis for a conclusion. But visible evidence is not the same as reliably resolving conflicting sources, and the available materials do not describe a conflict-resolution algorithm.
Technical Leaders Should Evaluate the Workflow, Not the Demo
For a financial institution’s technical team, a product like Moshi is first a data and workflow engineering problem. Public market feeds can provide shared inputs, but the harder work is securely connecting subscriptions and internal materials, preserving source and time context, and delivering results where traders will actually use them. Sokhal says the team uses a custom vision-language model to parse uploaded PDFs and does not want to hand user materials to a third party. That makes privacy control part of the product proposition, while leaving model maintenance and integration work with the team.
One practical evaluation is to run recommendations alongside the existing monitoring process and inspect, item by item, which position each signal relates to, where its evidence came from, and how conflicts are presented. Track which prompts actually change the human verification workload. The goal is not to assume that AI should make the decision, but to test whether it consistently reduces triage without introducing hidden errors into trading judgments. The interview’s account of engineers being told “you are the team” is also a caution: AI may accelerate development, but it does not automatically remove the data governance, reliability, and user-coordination responsibilities that used to be shared across a team.