Commodity Traders Need AI That Connects Market Signals to Their Positions

? anekha-sokhal describes Moshi as the program she wished she had while trading: a system that processes market information and pushes traders insights relevant to their portfolios. The company is starting with commodity, energy and macro markets. Its challenge, Sokhal said, is not simply gathering data but working out what matters to a trader’s positions and delivering that information in a usable way.

Moshi’s website materials shown during the discussion describe a service that can work with its own market, news, alternative and fundamental data, then be tailored with a customer’s portfolios, systems and workflows. A company post displayed during the discussion says Moshi processes 220,000 data points an hour. In conversation, Sokhal offered a second measure of scale: in the four seconds it takes her to say a sentence, Moshi has “learned 300 new things.” She said the system presents portfolio-related information when a user opens it, and lets them pull data and ask questions. A messaging update shown on screen says the product can send insights and conversation links through SMS and WhatsApp, where users can reply to continue the conversation.

The product’s inputs include structured and unstructured information. Structured data includes futures-market time series, technical indicators and moving averages, as well as time series on fundamentals such as supply and demand. Unstructured public information includes news, posts on X and podcast audio. Moshi also aims to incorporate information particular to a customer: the analysts and subscriptions a trader follows, internal data, and operational signals such as the number of LNG ships passing through the Strait of Hormuz.

Those private inputs vary by user. Sokhal said traders already have people they follow and subscriptions they rely on; she cannot simply tell each trader which voices to trust. Some customers also have specialized internal data, such as information about LNG ships moving through the Strait of Hormuz. The product can begin with Moshi’s own sources, she said, and can be tailored by connecting customer information.

Sokhal described a pipeline that combines public and private data, cleans and transforms it, applies statistics and machine learning, tags it and organizes it in what she called an “n-dimensional graph.” The output is software that pushes information to users.

Sokhal’s route to this problem ran through mathematics and energy trading. She studied Mathematics, Operational Research, Statistics and Economics at Warwick. Those subjects once seemed “so nerdy” to explain to people; now, she noted, people recognize them as connected to machine learning and AI. She wanted a fast-paced career involving data, began with an investment-banking and trading internship, then joined JPMorgan. She started on the emerging-markets desk, moved into commodities and spent most of her career in energy derivatives.

In commodities, Sokhal was interested in assembling a view of the market from its different parts: fundamentals, news and physical events. She said she saw a shift in the relationship between data and what might happen next, which helped prompt her to leave JPMorgan and pursue a data company. Before Moshi, she had also experimented with entrepreneurship, including a computer-vision project for jewelry recommendations that drew on her parents’ jewelry business. She wanted to become a founder who could talk about the technology behind the product, and saw the United States as a strong place to do that.

A Fulbright data scholarship brought her to the US. Sokhal recalled discussing the energy-market crisis and the connection between data and energy prices during her scholarship interview, when gas markets were highly volatile. She then worked in machine-learning research, including work published at ICLR in collaboration with Stability AI and work with NASA, before that experience led her to Moshi.

Sokhal does not describe Moshi as simply a new Bloomberg. She acknowledged Bloomberg chat as a valuable feature, and swyx described how traders use its standardized chat to transact and how he had parsed Bloomberg chat into structured pricing information in his own trading work. Sokhal’s shorthand for Moshi was “Bloomberg and Claude and Netflix”: Bloomberg chat, Claude-style answers and Netflix-style recommendations. The recommendation system is meant to help traders identify related developments they might not know to look for.

A headline or data point may not state its importance to a trader directly. Sokhal’s example was an energy-equities company doing something that could indirectly affect oil. A news stream might contain the relevant information, but a trader still has to connect it to the oil market and decide whether it matters to their book. A diagram shown during the discussion illustrated that chain: an energy company, an indirect impact on the oil market, and an oil trader.

Sokhal said a connected graph can surface such relationships. Otherwise, a person has to notice separate pieces of information and connect them. Moshi’s recommendation system is intended to make those connections, including second- and third-order effects a trader might not immediately know to look for. A trader following one market may care about related developments elsewhere, even when the connection is not obvious in a news stream.

That is different from summarizing text. Sokhal described a client who spent more time prompting an LLM than analyzing the market: writing a prompt, reading the output, noticing that it missed what mattered, rewriting the prompt and trying again. She called this “prompting fatigue.” Sokhal distinguishes using an LLM to summarize language or make a wall of text easier to read from using one to work out what matters to a particular portfolio.

She said Moshi’s team uses statistics, structure and market knowledge for analysis, and an LLM to make outputs sound more human. The product’s design, as Sokhal described it, aims to reduce the need for a trader to repeatedly steer a model toward the relevant question. The user should receive the connection the system has identified, rather than do the connecting through successive prompts.

The recommendation also has to arrive in a form people will use. Sokhal said a personal dashboard can amount to “your brain in a dashboard”: its usefulness to the person who built it does not mean someone else will know how to incorporate it into their own workflow. She connected this problem to product discovery at Moshi. Sometimes the hardest customer feedback, she said, is not that a feature is broken, but that the customer did not know it existed.

In a company post shown during the discussion, Sokhal described engineers taking on a product role: asking how a user will discover a feature, whether it needs to be announced, or whether it should appear at the moment it is useful. Her test was whether a five-year-old could work out what a feature does without being told. The post also described Moshi’s challenge as informing users without overwhelming them. For a system intended to deliver relevant information, making a feature or insight discoverable is part of the product problem.

Sokhal drew a connection between recommendation and interface design. Platforms such as Spotify and Instagram push items to users; people do not always have to assemble a dashboard and remember to revisit it. Moshi is still working out how its interface and recommendation system should reinforce one another. The issue she raised is how to make software that people incorporate into their work, rather than a custom dashboard that only its maker knows how to use.

More available information creates a problem of selection: which sources matter to a user? Sokhal said traders often have particular people they trust. In commodities, suppliers and facility operators may post status updates because social media is a fast way to communicate. Users tell Moshi about the sources they follow, she said, and the company uses that information when deciding what to surface.

Sokhal said Moshi tries to filter information and show a confidence score alongside context about the surrounding conversation. A claim from one person can be considered alongside other information around that conversation. Her account makes source selection dependent in part on users’ existing trust in particular people, rather than treating every public post as equally useful.

Reports from different outlets can also conflict. Sokhal gave the example of reports about how many ships or planes are moving, with Reuters, Bloomberg and the Wall Street Journal potentially giving different accounts. She said Moshi treats that divergence as potentially useful information, not simply as a problem to smooth away.

Sokhal’s point was that disagreement itself can matter to a trader: if sources do not agree, “is there an opportunity there? Because no one knows.” In her description, the system can show that divergence rather than replacing it with a single account.

Private data presents a separate integration question. Sokhal described one route for messy PDF data: customers can upload documents to the cloud version of Moshi, where a vision-language model breaks them down and the information is built into the company’s database. Other types of data require connecting to a customer’s systems. She said the approach depends on the kind of data and involves a further conversation.

When swyx asked whether Moshi builds its own document-processing models or uses an outside service, Sokhal identified data handling as one consideration. If a customer provides data, she said, the company needs to understand whether it is sent to a third party, how that party processes it and what it does with it. The choice also depends on the team: an existing service can be a good solution for a company without engineers, while a team with relevant capabilities may want to build. Sokhal noted that most of Moshi’s team had worked with NASA in some capacity, but said the decision depends on where a company is as a team.

After her AI Engineer NYC talk, Sokhal said she spoke with traders at funds, consultants and potential partners. She also heard from AI engineers facing pressure from management to build larger systems with smaller teams. The phrase she reported hearing was: “We don’t need a team. You are the team.” In her account, one engineer may be expected to build a system that would ordinarily take ten people.

Some of those engineers were asking whether they needed a swarm of agents and what would happen if something broke. Others had built a system people said they needed, sent it to them by email, and found that nobody clicked. The problem links the pressure to build with the challenge of making software useful and visible to the people it is meant to serve.

The conference also created a practical customer-development problem for Moshi. Sokhal said she had extended her New York stay as meetings accumulated over several days, including follow-ups with people in energy who wanted to meet in Houston. Her team was receiving sign-ups while she was out speaking with people. She said an initial meeting helps the team understand the problem a potential customer is trying to solve, after which they want to have a plan. Because the volume of inbound made individual meetings difficult to sustain, Moshi was preparing its first webinar.

Swyx proposed scheduled, on-site meetings in groups, drawing on the way banks had arranged meetings between companies and funds. Sokhal said the format could help: people could sign up for a 30-minute slot, meet in an assigned place and avoid trying to find one another around the venue. The exchange reflected a practical constraint: conference meetings can generate leads, but also take time to organize and follow up.

Sokhal said Moshi’s immediate priority was meeting clients, not hiring. The company had recently closed a job listing after four days and received 2,500 applications. She described that volume as difficult to deal with, mentioning applicants who were not legally allowed to work and uncertainty around visas. She said hiring also produced noise for a first-time founder still learning the market.

For customer development, Sokhal distinguished between people who have a problem and people who have that problem and want to buy. Finding the match was something she said she had not seen anyone do well. In the near term, her attention was on meeting potential clients and understanding what they needed; handling every conversation individually was already prompting the team to try a different format.