TwoSetAI: Decoding AI Builders

From a patent law class at Penn to automated takedowns: Jesse Xu is the CTO and co-founder of Podqi, an AI brand protection platform he started with two best friends, Trevor and Ivan. At the time of this conversation the team is 11 people, working in person in the Bay Area. The three knew they wanted to build something after ChatGPT came out, and went looking for the most boring, manual and tedious space they could find. They began with patents, where, as Jesse tells it, clearing prior art came down to paralegals doing keyword searches, then pivoted within a few months to trademark and copyright, where the volume was much higher and where they could judge for themselves whether an AI's call was right. By his account Podqi works with brands such as Netflix and Warner Brothers, with Fortune 10 hardware companies, and with consumer brands like Jones Road Beauty and Fear of God.

In this episode, Jesse joins TwoSetAI to explain how counterfeiting has changed. Fake goods are only one end of the spectrum, he says. Bad actors now put up pixel-perfect copies of a brand's site, buy ads that put those copies at the top of the results, and phish the customers who land there. He explains the problem at three levels, for an elementary schooler, a college student and an IP lawyer, and cites industry reports that put counterfeiting at a $2 to 3 trillion problem as of 2021.

You can learn more about Podqi here.

We go deep on how the system works. Jesse jokes that Podqi is a scraping company: a distributed architecture scrapes the largest marketplaces, the wider web, image sources and registries, evaluates what it finds with classifiers and LLMs, and puts the results on a dashboard where someone on the brand's side, the human in the loop, sends takedowns with a click. Angelina cites more than 5,000 infringements per day for some customers. Detection combines image matching, logo parsing and fuzzy matching with custom profiles built from each brand's guidelines, and for large customers the models are fine-tuned on their image libraries. The approach starts with recall, a wide net that can surface 30,000 results in one run, then ranks them so the team acts on the top 10%. He also walks through where an LLM pipeline can fail, from a page that does not render to a hallucinated match, and the layers of checks around it.

We also get into the harder parts. By law, Jesse says, it is up to the rights owner to notify a platform of infringement, and platforms technically have no mandate to take fakes down proactively. Until a report arrives they keep making margin on those listings, which he calls very much a conflict of interest, while noting that some platforms police better than others. Filing takedown forms works for one-offs, he says, not for 500 infringements a day. On the money side, he says brands can expect around 1 to 2% baseline revenue growth over 6 to 12 months once listings start coming down, that about 95% of infringements are simply automated takedowns, and that the other 5% can become documented cases for legal teams seeking retroactive compensation. He talks about conversations with the FBI and with customs, about hiring for a team that loves to grind, and about a business where, by his account, more than 70% of the revenue booked in the last 6 months came from referrals. He closes with two book recommendations.

We discuss:

* Why the co-founders went looking for the most boring, manual and tedious space they could find

* A patent law class at Penn, and paralegals doing keyword searches

* The pivot from patents to trademark and copyright, and the sniff test behind it

* What counts as infringement, from the clear-cut to the gray areas

* Podqi explained to an elementary schooler: fake Baby Shark toys

* Explained to a college student: fake sites, fake ads, fake everything

* Explained to an IP lawyer: investigative flows that trace a network of infringers

* Conversations with the FBI and customs, and stopping goods at the ports

* Two kinds of customer: enterprise brands with protection teams, and D2C brands that become targets overnight

* A $2 to 3 trillion problem, and why the damage is more than lost sales

* "It takes years to build up a brand. It's very quick to lose it."

* Brand protection as a revenue driver: 1 to 2% baseline revenue growth, by his account

* The 95% that is automated takedown, and the 5% that goes to the legal team

* Scrape, evaluate, act: the three-part architecture, with a human in the loop

* Why platforms have no mandate to remove fakes proactively, and the conflict of interest he sees

* Classifiers and LLMs, and what unstructured input made possible

* Image matching, logo parsing, fuzzy matching and custom brand profiles

* Precision versus recall: cast a wide net, then rank down to the top 10%

* Where hallucination shows up in IP matching, and the layers of checks around it

* Hiring: an in-person team of 11, and the roles open at the time

* Scaling the task pipeline: rate limits, cooldowns and daily versus weekly refresh

* How customers find Podqi: conferences, outreach and referrals

* Two book recommendations: Boys in the Boat and the Foundation Trilogy

Jesse Xu

* LinkedIn: https://www.linkedin.com/in/jesse1xu/

* Podqi: https://podqi.com

* Mentioned in the episode: Boys in the Boat and the Foundation Trilogy, the two books he recommends

Timestamps

00:00:00 Cold Open: "No human should be doing this work"

00:00:57 Introduction

00:01:52 From Patent Law Class to Brand Protection

00:05:31 The Pivot: Patents vs Trademarks

00:07:45 Three-Level Explanation (Baby Shark!)

00:10:02 College Student Level: Fake Everything

00:12:27 Professional Level: Investigative Flows

00:14:52 Working with FBI & Customs

00:15:55 Who Should Know About This Solution

00:18:48 The $2-3 Trillion Problem

00:20:43 Cost Center to Revenue Engine

00:23:27 Technical Architecture Deep Dive

00:26:22 Platform Conflict of Interest

00:29:19 Detection: Classification vs LLMs

00:32:45 Custom Brand Profiles & Fine-Tuning

00:35:47 Precision vs Recall Trade-offs

00:38:01 Hallucination in Brand Protection

00:40:38 Hiring & Team Culture

00:44:06 Technical Challenges & Scaling

00:46:37 Customer Discovery & 70% Referrals

00:49:09 Book Recommendations: Boys in the Boat & Foundation Trilogy

From teaching robots to see to building what he calls the AI data team for every enterprise: Alex Reichenbach did computer vision research, worked briefly at a Yale lab, then at the robotics company Matician, and is one of the founders of Structify, where he is CEO. At the time of this conversation the company was about two years old and, as he tells it, had raised a round of just over $4 million from Bain Capital and 8VC. It began with a family friend who ran a small bank and could not keep track of deal flow. Alex worked as a robotics engineer during the day and on the bank's data at night.

In this episode, Alex joins TwoSetAI to explain "data sets on demand": the feeling, as he puts it, that you can get whatever data you need to make the decisions you want. He shares a saying he likes, that your company has thousands of dashboards but none of them answers the question you need, and describes a head of RevOps asking Structify a question in Slack and getting the answer back in line. The first tool he built for the bank, a tracker of portfolio companies, took him about a month and a half. When he rebuilt it recently on Structify's platform, he says, it took a couple of minutes.

You can learn more about Structify here.

We go deep on how the product keeps its answers reliable. Angelina raises the compounding errors of multi-agent systems, where 5% per step becomes a 40% error rate over 10 steps, and Alex answers that Structify is not a pure multi-agent system: it writes code, and code executes the same way every time. He describes functional tests run against hundreds of queries every night, pipelines that end up as a Polars graph he compares to Apache Spark, and a metadata layer through DataHub in which agents keep column descriptions and governance labels such as GDPR, CCPA and PII up to date and notify the people involved. He is careful about what he promises: not 100% accuracy on every pipeline, but that the system will follow your plan 100% of the time, because a lack of specificity makes accuracy impossible. Pricing is per seat, he says, with large scraping and document jobs passed on at cost.

We also get into the harder parts. Alex says that trying to sell to heads of data was a terrible sales process, and that his favorite fit is legacy industries that have realized they need a data team and never had one. He makes a claim he expects Angelina to disagree with: given tools like Structify, it is easier to teach someone who knows the business processes how to data engineer than to teach a data engineer the business. He wants to compete on accuracy, arguing that if Structify's pipelines are 2% more accurate than its competitors', a bank that picks a competitor is being negligent, and that accuracy has to make it worth spending five times more. He explains why workflow builders all look the same and how he keeps Structify from being taken for n8n, runs a live demo across Slack and HubSpot, and names the one thing the product does not do well, Excel. He wants everyone to feel they have the power of the Citadel data team behind them, and says the biggest thing in the way is people's own belief about what they can do with data.

We discuss:

* What Structify does: "the AI data team for every enterprise"

* The family friend's bank, and the night work that started the company

* A month and a half then, a couple of minutes now: the portfolio tracker

* Pulling SEC filings from EDGAR and enriching them with information from the web

* "Data sets on demand," and thousands of dashboards with no answer

* The customer that ran out of data engineering credits for the quarter

* FDEs, and data scientists re-employed as deployment strategists

* Text to SQL, and the older NLP work that LLMs replaced

* Why selling to data teams did not work, and who the end user is

* Two kinds of head of data

* Learning curves, Slack as the interface, and Angelina's new term: "vibe data engineering"

* What you have to prepare before you bring your data

* An M&A team that used to sort documents by hand

* Finance teams, Excel and keeping the full pipeline from source to finish

* How a pilot starts: compliance, a deployment strategist, then Slack

* Teaching business people to data engineer

* PMs, engineers and wearing more hats

* The 10 month estimate a customer answered by building it on the platform

* Compounding errors, and why Structify writes code

* Competing on accuracy: "2% more accurate"

* What he guarantees: following your plan, not 100% accuracy

* DataHub, governance labels and agents that update the semantic layer

* Per seat pricing, and which costs are passed on directly

* Why workflow tools look the same, and the n8n comparison

* The Citadel data team vision, and self-belief as the biggest blocker

Alex Reichenbach

* LinkedIn: https://www.linkedin.com/in/alex-reichenbach-99055727a/

* Structify: https://structify.ai

* Mentioned in the episode: Polars and DataHub, which he says Structify uses and integrates with; and n8n and Manus, which he contrasts it with

Timestamps

00:00:00 Highlights from this conversation

00:01:13 Introduction & Background

00:02:26 From Robotics to Data Engineering

00:03:05 The 1.5 Months to 2 Minutes Story

00:06:52 What is "Datasets on Demand"?

00:08:32 The Data Engineering Credits Crisis

00:16:36 Coining "Vibe Data Engineering"

00:18:23 Data Preparation & Integration

00:19:29 Finance Teams & Excel Hell

00:23:47 Teach Business People Data Engineering

00:27:47 Why 5% Error Becomes 40% Failure

00:31:54 Code vs. LLM Decision Making

00:35:10 Why All Workflow Tools Look the Same

00:38:20 Slack Demo: Real-Time Data Queries

00:40:56 The Vision: Citadel Data Team for Everyone

00:41:39 The Self-Belief Barrier

From medical images to the footprint of the models themselves: Raghav Selvan trained in signal processing, did his PhD at the University of Copenhagen on machine learning methods for three-dimensional medical images, and has since focused on the sustainability of AI, starting from what it costs in resources. At the time of this conversation he is a computer scientist at the University of Copenhagen and the author of the O'Reilly book Sustainable AI, which Angelina introduces as his new book.

In this episode, Raghav joins TwoSetAI to argue that making AI efficient is necessary but not sufficient. Sustainability, as he lays it out, has three pillars: environmental, social and economic. The recent class of frontier models is built and deployed in hyperscale data centers, which gives it a material footprint he says is not negligible, and which also affects who can build these models at all. His working example is the model card Meta published for Llama 3, and he translates its energy use into a number of people, the comparison on the episode thumbnail.

You can find Sustainable AI here.

We go deep on the costs that sit behind one model. By his account the Llama 3 model card lists 405 billion trainable parameters, 15 trillion tokens of training data and about 31 million GPU hours. Beyond electricity he walks through the energy of the surrounding infrastructure, the fresh water that cooling evaporates, the mining behind the hardware, and the electronic waste left when a data center is refreshed, a cycle he puts at about 5 years. He introduces AI waste, the abundance mindset and its alternative, frugal constraints, and the rebound effect, or Jevons paradox: once attention became cheaper to compute, context windows went from 10,000 tokens to a million, and he says the net effect is that energy consumption has increased.

We also get into the harder parts: why he says sustainability cannot be an afterthought or a side effect of cutting costs, why a grid that runs on renewable energy would not settle the question (he calls this the green energy fallacy), and where regulation stands. By his account some rules that require the energy consumption of frontier AI to be measured and reported are starting to appear in the EU, and he says he has not closely followed the US. For developers he offers small changes: look at how much data a model needs, train at lower precision, schedule jobs that are not time critical for the night, and choose cloud regions with low carbon intensity. Asked how much time there is to act, he says to start today.

We discuss:

* From signal processing and medical imaging to the sustainability of AI

* Statistics, machine learning, AI: what Angelina calls a marketing rebrand

* The three pillars: environmental, social and economic sustainability

* Why the cost of frontier models also shapes who gets to build them

* Efficiency as a necessary but not a sufficient condition

* What Meta's model card for Llama 3 says: parameters, tokens and GPU hours

* The energy of one training run, put in terms of people

* His estimate for data center energy use against the entire African continent

* Hidden costs: surrounding infrastructure, cooling water, mining and manufacturing

* What happens to the electronics after a refresh cycle of about 5 years

* Who needs to know: a multistakeholder, multiscale approach

* AI waste, and why there is no standardized way of measuring it

* The abundance mindset and frugal constraints

* Why sustainability cannot be an afterthought

* Context windows, the rebound effect and the Jevons paradox

* Doing more, not resting more: the rebound effect in everyday work

* What DeepSeek shows about working under constraints

* Easy cuts: data curation, subsampling and low precision training

* Aligning incentives: cost, explainability and the best model for a given cost

* Regulation in the EU, and what he has seen from the US

* What a developer can do: training jobs at night and low carbon cloud regions

* The green energy fallacy

* Why he calls himself an optimist, and his plan for the next 3 years

* "AI is the new electricity," in the sense he means it

Raghav Selvan

* Sustainable AI, his book with O'Reilly: https://learning.oreilly.com/library/view/sustainable-ai/9781098155506/

* Mentioned in the episode: Meta's model card for Llama 3, and the rebound effect, also called the Jevons paradox

Timestamps

00:00:00 What Is Sustainable AI?

00:09:45 How Much Does It Cost to Train Llama 3?

00:11:41 How Much Energy Does One AI Model Use?

00:13:22 Will AI Data Centers Surpass Africa's Energy Use?

00:15:54 How Much Water Does AI Training Consume?

00:18:13 What Happens to Decommissioned GPUs?

00:23:21 Can We Build Powerful AI With Fewer Resources?

00:29:24 Why Does Making AI Efficient Make Climate Change Worse?

00:31:09 Does AI Actually Save Us Time?

00:32:28 How Did DeepSeek Build a Competitive Model Under Constraints?

00:41:08 Can Developers Reduce Their Carbon Footprint Today?

00:46:20 How Much Time Do We Have to Act?

From mechanical engineering to generative AI: at the time of this conversation, Ali Parandeh is head of engineering at an AI and data science consultancy based in London and the author of Building Generative AI Services with FastAPI. He is a chartered engineer with the UK Engineering Council who moved into AI through data analytics, computer vision and rail tech, and he now builds generative AI applications for enterprises. The book, he says, puts what he learned into one resource for anyone who wants to build production grade AI services.

In this episode, Ali joins TwoSetAI to separate what vibe coding is good for from where it gets people into trouble. He does it himself and thinks it makes good engineers faster: a 10x engineer, in his words, becomes a 100x engineer. His caveat is that an agent asked to build a feature makes a lot of architectural decisions for you, and if you do not understand the code you cannot see what it got wrong. He gives a concrete example from a Next.js form that works and is still not safe, and Angelina sums it up: you don't know what you don't know.

You can find the book's site at buildinggenai.com.

We go deep on where the line sits between a prototype and a product. Ali's rule is the 80/20 principle: generative AI can take you 80% of the way there, and the last 20%, the part that makes something enterprise grade, is still your effort. Vibe coding is, by his account, the way to go for prototypes, for a feature you build on a weekend to show users, and for tools you only use yourself. Angelina quotes Simon Willison, who does not count code you have reviewed, tested and understood as vibe coding, and Ali agrees: if you put your name on it, you do the QA. He explains how he used AI on his own book, which he did not let it write. On prompting, he treats a model like a junior intern and uses what he calls the RCT framework: role, context, task. He also shares his stack at the time: FastAPI, Next.js, Postgres, MongoDB, Qdrant, and Azure or Google Cloud, with Go as a backend language he is exploring.

We also get into the harder parts. Asked whether engineers will become obsolete, Ali says AI is both an opportunity and a threat, and that companies still have to develop juniors, because every senior was a junior at some point. Angelina brings up a Gartner prediction that 40% of agentic AI projects will be cancelled by 2027. Ali reads it as a learning curve and names the barriers he sees: chat applications that work on a small number of data sets and hit indexing and scalability issues at millions of documents, missing talent, business cases written by people who do not know the limits of the technology, and data that is not good enough. He argues that the open ground is vertical AI, where there is less competition but you need domain expertise and private data. The last part is security and testing: the vulnerabilities OWASP has cataloged for language models, guardrails on the input and the output side, and the three kinds of behavioral tests he describes in the book.

We discuss:

* Ali's path from mechanical engineering to generative AI, and the book that came out of it

* The Y Combinator stat Angelina cites: 25% of the winter 2025 batch with 95% AI generated code bases

* Why he says vibe coding turns a 10x engineer into a 100x engineer

* The caveat: the agent makes architectural decisions for you

* The Next.js form example, and "you don't know what you don't know"

* The stories he has heard of agents dropping production databases

* What vibe coding is good for: prototypes, pitching investors, a feature built on a weekend

* Why you cannot sell a vibe coded app to enterprises for £100,000 a year

* The 80/20 principle: AI takes you 80% of the way there

* Simon Willison on reviewed and tested code, and "you do the QA"

* Burstiness and perplexity: how human writing differs from AI writing

* Humans as editors: write the outline yourself and let AI draft

* Who owns AI generated work: Suno, licenses and training data

* How he used AI on a book that went from 600 pages to 500

* Junior engineering jobs, and why companies still need juniors

* Alignment, the junior intern, and the RCT framework: role, context, task

* The Gartner prediction that 40% of agentic AI projects will be cancelled by 2027

* Which industries he sees ahead and behind on AI literacy

* AI assisted programming, and AI living within your terminal

* Horizontal against vertical AI, and what he would build

* His stack: FastAPI, Go, Next.js, Postgres, MongoDB, Qdrant, Azure or Google Cloud

* n8n and make.com for automation, and how far they scale

* Security for people coming from data science: OWASP, prompt injection, excessive agency and guardrails

* Behavioral testing: minimum functionality, invariance and directional expectation tests

* Why he calls MCP and A2A patterns, not protocols

Ali Parandeh

* His book: Building Generative AI Services with FastAPI (O'Reilly)

* Book site: https://buildinggenai.com

* Mentioned in the episode: learnprompting.org; OWASP's catalog of vulnerabilities for language models; Simon Willison's view of vibe coding; the Gartner prediction on agentic AI projects, as Angelina cites it

Timestamps

00:00:00 Intro & Ali's Background

00:03:55 Vibe Coding: The 95% AI-Generated Code Reality

00:07:35 When Vibe Coding Makes Sense (and When It Doesn't)

00:17:05 AI as Collaborator: The 80/20 Principle

00:21:22 Will Engineers Become Obsolete?

00:31:41 Why 40% of AI Agent Projects Will Fail

00:39:45 Vertical AI: The Untapped Opportunity

00:45:12 Production Tech Stack for AI Agents

00:51:53 Security & Testing for AI Applications

From an offshore oil rig to 20 years in software: Ahmed Rashad started his career as an offshore oil driller, taught himself to code to solve a problem he had on the rig, and has been in software since. He is the founder and CEO of Perle.ai, which he describes as a data platform for specialized data collection and labeling for AI applications. Dental, medical, robotics and legal are the fields he names.

In this episode, Ahmed joins TwoSetAI to argue that AI will always have a data problem, because the data an application needs gets more specialized as the application gets more sophisticated. Whether we are running out of data depends on the use case, he says: for some there is a lot, for some there is a lot that nobody can get access to, and for some there is not enough that is available, accessible and structured in the right way. He shows what he means by labeling in a live demo. A conversation between a doctor and a patient is transcribed, translated, cleared of personal information and tagged by software, then validated by a human expert who adds the codes, goes through the scans and summarizes the case. In medicine, he says, there is zero error tolerance, and well enough is not good enough.

You can learn more about Perle.ai here.

We go deep on how expert labeling works and what it costs. Ahmed explains why his team asks experts for their own view instead of handing them full instructions, why he encourages some dissent, and why on edge cases it is usually the odd person out who is right. Getting people's judgment takes four things, he says, the right people, tooling, incentives and training, plus one warning: do not treat them like a sweatshop. He sorts error tolerance into three kinds, from a drive-thru or customer support case where 99% is fine to cases where a patient's life is at stake, and he argues for total cost of ownership over the price of a label. In his example, Perle quoted $18 per document against a competitor's $3, and by his account the customer's total cost with the cheaper option came to almost twice Perle's once the extra QA and touch-up work was counted. He adds that it is not uncommon for the cost of a project to drop to a tenth of the initial cost after six months, once the flow is standardized.

We also get into the harder parts: the calls he says tend to come at eight or nine on a Friday or Saturday evening from teams whose release is blowing up over data, why demos built in two or three hours fail miserably in production, and his line that vibe coding does not build products. Angelina brings up research she recalls from MIT on how many AI systems fail in production, and Ahmed says the part that comes down to data is quite significant. He has strong opinions on synthetic data, which he says will not generate exceptions like the ones in a world we do not fully understand. On medicine he says the first objective is not to replace doctors but to make them more productive, and that he thinks AI can double the number of patients doctors serve. He closes on whether experience and wisdom can be labeled, whether the human in the loop can ever be removed, and why he says we need both.

We discuss:

* From offshore oil driller to software: chase the problem

* Why he says AI will always have a data problem

* Arabic, written one way and spoken about 50 ways, and why context changes meaning

* Are we running out of data? His three categories

* Live demo: a doctor and patient conversation, from transcription to expert validation

* Penicillin: an allergy, a current medication or something taken in the past?

* Zero error tolerance in medicine

* Expert context, the Pythagoras example, and when you need a specialist

* Encouraging dissent, and why consensus is not always the right answer

* Who handles day-to-day production and who gets the escalations

* The four things experts need, and why the sweatshop model raises cost

* Three kinds of error tolerance

* Is the objective to replace doctors? Value-add time and doubling the patients served

* Why accuracy drives adoption: who gets sued when the AI makes a mistake

* Self-serve data pipelines, and cost that drops to a tenth

* Total cost of ownership: $18 a document against $3

* When to worry about data labeling: the issue tree, and testing what moves the result

* The 9 p.m. call on a Saturday

* Demos built in two or three hours vs. production

* Synthetic data, simulation and how much of the world we do not understand

* Can experience and wisdom be labeled? The patent example

* Contingency lawyers and the standard demand letter

* Can we eliminate the human in the loop one day?

* Extracting wisdom, not labor, and "we need both"

Ahmed Rashad

* LinkedIn: https://www.linkedin.com/in/ahmed-rashad-perle/

* Perle.ai: https://perle.ai

* Mentioned in the episode: the blog posts on Perle's website, which Angelina says she read, including one on expert context in model training; and the MIT research on AI systems in production that Angelina cites

Timestamps

00:00:00 Introduction

00:02:11 The AI Data Problem

00:09:04 Live Demo of Data Annotation

00:14:00 Expert Context & Human Wisdom

00:28:40 Cost vs. Quality (TCO)

00:41:01 Capturing Experience & Future Vision

From a PhD in reinforcement learning to Google's ads systems, then Google Brain, then startups: Jing Wang has spent his career on the systems that decide what people see. At Google Brain, by his account, he led the work of applying reinforcement learning research to YouTube's home recommendations. At the time of this conversation he is a founder of DeepVista, which builds proactive agents for busy people, especially founders and business owners, and he runs a founder community.

In this episode, Jing joins TwoSetAI to ask the question his years on recommendation systems left him with: is the amount of time people spend on an app the right reward? He describes the project he led to increase how long people stay on YouTube, what his team noticed as the optimization worked, and the weekly review, about 10 engineers and researchers looking at dashboards with something like 300 metrics, where he looked out of the window and started to think about what he wanted to build next.

You can learn more about DeepVista here.

We go deep on personalization, and on why he thinks today's AI applications lost it. Recommendation models used to be small and trained in real time, so everyone's YouTube homepage was different. A large model is the same for every single person and, as he puts it, nobody has the resources to fine-tune GPT-5. He walks through the two-stage recommendation framework (retrieval across billions of candidates, then reranking the hundreds or a thousand that are left) and argues that RAG has the same shape without the learning: the retrieval is the same for everyone and so is the LLM, which by his account leaves no personalization and no data flywheel. His answer is what he calls context modeling: a small personalized model that writes the instructions for the large one, where context engineering relies on rules. He also explains how DeepVista differs from ChatGPT, and what it does first, which is to get a busy person to inbox zero and keep them there.

We also get into the harder parts: why the ads model creates a three-party system whose interests are not fully aligned, and why he says giving a product away to maximize reach does not carry over to AI applications, where the cost of tokens is high. His yardstick is Nvidia's gross margin. While it stays high, he would rather build for a small group of people with high-value problems, and he says he will serve a wider audience when it drops. Jing also talks about impostor syndrome at Google Brain, where he found his place as a translator between researchers and product teams, about signal and noise, and about the philosophy he ended up with: he would rather build a product for 100 people who are smiling than one whose metrics are fantastic while no one is smiling.

We discuss:

* Why DeepVista builds proactive agents for founders and business owners, and the survey figure of 127 messages a day that he cites

* A PhD in reinforcement learning in 2014, Google's ads systems, and the move to Google Brain

* Google Brain as "the Bell Labs of my time", and the impostor syndrome that came with it

* Finding a place as the translator between researchers and product teams

* "Every metric has its own purpose", until it is over-optimized

* The YouTube project that set time spent as the reward for a reinforcement learning agent

* How do you measure whether people are happy? The behavior his team noticed

* The weekly review, the 300 metrics and the view from the window

* Why he moved from the ads model to subscription software

* Why free growth worked when serving a user cost almost nothing, and why he says it does not work when tokens are expensive

* Nvidia's gross margin as his yardstick for when to change strategy

* The electricity comparison, and the first families to have a light bulb

* DeepVista's multi-stage growth plan, starting with founders

* How DeepVista differs from ChatGPT: transactional, not personal, and no task tracking

* The LLM as an interpreter, and the question of who writes the program

* Prompt engineering, context engineering and his own term, context modeling

* How personalization got lost as models scaled

* The two-stage recommendation framework: retrieval, then reranking

* Why RAG works like the retrieval stage of a recommendation system, without the feedback

* Why he says application companies have no data flywheel

* DeepVista in practice: inbox zero, drafts for the messages that need you, and what he says an executive assistant costs

* Signal from noise, and the AI revolution as the "antidote" to the internet revolution

* Why he would rather see 100 people smile than a dashboard of fantastic metrics

Jing Wang

* LinkedIn: https://www.linkedin.com/in/jingconan/

* DeepVista: https://deepvista.ai

* His article on context modeling: https://jingconan.com/2025/07/09/context-modeling-the-future-of-personalized-ai/

Timestamps

00:00:00 Intro

00:00:44 Meet Jing Wang, founder of DeepVista

00:05:19 What was it like working at Google Brain?

00:12:13 Optimizing YouTube recommendations for engagement

00:13:55 How do you measure happiness?

00:18:18 How is that different from the ads model?

00:20:22 How token costs shape go-to-market

00:25:39 How is DeepVista different from ChatGPT?

00:30:23 Context modeling compared with context engineering

00:33:48 The two-stage recommendation framework

00:36:08 LLMs, hallucination and RAG

00:39:55 Are recommendation engines going back to the earlier algorithms?

00:42:09 What does DeepVista look like in practice?

00:48:03 Signal from noise

00:52:05 Two mindsets for building products: metrics and people

00:55:11 Outro

From machine learning at Microsoft, Apple and Facebook, including voice experiences on Siri, to a memory layer for AI agents: Shawkat Kabbara is the CEO of Papr at the time of this conversation. Papr builds what he calls predictive memory. His starting point is that an agent needs to remember the way people do, and that the usual way of giving it memory, storing everything and searching it later, holds up less and less well as the store grows.

In this episode, Shawkat joins TwoSetAI to explain why memory for AI gets worse as you give it more to remember. He introduces retrieval loss, the measure his team built to track the problem, and describes what happens to it as memory grows from 100 million tokens to 10 billion. Then he makes the case for his alternative: where everyone else is trying to engineer the context window, he says, Papr tries to predict the context an agent will need before it asks.

You can learn more about Papr here.

We go deep on how the system is put together. Shawkat walks through an architecture he says is inspired by the brain: a working set memory, an episodic tier that acts as a cache of what an agent has cited before, long-term memory in vector and graph stores, and prediction models that decide which tier a query should hit. He explains why voice agents are one hard test, since by his account a voice agent should respond in 4 to 500 milliseconds and a retrieval pipeline alone can take 500, and why an internal knowledge agent with terabytes of company data is the other. He covers shared memory for multi-agent systems, where he says one hallucinating orchestrator sets off a trickling effect through every sub agent, and custom ontologies that turn unstructured material such as a meeting recording into a graph. He also gives a plain definition of MCP and runs two short demos.

We also get into the harder parts. Angelina presses on what prediction may not reach: in people, long-term memory is tied to emotion, and Shawkat says he is not sure a model can capture that. He is direct about when a memory layer is not needed at all, which is when the data is small, nothing has to be personalized and everything fits in the context window. He names the three layers he would put in a minimal AI stack, says where Papr sits among orchestration frameworks and other memory platforms, and answers whether the space is crowded. He also says in the episode that Papr plans to open source its core retrieval, and that he uses the product himself, with over 22,000 memories stored.

We discuss:

* What Papr is: a memory layer for AI agents

* How people use context at work, and why he says "context is king"

* From prompt engineering to context engineering

* Why giving an agent more to remember can make its memory worse

* The needle in a haystack test, and why real world queries are more sophisticated

* "Everyone's trying to engineer context, but we predict it"

* Working set, episodic and long-term memory, in people and in agents

* Voice agents and the 4 to 500 millisecond budget

* B2B knowledge agents with terabytes of company data

* Multi-agent systems, shared memory and the trickling effect of a hallucination

* Retrieval loss: accuracy, speed and cost in one measure

* The Google research he cites on the limits of embedding dimensions

* What happens to retrieval loss when retrieval is treated as a prediction problem

* A brain-inspired architecture: tiers, neural pathways and eight prediction models

* The episodic tier as a citation cache, and feedback from users and agents

* Custom ontologies, the graph, and how a query is routed between vector and graph search

* What he read about dreaming and how the brain simulates the future

* Emotion and memory, and what today's architectures leave out

* Who Papr is for: developers, vibe coders and generalists

* MCP explained in plain terms

* Orchestration frameworks as partners, and the memory platforms in the same space

* A minimal AI stack: orchestration, the LLM layer and the memory layer

* Two demos: a spoken question answered from memory, and a retrieval loss lookup

* Three choices for a developer: build it, use a memory layer, or skip both

* Positioning: "the best RAG system ever"

Shawkat Kabbara

* Papr: https://papr.ai

* Mentioned in the episode: the Papr blog post on vector search and context, which Angelina quotes; the Google research paper on embedding limits that he cites; and Papr's open source chat app, shown in the demo

Timestamps

00:00:00 Intro & overview

00:01:42 Predictive memory basics

00:03:15 Retrieval vs prediction

00:05:02 Multi-tier memory

00:07:20 Papr memory tiers

00:09:10 Brain-inspired design

00:11:05 Efficient memory storage

00:12:40 Developer use cases

00:14:18 Database integration

00:16:02 Predictive graph models

00:18:10 Feedback loop learning

00:19:45 Predictive graph search

00:21:00 Auto ontology creation

00:22:40 Vector vs graph

00:24:00 Brain parallels

00:26:00 Emotional memory

00:28:00 AI & emotion

00:29:30 Emotion-aware future

00:30:20 Target users

00:31:20 MCP explained

00:32:40 MCP data flow

00:33:30 Memory value

00:34:40 Competitors & market

00:35:30 Building AI stack

00:36:20 Papr in stack

00:37:00 Demo: Retrieval

00:38:20 Auto graph building

00:39:10 Build vs buy

00:40:20 When memory unneeded

00:41:00 Papr positioning

From strategy roles at Meta and TikTok to building AI memory, first for individuals and then for teams: Kisson Lin was the CEO of Tanka at the time of this conversation, and before that a co-founder of Mindverse AI, which she says built an AI agent platform and long-term memory for individuals. By her count she had spent around eight years at Meta and TikTok and four as an entrepreneur. Tanka, as she described it, was a team messenger with long-term memory, a second brain for a team, aimed first at early-stage founders.

In this episode, Kisson joins TwoSetAI to make the case that context loss is one of the biggest pain points a team has, and that it comes from three places: work scattered across tools, people who join and leave, and the things everyone has in mind but never says out loud. Her answer is to put AI where decisions are made, which she argues is the chat, and let it remember what happened there along with the documents, email and meeting notes connected to it.

The product discussed in this episode is Tanka.

We go deep on how memory for a team differs from memory for one person chatting with an AI. Kisson describes combining episodic memory, a vector database and a knowledge graph, putting a timestamp on every piece of memory, and indexing documents so that a question about one PDF goes to that PDF first. She explains why she does not believe a larger context window is the ultimate solution, even if models reach tens of millions of tokens, and why human memory, which keeps events as stories with a subject, a time and an implication, is what her team borrowed from. She walks through features built on that memory: a smart reply that draws on a user's earlier replies and role, an agent that turns a chat into follow-ups and a weekly work report, and agents that draft pitch decks and business plans without a long brief. She also describes a decision engine that she says was still in the lab.

We also get into the harder parts. Team memory, she says, can over-retrieve for managers, who communicate a lot, and under-retrieve for engineers who mostly write code, and no memory design fits every case. Existing benchmarks did not cover team chat, so her team scored accuracy on its own internal use cases. She describes access control, with the AI limited to what each user can already see, sources attached to every answer to limit hallucination, and useful features that went unnoticed because they sat behind a swipe. On the business side she talks about positioning the product as an AI co-founder, the cold start problem of a tool that gets more useful the more a team uses it, whether larger companies will add long-term memory (she thinks they have to), and her picture of AI native software as 3D printing where the earlier generation was Lego.

We discuss:

* Context loss, and the three places she says it comes from

* From Meta and TikTok to Mindverse AI, and from memory for individuals to memory for teams

* Why a team's memory should start in chat: "a lot of decisions are made in chat"

* Implicit context, and how consistent she says our thinking patterns are

* Smart reply with deep thinking, and the hiring decision she had the AI explain to her team

* Capturing ideas and decisions at the time they are made, before anyone writes the document

* How she compares the product's memory structure with other chat and SaaS tools

* The white paper diagram: long-term memory, a decision engine and an agent framework

* AI giving context to people, where today people give context to AI

* Episodic memory, vector database and knowledge graph, and the trade between cost, speed and accuracy

* Agents in the loop: follow-ups, task updates and a weekly work report out of a chat

* The colleague whose to-do list the AI finished before she did

* Why maximizing the context window is not her answer

* Indexing documents so a question goes to the right PDF

* Timestamps, sequences and memory as stories

* The neuroscience research she says the memory design draws on

* What makes team memory harder than one user chatting with an AI

* Over-retrieving for managers and under-retrieving for engineers

* Hidden swipe features, and making the frequently used ones obvious

* Hallucination, sources, structured data and access control

* Benchmarks that do not fit team chat, and scoring on internal use cases

* "AI co-founder" as positioning, and the fundraising agent

* A crowded space, awareness and the cold start problem

* What happens if Notion or Slack build long-term memory

* Lego versus 3D printing, and where she saw the product in three years

Kisson Lin

* Tanka, where she was CEO at the time of this conversation: https://www.tanka.ai

* Mentioned in the episode: the Tanka white paper, whose architecture diagram Angelina shows

Timestamps

00:00:00 Introduction

00:01:30 Founder’s Background

00:02:10 Problem: Context Loss

00:03:29 AI as Second Brain

00:04:03 Why Chat Matters

00:05:05 Deep Thinking Reply

00:06:42 Smart Hiring Example

00:07:33 Capturing Ideas Early

00:10:55 AI Giving Context

00:12:23 Memory Infrastructure

00:15:18 AI-in-the-Loop Workflows

00:17:05 AI Suggests To-Do

00:21:04 Episodic Memory

00:24:12 Neuroscience-Based Design

00:28:48 Team-Level Challenges

00:34:00 Privacy & Access Control

00:36:53 Positioning as AI Co-Founder

00:44:22 Future Vision

From seven years at Google to a 10-person company with millions of users: Coco Mao is the co-founder and CEO of OpenArt, which she describes as a platform for visual storytelling that turns an idea into a visual story. At Google she worked on Google Photos, then built a short video platform inside the company's incubator with her current co-founder, a team of five that she says reached millions of monthly active users before Google Search acquired it. She started OpenArt in 2022. At the time of this conversation she puts it at roughly six to 7 million monthly active users, with a team that was eight people last year and is 10 now.

In this episode, Coco joins TwoSetAI to explain how a team that small grew that fast in a space she herself calls very crowded. Her answer does not open with a growth trick. It opens with an admission: she did not know what she was building on day one, and she says most founders do not. From there she traces the first version, built in less than a week, through the pivots that followed, and names the one trait she sees in the startups in her space that are still alive.

You can try OpenArt here.

We go deep on the product. Coco explains how the most requested feature on the platform, consistent characters, told the team that its users were trying to tell stories, and why video became the format to bet on. She demos one-click story live: a short prompt and a character go in, and a finished video with music comes out a few minutes later, which she says gets a user 80 or 90% of the way there before any fine tuning. She walks through a character vlog, an explainer video and a music video, and explains why the agent plans a story as separate clips, the way a film is shot. The limit was one minute at the time, by choice, with five minutes planned for August. She also describes who pays, Gen AI social media creators and SMBs, and what she heard from the more than 30 users she interviewed the week before, including two ladies from a church in Nashville and a grandmother in New Zealand.

We also get into the harder parts. Coco says she was very anxious about how competitive image generation looked, and that she did not want to stay in a category defined by another company. OpenArt does not train its own models, a choice she says was partly forced and looks right in retrospect. She tells the story of a payroll system switch she regrets as her lesson in not optimizing too early, explains why she listens to users' problems and not their feature requests, and argues that making a decision fast matters more than making the right one. She calls the lean startup leaderboard, which Angelina says OpenArt tops, a vanity leaderboard to some extent, says OpenArt has been profitable for a while, and answers what she would do if someone handed her 10 million tomorrow, how she spends her days, and whether to quit a job to start a company.

We discuss:

* OpenArt in one sentence: a platform for visual storytelling

* Seven years at Google, and a first startup inside Google's incubator

* Six to 7 million monthly active users, and a team that went from eight people to 10

* Why she calls the lean startup leaderboard a vanity leaderboard, and what it does measure

* "Most of the founders, including myself, don't know what we're building from day one"

* The first version: AI images and their prompts on a site built in less than a week

* Why OpenArt does not train its own models

* How requests for consistent characters pointed to storytelling, and then to video

* One-click story: a rough idea in, a video that is 80 or 90% there out

* Live demos: a plush frog's spa day, an explainer video and a music video

* Why the agent plans a story clip by clip, the way films are shot

* The one minute limit, and the plan for five

* Who pays: Gen AI social media creators and SMBs

* Two ladies from a church in Nashville, a grandmother in New Zealand, and creators who would not exist without Gen AI

* Leaving Google, and the gold rush analogy for a crowded market

* "Pinterest for AI images" and the Hacker News post that went viral

* The trait she sees in the startups that survived: fast and iterative

* Launching something you are ashamed of to test product market fit

* From 50k to almost 150k YouTube followers, and how launches changed

* Why making a decision fast matters more than making the right one

* The payroll switch she regrets, and not optimizing too early

* A Discord with over 350k users: listen to problems, not feature requests

* Why OpenArt stayed lean, and what being profitable buys

* Growth drivers over time: SEO, a good domain name and social channels

* What she would do with 10 million, how she spends her day, whether to quit your job, and the next bet

Coco Mao

* LinkedIn: https://www.linkedin.com/in/kechunmao/

* OpenArt: https://openart.ai/

* Mentioned in the episode: OpenArt's one-click story feature; and the lean startup leaderboard, which Angelina cites

Timestamps

00:00:00 Teaser

00:00:50 Intro

00:01:13 Background

00:01:59 Users & Revenue

00:02:41 Lean Startup

00:03:39 What is OpenArt

00:04:53 AI Pivot

00:06:58 Visual Storytelling

00:08:01 Consistent Characters

00:09:27 Demo: Vlog + Music

00:11:04 Live Demo

00:15:20 Democratizing Stories

00:16:15 Video Length

00:16:48 Current Customers

00:17:23 User Stories

00:21:08 Leaving Google

00:22:34 Crowded Market

00:24:00 Early Product

00:25:26 Fast Iteration

00:27:19 Testing Fit

00:29:40 Social Growth

00:30:46 Wrong Decisions

00:34:46 Growth Drivers

00:37:04 Founder Routine

00:40:00 Quit Job?

From AI research at Imperial College in London to building agents for the cases where a mistake is expensive: Yann Bilien is a co-founder of Rippletide and, at the time of this conversation, its Chief Scientist. He says the company started two years earlier on the intuition that agents could reach real autonomy, and that part of the tech stack needed for it was missing. The team built a sales agent first, because sales involves people and you cannot know in advance what they will do, and then began selling the underlying technology to others who build agents. Angelina met him at a Gen AI conference, where he gave a talk about agents in production.

In this episode, Yann joins TwoSetAI to explain why an agent that looks great in a demo so often breaks once real people use it. He puts the cause in one design choice that almost every agent shares today, and borrows a chess player facing a beginner and then an expert to show what changes between the prototype and production. He also shares the first question he asks anyone who wants to build an agent, and what his team does differently for the cases where the usual answer is not good enough.

You can learn more about Rippletide here.

We go deep on the difference between automation and autonomy: a workflow you can write down in advance, and a situation you cannot predict because a human is in it. Yann explains why he sees the AI SDR as the easiest sales agent to start with, and what limits it: by his account the only variable it can improve is volume, at tens of thousands of emails a day. He takes on the trade-off between control and flexibility and argues that it should not be a trade-off at all, because the two belong in different parts of a system. He also argues that data, not compute, is what limits today's language models, quoting a scientist's line that the biggest ones have seen about as much information as a 4-year-old child, and explains why he thinks synthetic data mostly does not solve that. On context windows, he says a one million context window still has issues with attention in the middle, and that retrieval pipelines are usually the bottleneck in a project.

We also get into the harder parts. Yann says evaluating agents is not a solved problem, and that the common answers, an LLM as a judge or a human in the loop, show how hard it is; he advises measuring agents with business metrics. He separates reliability from safety, and says a company should sometimes prefer an agent that does less but protects its brand. On build or buy, he thinks business people have to be involved either way and that a team building in-house has to pick its battles. He does not think smarter models will close the gap between foundational models and real applications soon, expects many agent builders to hit a wall within months, and argues that a company that keeps its people and adds digital workers will beat one that replaces them.

We discuss:

* Why Rippletide started by building a sales agent

* Automation versus autonomy: workflows you can write down, and situations you cannot predict

* Sales agent versus AI SDR, and why he calls AI SDRs a very crowded space

* Why volume is the only variable an AI SDR can improve

* What a self-driving car and an autonomous agent have in common

* Control and flexibility, and why he says it should not be a trade-off

* Why telling a model "don't talk about pricing" in a prompt is not a deterministic guardrail

* Taking the decision away from the LLM: neurosymbolic AI, graphs and rules

* "In the next months": the wall he expects agent builders to hit

* Long-tail questions, and why a demo built in a week breaks in production

* The chess metaphor: playing a beginner versus playing someone experienced

* Vertical reasoning engines that need less data and less compute

* Data, not compute, as the limiting factor, and the 4-year-old child comparison

* Why synthetic data mostly brings no new signal

* "Is 80% enough?": customer success tickets versus an assistant that books meetings

* Where the 80% comes from: a 5% hallucination rate across 10 steps

* What a hypergraph is, with a memory layer and a reasoning layer

* Data drift, LLM as a judge, human in the loop, and evaluating with business metrics

* Context windows, retrieval pipelines as bottlenecks, and "context engineering"

* Reliability versus safety, and an agent that protects the brand

* How work with Rippletide starts, and the high-stakes use cases it is built for

* Build or buy, and what to do with messy internal data

* Will smarter models make production easier?

* Why keeping people and adding digital workers beats replacing them

* Whether agents will ever be fully autonomous

Yann Bilien

* Rippletide: https://www.rippletide.com

* Mentioned in the episode: Rippletide's blog posts on verticalized reasoning engines, which Angelina cites; and the hypergraph approach described on its website

Timestamps

00:00:00 Teaser & Introduction

00:02:44 What is an AI sales agent (and why it matters)

00:03:50 Prediction tasks and sales use cases

00:05:10 Sales agent vs AI SDR

00:06:48 Comparing Rippletide with 11X

00:09:10 What makes autonomous agents different

00:11:20 Determinism in autonomous systems

00:12:57 Guardrails and controls in agents

00:16:30 Key risks: what can go wrong

00:19:10 Decision-making in the pipeline

00:20:25 Vertical reasoning engines vs chain-of-thought models

00:24:35 Achieving 99% accuracy

00:26:55 What is a hypergraph?

00:28:00 Handling data drift in production

00:31:16 Thoughts on context windows

00:34:25 From demo to production-ready systems

00:36:16 Onboarding clients: how to get started

00:37:47 Who are the ideal customer profiles?

00:38:42 Should companies build or buy agents?

00:40:39 Working with internal company data

00:41:50 Will smarter models make production easier?

00:46:45 Will AI agents ever be truly autonomous?