Podcast episode
You are the Team — Anekha Sokhal, Moshi
agents build-vs-buy inference privacy
Anekha Sokhal, CEO of Moshi, joined swyx on Latent Space to walk through what her company built for commodity and energy traders: a system that pulls in futures prices, news, social posts, and client documents, then surfaces signals a trader wouldn't find on their own. She calls it "Bloomberg meets Claude meets Netflix."
Two ideas in the episode travel well beyond trading. First, Sokhal argues that recommendation systems (the ranking logic that decides what Netflix or TikTok surfaces next) are the most undervalued piece of AI in production, and most teams building with large language models never bother with ranking at all. Second, Moshi wrote its own document-reading model rather than using a vendor API because clients' data agreements forbid sending files off-premises. That's a procurement constraint, not an engineering preference.
The data-handling point is the more durable one. In regulated verticals, where the data goes is now what kills deals. The recommendation pitch is interesting, but getting a busy expert to trust a push is harder than building one.
Full analysis
Anekha Sokhal, CEO of Moshi, went on Latent Space to describe an AI product for commodity and energy traders: it pulls in futures prices, news, X posts, and client PDFs, then pushes signals a trader wouldn't find on their own. She calls it "Bloomberg meets Claude meets Netflix." Two things in this conversation matter to anyone buying or building AI, and neither is the trading product itself.
First, Sokhal argues recommendation systems (the push logic behind Netflix and TikTok that decides what to surface next) are the most undervalued piece of AI in production. Second, she built her own document-reading model instead of using a vendor, because clients won't let their data leave the building.
How hard is this to undo? Nothing here forces a decision. No deadline, no price change, no deprecation. This is a founder sharing a playbook, so treat it as a lens on choices you're already making: whether to layer push-style recommendations on your AI product, and whether to build or buy the unglamorous plumbing.
The Skeptic. Moshi says it surfaces 300 new data points every 4 seconds. For a trader, that's not a feature, that's noise. The hard problem in finance was never "more signals," it was "fewer, right ones." Sokhal half-admits this herself: the real complaint she heard at the conference was systems that get built, land in someone's inbox, and die unopened. That's the whole game, and "Bloomberg meets Claude meets Netflix" doesn't solve it. Netflix works because wrong guesses cost you nothing. A wrong push to a trader with a position on costs real money, and one bad call ends the trust. The recommendation framing is the easy part. Earning a trader's attention is the part nobody's cracked.
The Researcher. Sokhal's actual claim holds up better than the pitch. Recommendation systems are a different animal from a chatbot. A large language model predicts the next word; a recommender ranks what you'll click out of millions of options, trained on what people actually did. It's older, more measurable, and it already runs the biggest attention businesses on earth. Most teams bolting an LLM onto a product never build ranking at all. They dump output into a feed and hope. Sokhal's point that engineers undervalue it is correct, and it's the most portable idea in the episode. Her "disagreement between Reuters and Bloomberg is itself a signal" line is also real: surfacing that two sources conflict, with a confidence score, beats pretending one is truth.
The Builder. The build-vs-buy call is the useful one for your Tuesday. Moshi wrote its own vision-language model (an AI that reads both the text and the layout of a messy PDF) instead of renting one, because clients signed data agreements that forbid sending files to a third party. That's not ML heroism, it's procurement. And here's the catch: Sokhal says her engineers mostly come from NASA research backgrounds. That's who can afford to build this. If your team can't, a vendor API is the right call and you negotiate the data terms instead. The failure she describes, the unused system rotting in an inbox, is a UI and workflow problem, not a model problem. No amount of parameter count fixes "nobody clicks it."
The Enterprise Buyer. For anyone selling AI into regulated industries, data-handling terms are now the thing that kills deals, ahead of capability. A trader, a hospital, a law firm will not let their files touch your vendor's servers. So either you can process data inside their walls, or you lose to the competitor who can. That favors two kinds of sellers: the ones who built their own inference and can promise data never leaves, and the big clouds (Microsoft, Amazon, Google) who already have the compliance paperwork and on-premises options. It squeezes the middle: the thin SaaS wrapper reselling someone else's API, with no answer when procurement asks where the data goes.
Where they disagree. The Researcher thinks the recommendation idea is the keeper. The Skeptic thinks it's the exact place this product breaks, because getting a busy expert to trust a push is harder than building the push. Both are right, and that tension is the whole business. The Builder and the Enterprise Buyer split on build-vs-buy: the Builder says only a rare team should own its own models, the Enterprise Buyer says in regulated verticals you increasingly have no choice. Resolve it by asking what your clients will sign. If their data agreements forbid third-party processing, the build decision is made for you, NASA team or not.
What this actually hinges on. Two beliefs. One, that push-style recommendations lift adoption of AI tools in expert workflows rather than adding noise. Untested at scale in finance, and the inbox-graveyard problem says it's unproven. Two, that owning your own document-reading model is becoming table stakes in sensitive verticals. That one's grounded in real procurement behavior and it's the more durable idea. Before copying either, run the cheap test: put your AI's output where the user already works and measure clicks. If they ignore it, no model upgrade saves you.
Prediction: At least one major document-extraction vendor (Reducto, or a comparable PDF-parsing API provider) will publicly add an in-your-own-cloud or on-premises processing option as a named product tier by 2027-06-30.
Confidence: Medium. Procurement pressure in regulated verticals is real, and vendors respond to lost deals.
Why: Sokhal built her own document reader for one concrete reason: clients signed agreements forbidding their files from going to a third party. That's not unique to Moshi, it's the standard constraint in finance, healthcare, and legal, and it's the one thing capability can't overcome. When the reason buyers walk is "we can't let the data leave," the vendors losing those deals have a direct fix: offer processing inside the customer's own environment so the data never moves. That's a packaging and deployment change, not a research problem, and vendors move fast when deals are on the line. The opposite outcome, vendors staying cloud-only, means ceding the entire regulated-enterprise segment to in-house builds and the big clouds, which no growing API vendor willingly does.
Revisit by 2027-06-30: We're right if a named PDF-extraction vendor ships an on-premises or customer-cloud tier advertised on its site or in a release. We're wrong if the leading extraction vendors remain cloud-only with no such tier by that date.
Comments