Trajectory Automates Agent Fine-Tuning to Close Model Experience Gap
Sequoia Capital
AI agents fail in domain performance because platforms discard trillions of interaction tokens instead of converting user edits and execution traces into fine-tuning signals.
## Background
This video was published by Sequoia Capital on YouTube on August 13, 2026. It features Trajectory co-founder Arjun Karanam discussing continual learning and how to close the experience gap by converting discarded agent interaction traces into training signals to make AI agents better with every use.
## TL;DR
Arjun Karanam presents Trajectory's approach to continual learning, addressing the 'experience gap' where AI models rapidly gain IQ but lack domain-specific tenure. He outlines four key wishes for the agent ecosystem: full-tree traceability that captures implicit user corrections, production-derived evaluations graded in real harnesses, flexible harness designs that let agents orchestrate primitives, and adopting open-weight models with dynamic routers. He demonstrates Trajectory's automated platform for benchmark import and fast model fine-tuning, followed by a Q&A session addressing privacy via synthetic data, feedback hierarchies, and pushing the capability frontier of agents.
## Atmosphere & style
The presentation is energetic, forward-looking, and technical yet highly accessible, striking a balance between cutting-edge engineering insights and product vision. Arjun speaks with the enthusiastic, pragmatic tone of a founder addressing an audience of peers, grounding abstract AI concepts in relatable analogies like top talent on their first day at work. The Q&A segment shifts to an interactive, collaborative mood as he addresses complex industry challenges like customer data privacy and feedback mechanisms with clarity and confidence.
## Key takeaways
- [01:33](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=93s) Models are rapidly improving in IQ, but they face an 'experience gap' because they lack domain tenure and practical usage experience.
- [02:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=120s) Trillions of tokens generated during agent interactions are currently discarded after use rather than leveraged as training signal.
- [02:52](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=172s) Continual learning requires extracting implicit rewards and specifications from execution traces to update both model weights and the surrounding harness.
- [04:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=240s) Transient facts and dynamically changing information belong in the harness context window rather than baked permanently into model weights.
- [06:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=394s) Full-tree tracing must extend beyond top-level actions to capture sub-agents, tool executions, and implicit user corrections like edits, undos, and retries.
- [08:03](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=483s) Evaluations should be drawn directly from real production traffic and graded inside the production harness to maintain evaluation parity.
- [08:35](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=515s) Modern harness design should shift away from rigid flow-chart constraints toward exposing product primitives and letting agents orchestrate dynamically.
- [09:30](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=570s) Tool interfaces must return rich contextual state and feedback rather than bare status flags so models can learn from execution results.
- [10:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=634s) Transitioning to open-weight models and implementing model routers are critical steps for organizations to own their intelligence layer.
- [16:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=968s) Continual learning can be achieved without violating customer data privacy by using sampled distributions to generate synthetic training datasets.
- [17:13](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1033s) High-confidence user corrections provide explicit reward signals, whereas ambiguous negative feedback serves only as a penalization signal.
- [18:22](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1102s) Universal performance issues should be fine-tuned into global model weights, while individual user or organizational preferences should be routed into the context window.
- [19:37](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1177s) Continual learning is most impactful on the capability frontier, allowing systems to learn from failure points and systematically expand what agents can accomplish.
## Detailed walkthrough
### [00:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=0s) Introduction and the "Experience Gap"
The session closes with Arjun Karanam and Ronak, co-founders of Trajectory, presenting their work on one of the hottest topics in modern artificial intelligence: continual learning. Arjun introduces the core team behind Trajectory, which includes his two best friends: Ronak, who previously worked at Wandb (Weights & Biases) and Scale AI, and Michael, who worked on robotics at Google DeepMind. Together, they are on a mission to build the definitive platform for continual learning.
Setting the stage with their worldview, Arjun acknowledges that while AI models are improving at an astonishing pace—with leapfrogging releases happening almost weekly—their progress is happening primarily along a single axis: IQ. Models are getting smarter, yet interacting with them constantly feels like their "first day on the job." Drawing an analogy to world-class talent, Arjun notes that having a Terence Tao in your pocket is incredible, but Terence Tao on his very first day at an accounting firm probably isn't the best accountant in the room; give him a few days or years, however, and he'll master it. This orthogonal axis of tenure and domain-specific practice is what Trajectory terms the "experience gap."
```
Traditional Paradigm Trajectory's Continual Learning
┌──────────────────────┐ ┌──────────────────────┐
│ Model IQ Focus │ │ Model IQ Focus │
│ (Smarter, but always │ │ + Experience/Tenure │
│ "day 1 on the job") │ │ (Compounds over time)│
└──────────┬───────────┘ └──────────┬───────────┘
│ │
▼ ▼
┌──────────────────────┐ ┌──────────────────────┐
│ Trillions of Tokens │ │ Trillions of Tokens │
│ Thrown Away │ │ Extracted as Signal │
└──────────────────────┘ └──────────────────────┘
```
Closing this gap requires tapping into the massive volume of agent interactions generated daily. Hundreds of millions of tokens are created during real work, only to be discarded after the user acts on them. Trajectory views these discarded traces as crucial signals for training. By capturing this data, agents can evolve from static, slow, expensive, and error-prone bots into dynamic systems that compound in value and become faster, smarter, and cheaper with every single use.
- **Founding Team:** Arjun Karanam, Ronak (ex-Weights & Biases/Scale AI), and Michael (ex-Google DeepMind).
- **Core Concept:** The "Experience Gap"—models are gaining IQ rapidly, but lack domain tenure and practical experience.
---
[02:52](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=172s) From Traceability to Model Specs, Weights, and Harnesses
To convert raw production interactions into continual learning, Trajectory approaches the challenge as both a product engineering problem and a cutting-edge research initiative. The journey begins with total traceability: capturing the complete experience of an agent in action rather than throwing it away.
Once interactions are captured, the next hurdle is defining what the agent *should* do through a formal "model spec." Trajectory conducts research into automatically extracting user interactions, deriving implicit rewards, and turning execution traces into precise specifications. These specifications feed directly into two core surfaces:
1. **The Model:** Fine-tuning base weights via Reinforcement Learning (RL) techniques like SDPO (Step-level Direct Preference Optimization) over long execution traces.
2. **The Harness:** Updating the surrounding execution context or tool layer rather than forcing static facts into model weights.
Arjun emphasizes the necessity of distinguishing between what belongs in the weights versus what belongs in the harness. For instance, if a company gets delisted from an exchange, that fact shouldn't be baked permanently into the model's weights via fine-tuning; it should be provided dynamically as context to the harness. Trajectory's platform provides an end-to-end pipeline that moves from real production interactions to explicit specs, updating both models and harnesses seamlessly.
---
[05:27](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=327s) Wish 1: Full-Tree Traceability and Capturing User Corrections
Reframing the unsolved challenges of building production agents, Arjun imagines having four genie wishes to dramatically accelerate the agent ecosystem toward true continual learning. His first wish focuses on **Traceability**, which contains two critical components:
1. **Full-Tree Tracing:** Most frameworks trace only the main action while discarding intermediate tool calls and sub-agent executions. Complete tree tracing is essential to capture the full context of how an answer was derived.
2. **Eliciting and Capturing Corrective Behavior:** Basic explicit feedback like thumbs-up/thumbs-down ratings are notoriously noisy and unreliable. In complex workflows (like software engineering agents), developers routinely accept multiple code edits without rating them, only realizing five commits later that something broke. The real signal lies in implicit corrective actions—edits, undos, and retries. Products must be intentionally designed to elicit and capture these corrective loops.
> "It's the corrective behavior—the edits, the undos, and the retries—that both need to be elicited from the user, but also captured. So that's my wish on traceability."
---
[07:29](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=449s) Wish 2: Production-Derived Evals Graded in Real Harnesses
Arjun's second wish addresses **Evaluations**. The ideal engineering environment maintains parity across three surfaces: the production product, the evaluation suite, and the training harness. When these three environments diverge, training gains fail to translate into real-world performance improvements.
To achieve robust evaluation, teams must draw test cases directly from actual user traffic—capturing both current usage patterns and edge requests on the frontier of what agents can handle. Furthermore, engineering teams must invest in making every production task replayable ("roll-outable"). Finally, evals should be graded directly inside the actual production harness rather than a simplified mock environment, ensuring that performance benchmarks match reality.
---
[08:35](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=515s) Wish 3: "Let the Agents Cook" with Informative Tool Responses
Arjun's third wish centers on **Harness Design**. Many early agent frameworks were constructed around older, less capable models, acting primarily as rigid guardrails to prevent errors or malformed outputs. Today's frontier models are far more capable, shifting the paradigm to a "let the agents cook" mentality.
```
Old Harness Paradigm Modern "Let Agents Cook"
┌──────────────────────────────┐ ┌──────────────────────────────┐
│ Rigid, over-constrained flow │ │ Flexible orchestration over │
│ control to stop errors. │ │ primitives (search, DBs). │
└──────────────────────────────┘ └──────────────────────────────┘
```
1. **Orchestration over Constraint:** Instead of forcing fixed flow-chart logic, harnesses should expose underlying product primitives (search tools, private database access) and empower the agent to orchestrate them dynamically.
2. **UI and Agent Interface Parity:** Every feature accessible to a human user in the interface should be exposed to the agent via an equivalent tool call.
3. **Informative Tool Feedback:** Tool outputs must provide rich contextual state rather than simple status flags like `"done"` or `"finished"`. If a tool updates a database, returning a bare confirmation gives the model zero feedback signal to learn from during training runs.
---
[10:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=634s) Wish 4: Open Weights, Routers, and Demystifying Post-Training
Arjun's fourth and final wish tackles **Models**. Transitioning to open-weight models isn't as simple as swapping an API endpoint—it involves navigating complex security boundaries, safety protocols, and access provisioning. However, getting comfortable running open weights is the essential gateway to owning model weights and driving domain-specific fine-tuning. Additionally, teams should experiment with dynamic model routers to steer tasks to the most cost-effective tier of intelligence.
Addressing the audience directly, Arjun highlights Trajectory's platform beta, built on the principle that owning intelligence shouldn't require hiring expensive, ongoing external consultancies.
```
Traditional Fine-Tuning Trajectory Automated Platform
┌─────────────────────────┐ ┌──────────────────────────────┐
│ • 50M hyperparameter │ │ • Imports benchmarks (Harvey,│
│ knobs │ VS │ GAIA, etc.) in clicks │
│ • Pure "researcher │ │ • AI Agent handles tuning │
│ intuition" │ │ • Deployable in ~15 minutes │
└─────────────────────────┘ └──────────────────────────────┘
```
During a brief product walkthrough, Arjun demonstrates how easily custom setups can be deployed:
* **Benchmark Import:** Teams can import standard or custom benchmarks (such as LegalBench or Harvey) in a few clicks.
* **Automated Post-Training:** Fine-tuning typically requires adjusting dozens of hyperparameter knobs guided by subjective "researcher intuition." Trajectory abstracts this complexity by running an automated agent behind the scenes to manage low-level knobs, exposing only necessary high-level controls.
* **15-Minute Iteration:** Users can fine-tune, evaluate against previous baselines, compare outputs, and deploy updated models to production in roughly 15 minutes of hands-on time.
- **Core Commitment:** Empowering engineering teams to own their experience layer without relying on external consulting.
- **Workflow:** Import benchmark $\rightarrow$ Automated RL/post-training agent runs $\rightarrow$ Evaluate and compare $\rightarrow$ One-click production deployment.
<FollowUp label="Explore Part 2 for the Q&A on customer data privacy, memory hierarchy, and fine-tuning strategies." query="Please provide the detailed transcript walkthrough for Part 2 of the Sequoia Capital Continual Learning talk by Arjun Karanam."/>
[16:03](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=963s) Continual Learning Without Training on Customer Data
An audience member opens the Q&A segment by bringing up a point raised by previous speakers regarding data privacy: application companies frequently operate under strict customer data arrangements that prohibit training models directly on private user interactions. They ask Arjun Karanam how Trajectory approaches this constraint when building a continual learning system—specifically how to navigate differential privacy and continuously improve models without violating these agreements.
Karanam strongly agrees that privacy is a critical challenge. Drawing on his prior experience at Apple, where privacy-preserving AI was a primary focus, he points out that teams can leverage several clever techniques to avoid training directly on raw customer data. Instead of feeding sensitive text or logs into a model training run, systems can sample distributions from the customer data to synthetically generate synthetic datasets. He compares this concept to a cryptographic check, where the system continuously tests whether its synthetic distributions remain aligned with real-world production data ("on distribution") without ever directly exposing or consuming the underlying customer records. Trajectory is already actively deploying these techniques with its customers to bypass data compliance roadblocks.
- Arjun Karanam previously worked on privacy-preserving machine learning techniques during his time at Apple.
- Instead of direct training, Trajectory samples data distributions and synthetically generates training datasets.
- Synthetic distributions are validated against real data using distribution-matching techniques akin to cryptographic verification.
---
[17:13](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1033s) Episodic Memory and the Feedback Hierarchy
Sid from Finch asks about the role of episodic memory in continual learning. Specifically, when a user performs an action on a platform that actively corrects a previous agent action, Sid asks whether Trajectory takes an opinionated approach on how to handle that feedback to update agent behavior.
Karanam outlines two frameworks for thinking about feedback signals:
1. **Signal Clarity (Negative vs. Corrective):**
- *Ambiguous Negative Feedback:* When a user "flames" an agent, leaves a negative rating (like a thumbs-down), or abandons a session without explanation, the system knows something went wrong, but it lacks a reference for what a successful outcome looks like. In these scenarios, the system penalizes the underlying behavior without enforcing a specific alternative output.
- *High-Confidence Corrective Feedback:* When an agent retries an action and succeeds, or when a user directly edits/corrects an output, the system receives a clear target. Trajectory can assign a high-confidence reward to that specific sequence to reinforce the correct solution.
2. **Feedback Hierarchy (Global vs. User-Specific):**
- *Global Model Updates:* Patterns that are universal across all users—such as an agent repeatedly making incorrect parameters for a specific tool call—belong directly in the model's fine-tuned weights so the model natively learns how to call the tool correctly.
- *User/Org Context:* Highly localized preferences, such as a user demanding, "I never want to use the sub-agent, please don't do it," should **not** be baked into global model weights. Instead, those preferences belong in the context window via the harness. Karanam references earlier discussions from Harvey, noting that this context routing typically operates on a per-organization or per-customer basis.
- Simple user drop-offs or negative ratings act as penalties rather than explicit learning targets.
- Retries and user corrections provide direct, high-confidence reward signals for model updates.
- Universal failures (like broken tool calls) are baked into model weights, whereas user-specific preferences are handled via context in the harness.
---
[19:37](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1177s) Where Continual Learning Matters Most
An audience member observes that building AI products involves balancing cheap, open-source models with frontier closed models. They ask Karanam to outline the specific shape of problems where continual learning offers the biggest performance boost compared to using a statically trained frontier model backed by harness-based context injection.
Karanam explains that while continual learning benefits almost any workflow, its true power shines on the **frontier of capabilities**. He describes how user behavior evolves alongside model capabilities: two years ago, a developer would never have typed a complex, wild query into Cursor because models were not equipped to handle it. Users instinctively test the edges of what a product can do; when it fails, they scale back their expectations and stop trying.
Continual learning disrupts this cycle by closing the failure loop in real time. When users attempt tasks at the outer edge of capability, the system captures those subtle failures, trains on them, and expands the model's capabilities. As a result, the user returns to discover that the agent can suddenly execute tasks that failed previously. This rapid expansion of the capability frontier is what Karanam views as the most exciting promise of continual learning. The session concludes with warm applause from the audience.
- Users naturally restrict their prompt style and expectations to match perceived product limits.
- Continual learning directly targets user failure points on the frontier to incrementally expand what the product can execute.
- The presentation ends at following closing thanks from the Sequoia Capital host.
## Notable quotes
> [05:27](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=327s) It's the corrective behavior—the edits, the undos, and the retries—that both need to be elicited from the user, but also captured. So that's my wish on traceability. — Arjun Karanam
Arjun Karanam, co-founder of Trajectory, argues that while frontier artificial intelligence models are advancing quickly in general intellect, production systems suffer from an 'experience gap' because discarded execution traces prevent agents from acquiring tenure and domain-specific competence over time.
The Experience Gap and Full-Tree Tracing (0:00)
Modern foundational models improve rapidly along an 'IQ' dimension, yet Karanam notes they continually behave as if it is their first day on the job. In real-world enterprise deployments, hundreds of millions of generated tokens and execution traces are discarded after a user acts. Trajectory's thesis is that these discarded interaction logs contain the domain tenure required to turn static, costly agents into systems that compound in value.
Partitioning Knowledge Between Weights and Harnesses (2:52)
Transforming captured traces into continual improvements requires separating permanent behavioral learning from dynamic contextual data. Trajectory uses post-training techniques like Step-level Direct Preference Optimization (SDPO) on execution traces to adjust base model weights for universal patterns, such as learning proper parameters for an application tool call. In contrast, ephemeral or organization-specific facts—such as corporate delisting notices or localized user interface preferences—are preserved in the execution harness or context window rather than baked permanently into model weights.
Engineering Parity and Informative Harness Design (7:29)
To prevent training gains from degrading in deployment, Karanam outlines architectural principles spanning evaluation suites, harness flexibility, and tooling. Robust evaluations require production parity across live products, evaluation suites, and training harnesses, drawing replayable test cases directly from user traffic. Harness design must also shift away from rigid flow charts toward orchestrating primitives, ensuring that agent capabilities mirror user interface features and that tool executions return rich, informative system states instead of bare confirmation flags.
Feedback Hierarchies and Privacy-Preserving Continual Learning (16:03)
User feedback signals vary in quality and require distinct handling. Ambiguous negative signals, such as thumbs-down ratings or user drop-offs, serve as general penalties because they do not indicate the intended outcome. Conversely, implicit corrective behaviors—such as retries, undos, and direct text edits—offer high-confidence reward signals for post-training. Where customer privacy contracts prohibit training directly on private text, Karanam states that teams can sample underlying production distributions to generate synthetic training datasets, validating them through distribution-matching checks akin to cryptographic verification.
According to Karanam, the primary advantage of continual learning lies at the capability frontier: by learning directly from subtle edge-case failures, agents expand what they can handle, counteracting the natural user tendency to scale back expectations when interacting with artificial intelligence tools.
## Background
该视频由红杉资本（Sequoia Capital）于 2026 年 8 月 18 日在 YouTube 平台发布，记录了 Trajectory 联合创始人 Arjun Karanam 在“Own Your Intelligence”活动上的压轴演讲。内容围绕 AI 智能体的“持续学习”（Continual Learning）展开，探讨如何将日常交互中被丢弃的海量 Token 转化为有效信号，帮助模型跨越“空有高智商（IQ）却缺乏工作经验（Tenure）”的经验鸿沟。
## TL;DR
Arjun 指出当前基座模型虽飞速迭代，但每次交互仍像“第一天上班”，必须通过持续学习将交互经验沉淀为系统资产。为此，他面向智能体生态提出了四大愿景：全树追踪并捕捉撤销与修改等高价值修正行为、基于真实流量与真实 Harness 进行评估、让智能体自主编排原语并提供信息量充沛的工具响应，以及主动拥抱开源权重与模型路由。同时，他展示了自动化管理后训练复杂超参数的平台能力，并深入解答了反馈层级划分、隐私保护下的合成数据训练，以及持续学习如何通过捕捉用户失败尝试来不断拓展产品能力边界。
## Atmosphere & style
整场演讲节奏明快、生动务实，既有创业者面对同行的幽默松弛，又不乏来自 Google DeepMind 与 Apple 背景的深厚系统工程洞察。Arjun 擅长用直观绝妙的比喻（如“口袋里的陶哲轩去做会计”、“阿拉丁神灯的许愿精灵”以及现代操作系统的分层存储）拆解极其晦涩的底层技术挑战。现场互动真诚热烈，问答环节直击数据隐私与可训练载体划分等行业痛点，整体呈现出一种立足工程前沿、渴望打破黑盒模型束缚的极客激情与务实探索感。
## Bulletin
- [01:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=60s) 大模型能力正面临严峻的“经验鸿沟”：基座模型的智商（IQ）持续飙升，但每次交互仍像“入职第一天”般缺乏业务年限（Tenure），每天全球交互产生的海量 Token 几乎被随手丢弃，持续学习旨在将这些被浪费的交互转化为模型自我复利的进化飞轮。
- [06:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=368s) 高价值监督信号源自用户的真实纠偏动作而非廉价的点赞点踩，代码回滚、文本撤销、多轮重试等修正行为才是提炼奖励规范的核心依据，系统需完整追踪包含子 Agent 与工具调用在内的完整决策链路。
- [08:35](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=515s) 现代 Agent Harness 应从防范妄想的“防御型工作流”转向“原语编排器”，让高推理能力模型放手调度；同时工具调用必须返回具备丰富上下文的信息，杜绝返回单一“Done”状态码导致的学习信号断层。
- [16:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=968s) 持续学习不需要触碰客户私有明文数据，工程上可通过提取生产交互的底层统计分布并合成脱敏训练样本，结合分布对齐校验在严格差分隐私合规下完成微调闭环。
- [17:13](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1033s) 吸收反馈需建立系统级分层调度机制：全局通用的接口认知与纠错应直接固化进模型底座权重，而组织级规范与用户个人偏好则更适合交由 Harness 或上下文窗口动态注入。
## Key takeaways
- [01:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=60s) 当前 AI 生态存在明显的“经验鸿沟”，即便拥有陶哲轩般的天才智商，进入会计师事务所第一天也无法做好报表，大模型极度匮乏将业务交互转化为工作经验的持续复利机制。
- [02:52](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=172s) Trajectory 构建的持续学习闭环由四大系统层级构成：捕获交互的长轨迹追溯、提炼奖励标准的 Model Spec、基于长轨迹微调的模型层，以及承载事实与规则演进的 Harness 脚手架。
- [06:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=368s) 愿望一之全树追溯：必须完整记录包括派生子 Agent 和全部工具调用在内的完整调用树，仅保存主输入输出将导致后续因果决策链分析完全失效。
- [06:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=394s) 愿望一之捕获修正：传统的“大拇指赞踩”反馈充满噪音，真正决定模型能力进化的黄金信号是用户在多轮交互后发生的编辑、撤回、代码回滚与重试等纠偏行为。
- [07:29](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=449s) 愿望二之真实评测：产品线上环境、评测基准环境与模型训练环境在架构上必须高度统一，Eval 必须直接采样自真实流量，并在沙箱中支持每一个任务的一键重放回测。
- [08:35](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=515s) 愿望三之转变 Harness 角色：早期防守型、强行规定死板步骤的 Harness 会扼杀现代强推理模型的自主潜力，Harness 应蜕变为提供检索和私有数据库等核心原语的编排器。
- [09:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=574s) 愿望三之工具响应信息量：用户在产品 UI 上的全部操作必须与 Agent 的工具调用能力严格对齐，且工具返回必须包含详细数据内容，禁止使用“Done”等无信息量的极简状态码。
- [10:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=634s) 愿望四之拥抱开源权重与路由：实现专有智能闭环必须克服 50 多项安全合规与权限工程挑战以掌控开源权重，并借助模型路由器实现任务复杂度的动态分流。
- [12:36](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=756s) 核心智能资产不应外包给咨询公司：Trajectory 通过自主 Agent 接管复杂的后训练超参数配置与深水区工程，将工程师的实际操作投入时间压缩至约 15 分钟。
- [14:28](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=868s) 持续学习的优化载体是系统级调度问题：权重、Harness 与上下文窗口的关系类似固态硬盘与内存，系统应根据反馈属性自动分配存储介质，而非依赖研究员经验拍脑袋决断。
- [16:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=968s) 借助统计分布采样与脱敏数据合成技术，企业可以在物理上完全不接触、不存储客户敏感明文数据的前提下，实现贴合生产实际分布的高质量持续微调。
- [19:02](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1142s) 构建反馈层级认知（Hierarchy of Feedback）：对所有用户均成立的通用经验应淬炼进基础权重，针对特定组织和个人用户的策略要求则应限制在 Harness 约束或即时上下文中。
- [19:36](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1176s) 持续学习最核心的突破点在“能力边界（Frontier）”任务：当用户因模型“勉强出错”而退缩放弃时，持续捕获这部分边缘失败样本并进行定向迭代，能持续拓宽产品的新能力边界。
## Detailed walkthrough
### [00:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=0s) 介绍与 Trajectory 的愿景：构建持续学习平台
红杉资本（Sequoia Capital）活动的主持人介绍最后一场压轴演讲的嘉宾——来自 Trajectory 的联合创始人 Arjun Karanam 与 Ronak。他们正在围绕当前 AI 领域最火热的方向之一——**持续学习（Continual Learning）**展开前沿研究。Arjun 登台后幽默地表示，自己作为全场倒数几位出场的分享者，非常希望台下观众还保留着注意力，同时也向坐在后排的联合创始人 Ronak 打了个招呼。
Trajectory 的核心使命非常明确：**构建用于 AI 智能体持续学习的基础平台**。Arjun 动情地谈到，自己最开心的部分莫过于能与两位最好的朋友一起并肩创业：一位是曾在 1X 负责仿人机器人学习平台和机器人大脑（World Model）训练的 Ronak；另一位则是曾在 Google DeepMind 研发顶尖机器人的 Michael。团队希望用底层系统性思考来解答一个根本性问题：为什么当前 AI 智能体虽然飞速迭代，但体验依然存在巨大的断层？
```mermaid
flowchart LR
accTitle: Trajectory 核心闭环架构
accDescr: 展现从用户交互追踪到模型规范，再到模型与 Harness 双重迭代的完整流程。
subgraph Capture["1. 数据捕获"]
A["生产环境交互 Trace"] --> B["用户修正行为<br/>(撤回/修改/重试)"]
end
subgraph Spec["2. 行为规范"]
B --> C["Model Spec<br/>提取奖励与执行标准"]
end
subgraph Iterate["3. 双轨演进"]
C --> D["模型微调<br/>(RL / SDPO)"]
C --> E["Harness 演进<br/>(上下文 / 事实注入)"]
end
Iterate --> F["快速部署并持续复利"]
```
---
### [01:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=60s) 经验鸿沟：模型空有智商（IQ），缺乏工作年限（Tenure）
Arjun 指出，当今人类正处在一个令人惊叹的历史节点上，几乎每周都会有新的前沿基座模型横空出世，在基准测试上将上一代碾压倒地。模型的能力无疑在指数级飙升，然而这种能力的提升几乎完全集中在一个单一维度——**智商（IQ）**。
现实中当你与这些大模型对话时，永远会有一种诡异的感觉：**"每次交互都像它们入职第一天（It always feels like their first day on the job）。"** 为此，Arjun 提出了一个生动的类比：
- 想象一下，你的口袋里揣着当代数学大师陶哲轩（Terence Tao），这固然惊人；
- 但是，如果让陶哲轩第一天直接去一家会计师事务所当记账员，他大概率绝不是全公司最出色的会计；
- 只有给他几天甚至几年的职场时间去熟悉业务流水、流程规范与具体上下文，他那超凡的智力才能转化为极高的业务输出。
在智商之外，存在着一个正交且至关重要的维度——**经验（Experience）**。智商与经验的断裂，正是 Trajectory 试图跨越的**经验鸿沟（Experience Gap）**。
经验从何而来？每天全球由 AI 智能体生成的数以亿计甚至万亿级的 Token，大部分在用户扫一眼或者根本不看的情况下，就被随手丢弃并清空了上下文。然而，这些 Token 代表着真实的业务探索与人类的应对反馈。人类之所以能越来越强，核心就在于能从经验中形成心智模型并持续迭代，而当今的智能体在投入使用后不仅速度慢、成本高、频繁出错，而且根本不会随着使用变聪明。Trajectory 坚信，如果将这些交互信号充分吸收，AI 系统将达成两大直接收益：
1. **立即获得更快、更强、更廉价的模型；**
2. **构建随使用频次实现自我复利（Compound with use）的进化系统。**
---
### [02:52](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=172s) 闭环系统：从可追溯性到 Model Spec，再到模型与 Harness 的解耦
构建持续学习的商业平台必须与深度的前沿科研紧密结合。Arjun 梳理了团队从交互信号迈向智能体升级的四大系统层级：
1. **可追溯性（Traceability）：** 捕获过去被丢弃的所有交互轨迹，这是让系统沉淀经验的第一步。
2. **模型规范（Model Spec）：** 如何将用户杂乱的交互转化为对智能体的显式约束与奖惩？Trajectory 正在研发专门的算法，能够从调用轨迹（Traces）中提炼奖励信号，转化为智能体到底应该做什么的精确规格。
3. **模型微调（Models）：** 运用强化学习（如 SDPO 等算法），利用完整长轨迹（Full long traces）对基座权重进行训练，使模型在决策与策略上实现自我进化。
4. **测试框架与脚手架（Harnesses）：** 并非所有经验都该塞进模型权重中。团队深入研究了反馈信号的分配逻辑：
- 如果是一条**事实性变动**（例如某家上市企业已被摘牌退市），这类知识不应该重新预训练或微调进权重，而应作为上下文动态提供给 Harness；
- 算法和行为决策层面的习惯，才真正适合下沉进模型。
通过连接“真实轨迹 → 规范制定 → 模型优化 → Harness 完善 → 极速重新部署”，Trajectory 试图打造让智能体能够闭环迭代的工作台。随后，Arjun 幽默地将自己比作从《阿拉丁》神灯里钻出来的精灵，由于智能体落地的每个环节都充满痛点，他针对整个智能体生态系统提出了**“四个愿望”**，分别对应追溯、评测、Harness 与模型。
---
### [06:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=368s) 愿望一：全树追溯并捕捉撤销、修改等修正行为
在可追溯性（Traceability）维度上，Arjun 许下了两个具体的细分愿望：
- **愿望 1.1：追踪完整的调用树（Trace the whole tree），切勿遗漏子智能体与工具调用。**
当前大多数公司仅仅保存用户发出的指令和智能体最终给出的主响应，中间衍生的工具调用（Tool calls）以及子智能体（Sub-agents）的多层派生链路都被直接丢弃。缺失了中间过程的决策链路，后续训练根本无法分析因果关系，使得模型无法真正从历史长轨迹中吸取教训。
- **愿望 1.2：别沉迷于点赞/点踩，真正有价值的是用户的修正行为（Corrective behavior）。**
Arjun 直言，很多产品的交互设计还停留在第一阶段——试图放一个“大拇指向上/向下”来收集反馈。这种显式反馈在实际业务中充满噪音。以代码智能体为例：开发者在写代码时往往会习惯性一键接受智能体生成的所有补全，直到提交了 5 次 Commit 之后，才突然发现“糟糕，整个项目全被搞挂了！”，随后才火急火燎地回滚并修正代码。
因此，真正高价值的监督信号不是廉价的点赞，而是用户在后续发生的**编辑（Edits）、撤销（Undos）、重试（Retries）以及回滚**。优秀的产品架构不仅要能精准捕捉这些修正动作，更要在交互界面上有意识地诱导（Elicit）并沉淀此类纠偏数据。
---
### [07:29](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=449s) 愿望二：评测应源自真实流量，并在真实的 Harness 中评测
第二个愿望聚焦在**评测（Evals）**机制上。Arjun 提出了一条至关重要的心智模型准则：
> **“用户使用的实际产品环境、评测所在的环境、以及模型训练所在的环境，这三者在架构上越接近越好；在理想世界中，它们应当完全同一、毫无二致。”**
针对当前的评测脱节问题，Arjun 提出了三个技术诉求：
1. **评测基准必须直接从生产流量中抽取（Drawn from traffic）：** 评测数据集不应只是合成的玩具用例，而应直接反映用户当前的实际用法，甚至包含用户在边界能力探索时那些目前还无法满足的前沿请求。
2. **让每一个任务都具备可回放性（Every task roll outable）：** 这在基础设施层面是一个极具挑战的工程难题，但如果平台能够完整录制并在沙箱中一键重放（Replay）用户与智能体的交互上下文，将成为智能体演进的巨大助力。
3. **在真实的 Harness 中打分：** 严禁使用一套简化版、玩具版的离线评测 Harness，评测打分必须跑在用户线上真正交互的生产环境 Harness 之上。
---
### [08:35](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=515s) 愿望三：让智能体放手去干，把 Harness 转变为原语编排器
谈到第三个愿望——**Harness（脚手架系统）**的设计时，Arjun 指出了目前行业普遍存在的设计过时问题。许多团队的 Harness 架构仍然是按照一年或一年半之前的落后模型来定制的：
- **老一代 Harness 的核心逻辑是“防御”：** 当时的模型极易崩溃、产生格式错误的无效输出或出现严重的妄想，因此 Harness 的首要目标是严格设限、防止模型乱来；
- **新一代系统的逻辑应当是“让智能体放手去干”（Let the agents cook）：** 现阶段的模型推理能力已大幅提高，如果 Harness 依旧强行设定死板的工作流（Specific flows），反而会死死束缚住智能体的自主能力。
现代 Harness 的正确定位应该是**原语编排器**。开发者应当专注于厘清自己产品具备的核心原语（Primitives）——比如内部检索工具、专有数据库或私有信息接口，然后放手让智能体去自由调度、组合与编排这些原语。此外，智能体与底层工具交互的接口格式，应该尽可能向人类面对的用户界面（UI）靠拢，赋予智能体与人类同等的感知和操作灵活度。
### [09:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=574s) 愿望三续：提供信息量充足的工具响应与 UI 对齐
在探讨如何构建理想的 Agent 运行环境（Harness）时，Arjun 提出了一个核心原则：凡是用户能在产品 UI 上完成的任何操作，Agent 也必须能通过工具调用（Tool Call）完整复现。这种 UI 与工具调用的严格对齐，能够让后续的训练和持续学习（Continual Learning）变得极其简单顺畅。
此外，工具调用的响应内容绝不能流于形式。在工程实践中，很多系统在 Agent 调用搜索或数据库写入工具后，仅简单返回一个状态码或干瘪的单词，比如冷冰冰的“Done”（已完成）或“Finished”（已结束）。从表面上看，返回操作成功似乎足够了，但从 Agent 的认知与推理视角来看，这种黑盒反馈“令人极其困惑”。更严重的是，当开发者试图基于这些交互轨迹进行后训练（Post-training）或持续学习时，这种缺乏上下文的响应几乎没有提供任何可供学习的有效信号——系统无从得知数据库究竟写入了什么内容，也无从判断读取到了哪些实体信息。因此，保证工具调用响应具备丰富的信息量（Informative tool responses），是构建健壮 Harness 的关键收尾环节。
- **UI 与工具能力对齐**：用户界面上的每一项交互，Agent 都应具备等价的工具调用能力，从而简化交互数据的学习路径。
- **杜绝单薄状态码**：工具返回不能仅局限于“Done”或“Finished”，必须包含具体读写的数据内容和明确的上下文状态，为模型提供高密度的强化学习与微调信号。
---
### [10:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=634s) 愿望四：拥抱开源权重与模型路由机制
按照传统习惯，许愿通常只有三个，但 Arjun 笑着打破常规，抛出了第四个愿望——直面模型层本身的演进。他直言，切换到开源权重（Open-weight models）远非在代码里改一行参数那么简单；真正实操过的开发者都清楚，背后牵涉到安全性、合规风控、访问控制编排（Access provisioning）等 50 多项严苛的工程考量。即便如此，团队仍需尽早熟悉在开源权重上运行生产系统，因为这是实现“拥有自身智能模型权重”，并在其上持续迭代积累经验的唯一通道。
与开源权重并行的另一大关键趋势是模型路由器（Model Routers）。正如当天稍早时演讲嘉宾 Gabe 所强调的那样，未来生产系统不可能由单一模型通吃，路由器将在调度机制中扮演核心角色，负责将具体任务的复杂度精准分发给具备对应能力与成本效益的模型。因此，在架构中大胆试验模型路由，是实现持续学习系统不可或缺的基础设施建设。
```mermaid
flowchart TD
accTitle: 持续学习的四项基础设施支柱
accDescr: 展示从Trace、Eval、Harness到Open Weights与Router的完整落地链条
subgraph Traceability["可追踪性 (Traceability)"]
T1["追踪完整调用树与子 Agent"]
T2["捕获人工修改与重试纠错"]
end
subgraph Infrastructure["运行环境与评估 (Harness & Evals)"]
E1["源自真实流量的真实 Eval"]
H1["丰富信息量的工具返回"]
H2["UI 交互与工具调用完全对齐"]
end
subgraph ModelLayer["模型与路由层 (Model Layer)"]
M1["开源权重自主可控 (Open Weights)"]
M2["模型路由器 (Model Router) 智能分流"]
end
Traceability --> Infrastructure
Infrastructure --> ModelLayer
ModelLayer --> CL["持续学习飞轮 (Continual Learning)"]
```
- **开源权重的工程门槛**：涉及权限、安全沙箱等数十项繁杂配置，但掌控权重是企业沉淀自有智能资产的前提。
- **任务路由普及化**：通过模型路由器实现能力按需匹配，根据任务属性动态分派给专有小模型或前沿大模型。
- **现实审计与应对策略**：Trajectory 在服务客户时首先审计这四项维度的就绪度。针对大多数企业缺少 Eval 基准或链路追踪不全的现实困境，团队正通过前沿科研探索在“零 Eval”或“追踪缺失”的弱信号条件下抽取训练信号的方法。
---
### [12:36](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=756s) 掌握核心智能：15 分钟完成模型导入、训练与部署
Arjun 强调了 Trajectory 最核心的产品信念：企业拥有属于自己的智能系统，绝不应该是不得不依赖外部咨询团队来交付的事情。由于智能层直接决定了产品的核心竞争力，这项专业能力必须掌握在企业自己手中。为此，Trajectory 开发了一套旨在让所有公司都能基于真实交互实现模型自主迭代与持续学习的平台。
现场展示的产品 Demo 中，Arjun 提前向现场观众曝光了即将向投资人展示的平台界面：
1. **基准无缝导入**：一键导入外部公开评测或专有基准（如法律 AI 独角兽 Harvey 的专属评估集，以及 Gabe 提及的各项基准测试）。
2. **AI Agent 代劳后训练旋钮**：后训练传统上是一个门槛极高、极易出错的领域，充斥着“5000 万个可能出错的坑”和“5000 万个需要精细微调的超参数”，高度依赖所谓的“研究员直觉（Researcher intuition）”。Trajectory 将内部顶级研究员的训练经验封装进后台 Agent，由 Agent 自动管理绝大多数底层旋钮，前端仅暴露关键必要决策。
3. **高效端到端闭环**：开发者完成配置后，除模型实际跑训练的时间外，工程师真正投入的肉身操作时间“大约只有 15 分钟”，即可顺畅走通模型训练、效果分析、对照评估与生产部署全流程。
---
### [14:28](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=868s) Q&A：持续学习的优化载体到底是什么？
在问答环节，有观众犀利提问：在谈论持续学习时，真正的“可训练对象（Trainable object）”到底该放在模型权重、Harness、工具集还是应用层代码上？面对这些纷繁的载体，团队应该如何排列优先级？
Arjun 幽默地回应：“如果你去问六个研究员什么是持续学习，你大概会得到七种截然不同的答案。”学院派纯粹主义者可能坚持模型必须像人类大脑一样，只依靠权重在线实时进行单样本（One-shot）自适应；但 Trajectory 的工业界视角截然不同——驱动产品的智能本质上是一个包含多层组件的完整**系统**。真正的持续学习，应当在这个复杂系统中全局寻找最优解，并根据新流入信息的性质，智能决定应该更新系统的哪一个部分。
他借用现代计算机存储分层架构打了个绝妙的比方：今天编写代码保存数据时，开发者早已不需要手动指定要把数据写进内存条的哪个地址、还是固态硬盘的哪条磁道，操作系统已经将存储介质透明化抽象了。模型权重、Harness 配置与上下文窗口（Context）三者之间的关系亦是如此。当前全行业必须依赖极其匮乏的先验经验，手动拍脑袋决定某项反馈是该写进 Prompt、改 Harness 规则还是重新刷模型权重，这种状态是落后的。这本质上是一个可以通过科学方法解决的系统调度问题，未来的平台会将其完全底层抽象化。
---
### [16:08](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=968s) Q&A：不触碰客户敏感数据如何实现持续学习？
现场另一位观众就数据安全提出关键顾虑：许多演讲者都强调千万不能用客户私有数据训练模型，但持续学习又必须不断从人机交互中汲取养分，在严格的数据隔离与差分隐私（Differential Privacy）诉求下，系统该如何跨越这条鸿沟？
Arjun 透露，在创立 Trajectory 之前他曾就职于 Apple，在那里长期深耕过同类隐私计算难题。他指出，持续学习并不等同于将原始客户数据直接一股脑塞进微调数据集。工程上有许多巧妙的架构解法：
- **无感分布采样与合成生成**：系统并不直接截取客户敏感的对话原文，而是提取其底层的统计分布与交互行为模式（Sampling distributions），随后以此为依据在隔离环境中通过合成数据技术（Synthetically generating）生成完全脱敏的自有训练数据。
- **密码学式的分布对齐校验**：类似密码学校验机制，利用统计对比验证合成数据是否完美贴合生产分布（On distribution），从而在物理上完全不触碰、不存储客户私有明文数据的前提下，实现模型能力的闭环强化。
---
### [17:13](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1033s) Q&A：情境记忆与不同反馈类型的层级响应
来自 Finch 的观众 Sid 提问，探讨情境记忆（Episodic memory）在持续学习中的角色：如果终端用户在平台上纠正了 Agent 刚才的某个错误行为，这种修正应如何反馈回系统？Trajectory 对此有何设计偏好？
Arjun 分享了系统对待反馈信号的两种解构维度：
第一种维度是**明确奖惩信号与模糊负反馈的区分**。如果用户只是愤怒地喷一句“你做得太烂了”，或者默默点了个踩、甚至直接关掉网页，系统只能确切获知“出了差错”，却无法得知“什么是正确答案”。面对这种信号，系统只能施加惩罚以降低对应策略的出现概率。相反，如果是 Agent 在遇到挫折后重试并最终跑通，或者是用户给出了具体修正并指出“应该这样改”，系统就拥有了高置信度的正向奖励（Reward）和标准解，能够精准调整模型策略。
第二种维度是**知识价值的受众层级划分**。反馈信息在普适性上存在严密的分级：有些知识是“全局通用真理（Globally accurate）”，例如调用某个具体外部 API 时的特定格式陷阱或高频崩溃 bug。这种工具调用层面的通病对所有用户一视同仁，就不应该仅仅作为个别用户的情境记忆驻留，而必须直接淬炼沉淀并训练进模型权重（Train into the model），从而彻底提升基础模型掌控该工具的底层通用能力。
### [19:02](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1142s) 反馈的层级结构：模型权重与上下文的分工
在探讨系统如何吸收用户反馈时，Arjun 举例说明了区分处理层级的重要性。假设某个特定用户强烈表示：“我绝对不想使用子智能体（sub-agent），拜托千千万万别用。”这种高度个性化的偏好显然不属于应当直接训练进模型底座权重的内容，而更应该保留在上下文（Context）中动态调整。
Arjun 指出，正如前面 Harvey 团队所分享的经验，许多反馈和规则其实是针对特定组织机构（per org）甚至是特定客户（per customer）生效的。因此，在构建系统时必须建立清晰的“反馈层级认知”（Hierarchy of Feedback）——明确评估某条反馈究竟是适用于全量模型的通用行为改进，还是属于企业级策略，亦或仅仅是单一用户的个性化配置，进而决定将其写入权重、放入治理框架（Harness），还是注入即时上下文。
- **组织与客户隔离**：用户层面的个性化指令与特定企业的定制偏好，更适合作为 Harness 或上下文层面的约束，而非直接微调模型底座。
- **反馈适用范围**：通过明确反馈的作用域，团队可以避免将局部的、冲突的单点用户喜好误作为泛化能力训练到全局模型权重中。
---
### [19:36](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1176s) 持续学习的用武之地：在能力边界拓展产品前沿
现场观众提出疑问：在当下的产品实践中，往往有些任务适合采用开源模型降低成本并快速实验，而核心环节则依赖最先进的闭源前沿模型；如果将这种划分延伸到持续学习领域，究竟什么样的任务和业务形态最需要持续学习，又有哪些场景仅凭“静态训练的模型配合 Harness 上下文注入”便已足够？Arjun 认为，虽然广义上绝大多数任务都能从持续学习中受益，但他个人最看好的，是那些始终处于“能力边界前沿”（on the frontier）的任务。
Arjun 分享了他理解 AI 演进的心智模型：用户在使用产品时，往往基于自身对产品能力的预期发起请求；大家总会在产品能力的边缘反复试探，一旦发现模型失败或出错，就会立刻退缩并得出结论——“这东西还不够好，我没法用它干这个”。正如两年前开发者面对代码编辑器 Cursor 时，“根本不敢想象输入现在这种天马行空的复杂查询”。然而随着底座能力提升，用户的试探尺度也逐步放大。持续学习最迷人的地方在于，当用户尝试让模型做某件事而模型“几乎做不到”（barely do it）时，系统能够捕获这一交互并通过训练学会该能力，让用户下次顺利完成此前无法做到的任务。这种基于用户失败尝试不断拓展能力边界的正向循环，正是持续学习的核心价值所在。
```mermaid
flowchart TD
accTitle: 持续学习拓展能力前沿的工作流
accDescr: 展示用户在能力边缘发起请求、系统捕获失败交互、持续训练并最终突破前沿的循环链路。
subgraph UserInteraction ["用户行为与前沿试探"]
A["用户在前沿边界发起复杂请求"] --> B{"模型能否顺利完成？"}
B -- "超出当前能力 / 勉强出错" --> C["用户退缩并降低预期"]
end
subgraph ContinualLoop ["持续学习闭环"]
C -. "交互轨迹与错误被捕获".-> D["针对失败样本进行定向训练"]
D --> E["模型吸收经验并掌握新能力"]
E --> F["拓展产品能力边界 (Push Frontier)"]
end
F -. "再次激发更高级尝试".-> A
```
- **预期的退缩效应**：当用户在产品边缘遭遇失败时往往会放弃尝试，若仅依靠静态模型，这类未被满足的需求就会永久流失。
- **动态推高边界**：持续学习将“用户尝试但无法完成”的边缘案例转化为训练信号，让模型在实战交互中跨越鸿沟，使用户解锁全新工作流。
## Notable quotes
> [01:00](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=60s) 每次交互都像它们入职第一天（It always feels like their first day on the job）。 — Arjun Karanam
> [07:29](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=449s) 用户使用的实际产品环境、评测所在的环境、以及模型训练所在的环境，这三者在架构上越接近越好；在理想世界中，它们应当完全同一、毫无二致。 — Arjun Karanam
> [08:35](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=515s) 老一代 Harness 的核心逻辑是“防御”……新一代系统的逻辑应当是“让智能体放手去干”（Let the agents cook） — Arjun Karanam
> [09:34](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=574s) 凡是用户能在产品 UI 上完成的任何操作，Agent 也必须能通过工具调用（Tool Call）完整复现。 — Arjun Karanam
> [12:36](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=756s) 企业拥有属于自己的智能系统，绝不应该是不得不依赖外部咨询团队来交付的事情。 — Arjun Karanam
> [14:28](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=868s) 如果你去问六个研究员什么是持续学习，你大概会得到七种截然不同的答案。 — Arjun Karanam
> [14:28](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=868s) 驱动产品的智能本质上是一个包含多层组件的完整系统。真正的持续学习，应当在这个复杂系统中全局寻找最优解，并根据新流入信息的性质，智能决定应该更新系统的哪一个部分。 — Arjun Karanam
> [19:36](https://www.youtube.com/watch?v=eYrMF9Cht8A&t=1176s) 这东西还不够好，我没法用它干这个 — Arjun Karanam
## Mentioned
Trajectory, Arjun Karanam, Ronak, Michael, Sequoia Capital, 1X, Google DeepMind, Terence Tao, Harvey, Apple, Finch, Sid, Cursor, Gabe
## Video description
Today's AI models keep getting smarter, but every conversation still feels like their first day on the job. Trajectory co-founder Arjun Karanam calls this the experience gap: models are improving on IQ, but not on experience. Continual learning aims to close it, turning the trillions of tokens of agent interactions that get thrown away into signal that makes agents better with every use.
At Sequoia Capital’s Own Your Intelligence event, Arjun lays out four goals for companies that want to get there: full traceability (including sub-agents and corrective behavior like edits and retries), evals drawn from real production traffic, harnesses that let agents orchestrate rather than constrain them, and getting comfortable running on open weights. He also covers what should be trained into the model versus left to the harness, and how to learn from interactions without training on customer data.
00:00 Introduction
00:12 Building the platform for continual learning
01:33 The experience gap: models have IQ but no tenure
02:52 Traceability → model spec → better models and harnesses
05:27 Four wishes for the agent ecosystem
06:34 Wish 1: Trace the whole tree — and capture the corrections
08:03 Wish 2: Evals from real traffic, graded in the real harness
09:26 Wish 3: Let the agents cook, and make tool responses informative
10:34 Wish 4: Get comfortable on open weights, experiment with routers
11:51 Why owning your intelligence shouldn't be consulted away
13:15 Demo: import a benchmark, train a model, deploy it
14:28 Q&A: What's the trainable object — weights, harness, or context?
16:08 Q&A: Continual learning without training on customer data
17:13 Q&A: Episodic memory and the hierarchy of feedback
19:37 Q&A: Where continual learning matters most
[Source](https://www.youtube.com/watch?v=eYrMF9Cht8A)
Source quotes
[1:00] Arjun Karanam: 每次交互都像它们入职第一天（It always feels like their first day on the job）。
[7:29] Arjun Karanam: 用户使用的实际产品环境、评测所在的环境、以及模型训练所在的环境，这三者在架构上越接近越好；在理想世界中，它们应当完全同一、毫无二致。
[8:35] Arjun Karanam: 老一代 Harness 的核心逻辑是“防御”……新一代系统的逻辑应当是“让智能体放手去干”（Let the agents cook）
[9:34] Arjun Karanam: 凡是用户能在产品 UI 上完成的任何操作，Agent 也必须能通过工具调用（Tool Call）完整复现。
[12:36] Arjun Karanam: 企业拥有属于自己的智能系统，绝不应该是不得不依赖外部咨询团队来交付的事情。
[14:28] Arjun Karanam: 如果你去问六个研究员什么是持续学习，你大概会得到七种截然不同的答案。
[14:28] Arjun Karanam: 驱动产品的智能本质上是一个包含多层组件的完整系统。真正的持续学习，应当在这个复杂系统中全局寻找最优解，并根据新流入信息的性质，智能决定应该更新系统的哪一个部分。
[19:36] Arjun Karanam: 这东西还不够好，我没法用它干这个
Source quotes
[5:27] Arjun Karanam: It's the corrective behavior—the edits, the undos, and the retries—that both need to be elicited from the user, but also captured. So that's my wish on traceability.
Original transcript
[0:00] Okay, last talk to bring us home, we
[0:01] have Arjun and Ronak, co-founders of
[0:03] Trajectory. They're doing a bunch of
[0:05] interesting research around what I think
[0:07] is one of the hotter topics, continual
[0:09] learning.
[0:10] Please welcome Arjun to the stage.
[0:12] >> Cool. What's up? How's it going
[0:14] everyone?
[0:15] Thank you so much. I'm really excited. I
[0:18] know I'm close to the last one, so
[0:19] hopefully there's like remaining
[0:20] attention span.
[0:22] I'm here. Ronak is also back there. So
[0:25] we're together.
[0:26] But let's get started.
[0:29] We're Trajectory and we're building the
[0:31] platform for continual learning.
[0:35] Who are we? I think we're working on
[0:36] like a really really cool mission and
[0:39] that's the most fun part. The second
[0:40] most fun part is I get to do this with
[0:42] my two best friends. Ronak over here
[0:44] worked at One Surf and Train Speed 1
[0:45] before this and and Michael who worked
[0:47] on really cool robotics stuff at at Deep
[0:49] Mind. And what I wanted to start off
[0:52] with was the world view that we have
[0:56] and how that shapes
[0:58] why we think this problem is important.
[1:00] And so the world view that we have is
[1:02] that and it's not a hot take, we are
[1:04] living in an incredible time in human
[1:06] history here. Every single week it seems
[1:09] like another model is coming out that is
[1:11] leapfrogging the last one.
[1:14] It's undeniable that models are getting
[1:15] better and better.
[1:16] But we think that they're getting better
[1:18] on one axis and that is
[1:22] IQ. These models are smarter and smarter
[1:24] but always feels like when you're
[1:25] talking to them, it's their first day on
[1:27] the job. And so you take this analogy if
[1:30] you have a Terrence Tao in your pocket,
[1:32] that's great.
[1:33] But Terrence Tao day one at an
[1:35] accounting firm is probably not the best
[1:37] accountant there.
[1:39] But give him a few years or honestly
[1:40] maybe even like a few days,
[1:42] he'd probably be really good.
[1:44] And so we have this orthogonal axis of
[1:47] experience that is much more important
[1:49] than we think
[1:51] in conjunction with IQ. And that's what
[1:53] we're calling the experience gap and
[1:54] that is what we want to close as a
[1:56] company.
[1:57] Um
[1:58] And then but the question is like how do
[2:00] you how do you close that? Where does
[2:02] experience come from? Well, it's already
[2:04] out there right now. There's so many
[2:06] hundred million is a number, but so many
[2:09] tokens out there that are being
[2:10] generated by these agents. You view them
[2:13] or sometimes you don't even view them
[2:14] and they get thrown away. But this is
[2:16] all real work that they're doing
[2:18] and then people are acting upon them and
[2:20] then it's being thrown away. And so our
[2:22] take as a company as Gabe mentioned like
[2:24] our opinionated take is that uh this is
[2:27] a signal that we should be learning
[2:28] from.
[2:30] And this is also how humans get better.
[2:32] And in classic AI fashion like if the if
[2:34] humans do it probably a good way to
[2:36] mental model off of. Uh and so today's
[2:38] agents they're still slow, expensive,
[2:40] error prone over time. You implement
[2:42] them, they probably don't get better.
[2:44] We want to imagine what learning agents
[2:46] look like where as they are used by
[2:49] people, they get better and better over
[2:51] time.
[2:52] Uh and tangibly this has two good
[2:53] benefits. Right away it gets you much
[2:56] faster, better, cheaper models. Uh but
[2:58] more excitingly it gets you to this goal
[3:00] of systems that compound with use.
[3:03] And so I want to start off by talking
[3:05] about how we're approaching this problem
[3:08] uh and then
[3:10] uh some interesting stuff for you guys
[3:11] at the end.
[3:13] And so where it starts off and this kind
[3:15] of dovetails off of what Harrison was
[3:16] talking about before is it starts off
[3:18] with traceability. We need to first
[3:20] capture these interactions, capture this
[3:22] experience that's being thrown away.
[3:24] So that's step number one.
[3:26] Uh
[3:27] And then step number two and this is
[3:28] where where we start getting to our
[3:29] research. The way we view the company
[3:31] we're building is we're building a
[3:33] product to allow for continual learning,
[3:35] but we're doing cutting edge research
[3:36] under every single one of them
[3:38] to make this possible.
[3:40] And so
[3:41] you have all these interactions and the
[3:43] next thing we're building is this idea
[3:45] of a like a model spec. This idea that
[3:47] like you need to have a way to define
[3:50] what do I want my agent to do and have
[3:52] the agent learn against that. So we're
[3:54] doing really cool research here on how
[3:55] to extract user interactions, turn that
[3:58] into reward, extract traces, and turn
[4:00] that into exact specs of what you want
[4:03] your agent to do.
[4:04] And then okay, cool. You have what you
[4:06] want your agent to do. What do you do
[4:08] with that? Well, there's two surfaces.
[4:09] One is the models, right? You want your
[4:11] models to to learn from actual
[4:14] interactions here. And so we're doing
[4:16] really cool research on algorithms like
[4:18] SDPO,
[4:19] and and and and things along those lines
[4:21] where we're using RL to uh
[4:25] take these full long traces and improve
[4:28] models over time.
[4:29] But models are not the only thing. You
[4:30] have harnesses as well. And we're doing
[4:33] a lot of really cool research on
[4:35] when you have good feedback from people,
[4:38] does that go to a harness, or does that
[4:39] go to a model? An example here is
[4:42] if it's like a fact, like this person
[4:45] this like this company has been
[4:46] delisted, right? You probably don't want
[4:48] to train that knowledge into the model.
[4:49] It's probably context that should be
[4:50] available to the harness.
[4:52] And so that is how kind of how we're
[4:54] splitting things, and that is the
[4:55] product that we're building. Allowing
[4:57] you to go from real interactions all the
[4:59] way to specs of what you want your agent
[5:02] to get better at, to better models, and
[5:04] then better harnesses, and then being
[5:06] able to deploy those those models right
[5:08] away,
[5:09] and then start using our product.
[5:11] And so that's the world we want to get
[5:13] to.
[5:14] If you have built agents, which I'm sure
[5:17] most of you guys have,
[5:18] you probably know that there are so many
[5:20] things that go wrong with every single
[5:23] part of these, and then how every single
[5:24] one of these is an unsolved problem. And
[5:27] so the way I wanted to frame the rest of
[5:29] this is
[5:31] I'm going to imagine that I am like
[5:33] straight from Aladdin, and I have like
[5:35] four wishes.
[5:37] And what are those wishes that I would
[5:38] ask to like make the agent ecosystem
[5:41] better. And so like we have agents
[5:42] today,
[5:43] we have this like gap,
[5:45] and there's a level where agents get to
[5:48] and after that
[5:50] we can really see the exponential
[5:51] effects of continual learning. And what
[5:54] are those in
[5:56] I'll walk through them step by step with
[5:57] the same four categories I talked about.
[5:58] What we would like to see on the
[6:00] traceability side.
[6:02] What we would like to see on the eval
[6:04] side, what we'd like to see on the
[6:06] harness side, what we'd like to see on
[6:07] the model side. So let's start with wish
[6:08] number one.
[6:10] Uh and how can companies get there
[6:11] faster? Uh traceability.
[6:14] So two two sub wishes here. Number one
[6:17] is around tracing the entire tree of
[6:20] what happens, uh including sub agents.
[6:23] Uh what a lot of companies do is they
[6:25] trace the main action that is happening,
[6:28] but they throw away tool calls or sub
[6:29] agents that are made. Um and that makes
[6:31] it very hard to learn from the whole
[6:33] thing that you've done. So that's wish
[6:34] number one. Uh sub wish number two uh is
[6:37] probably the most important in here and
[6:39] that
[6:40] you should build your product around how
[6:43] you can both capture this interaction
[6:46] data, but also elicit the right amount
[6:48] of feedback uh so that you can then
[6:50] capture it. Um and a really interesting
[6:53] thing here is I think the level one way
[6:55] of thinking about this is uh okay, let's
[6:57] have like a thumbs up, thumbs down and
[6:59] like let's capture that. And that sounds
[7:01] amazing in theory uh but it's incredibly
[7:03] noisy and if you've used any coding
[7:06] agent, you know you kind of just like
[7:07] accept everything that the agent does.
[7:09] And it's only like five commits later
[7:11] that you're like, oh crap, like
[7:13] this broke everything. Let me go and
[7:14] undo that. And so it's the corrective
[7:17] behavior, the like the edits, the undos
[7:19] and the retries that both need to be
[7:22] like elicited from the user, but also
[7:24] captured. So that's my wish on
[7:27] traceability.
[7:29] The second wish is around evals. And the
[7:32] mental model to use here is
[7:35] your the product that your user uses
[7:39] should be as similar as
[7:41] as close to
[7:43] what the eval is done in in for wise
[7:45] should be as close to where the training
[7:47] is done in.
[7:49] In an ideal world, these are all the
[7:50] same. There's no difference between
[7:52] these. And so this means that evals are,
[7:54] you know, drawn from traffic, how people
[7:56] are actually using your product, both
[7:58] how they're using it now and the things
[8:00] that they're requesting on the frontier
[8:01] that might not be possible, all super
[8:03] helpful.
[8:05] Second is making every task roll
[8:07] outable. This is a pretty big infra
[8:10] challenge, uh but it's this idea that
[8:12] hey, if a user has done one thing, can I
[8:15] somehow replay what they what the user
[8:17] has done? And that is an incredibly
[8:20] helpful boon to to moving forward in
[8:22] this agentic era. And then lastly, this
[8:24] goes with number one, grading through
[8:25] like the real harness, uh not making a
[8:27] variation of the harness, but like
[8:28] grading the real harnesses that people
[8:30] use in production.
[8:32] So that is wish number two.
[8:35] Uh wish number three, getting into the
[8:36] harness,
[8:37] uh
[8:38] pretty important. Uh number one is and
[8:41] and I think the mental model to use here
[8:43] is I think a lot of products
[8:46] have built their harnesses around models
[8:49] that existed a year a year and a half
[8:51] ago. Where the primary function of the
[8:54] harness was to
[8:56] prevent the agent from doing bad things.
[8:59] Which was really good when agents would
[9:01] randomly break or have misformatted
[9:03] outputs, but now we're very much in a
[9:05] let the agents cook world.
[9:07] Uh and so
[9:09] I think I would view building the
[9:10] harness as not enforcing specific flows
[9:13] that need to be done, but more what are
[9:15] the primitives that your product has,
[9:18] whether that's search tools or private
[9:20] information, and then viewing the agent
[9:22] as orchestrating those primitives and
[9:24] then letting it do that.
[9:26] So that's sub wish one. Uh sub wish two,
[9:28] and this is how we're building our
[9:28] product as well, is making the agent
[9:31] interface as close to the user interface
[9:32] as possible.
[9:34] Uh in an ideal world, every single thing
[9:37] that I can do on your UI, your agent can
[9:39] do via tool call as well.
[9:41] Uh I think that is a world that makes
[9:43] training and continual learning so so
[9:45] much easier.
[9:46] Uh and then lastly, this is a small one,
[9:48] uh making tool responses informative. I
[9:50] think it's easy to be like, "Okay, I
[9:52] just want to know the state." Like let's
[9:54] say I'm like calling a search tool. I
[9:55] want to know the state. I want to see if
[9:56] it worked. Uh and if it's writing to a a
[9:59] DB or something, it just writes to it.
[10:01] And what we see often is like the
[10:03] response from that tool call will be uh
[10:05] done. Finished.
[10:08] That sounds like good in theory, but
[10:09] from an agent's perspective it's like
[10:11] incredibly confusing. And if you're
[10:13] trying to train or learn off of that,
[10:15] there's like no signal to learn off of.
[10:16] Right? You have no idea what actually
[10:17] was written. You have no idea what was
[10:19] actually was read. And so, that's the
[10:21] last sub wish under the harness is to
[10:22] make your tool responses really
[10:24] informative.
[10:25] So, that's wish number three. I think
[10:27] like canonically I only get three
[10:28] wishes, but let's imagine I have four.
[10:30] Uh
[10:31] and that's around the models.
[10:34] Uh and we've talked about that a lot
[10:35] today. Uh and that is
[10:38] uh
[10:39] I wish it was as easy as like just
[10:41] switching to an open weight model, but
[10:42] if you've tried that, you've probably
[10:44] seen there's 50 other considerations
[10:46] from security to safety to
[10:50] uh you know, different access
[10:51] provisioning stuff. So, start getting
[10:53] comfortable running on open weights cuz
[10:56] that is what unlocks the door to owning
[10:59] owning your weights and then continually
[11:00] improving on top of them.
[11:02] Um and then Gabe also talked about this
[11:04] this idea that like model routers are
[11:07] uh going to probably play a really large
[11:10] role in routing intelligence to the
[11:14] exact capability of the task they're at.
[11:15] And so, experimenting with with routers
[11:17] is another wish I would wish cast into
[11:19] the world.
[11:20] And so,
[11:22] that is the high level here. And so, I
[11:24] think like
[11:25] when we work with companies, the first
[11:27] thing we often do is do an audit of of
[11:29] these and like where things are. And
[11:32] for the most part there's a lot of work
[11:34] to be done to get here and so we work
[11:35] with them to build it out and it would
[11:37] be my dream if we go to a company and
[11:41] they have a lot of this built out.
[11:42] Granted a lot of the work we're doing is
[11:44] also knowing that a lot of this we can't
[11:45] expect and so we're doing a lot of cool
[11:47] research on, you know, assuming that
[11:49] nobody has Evals, somebody doesn't have
[11:50] Evals, how can we overcome that? Or
[11:53] assuming that the traceability is off,
[11:56] like how can we learn from the signals
[11:58] that are there? And so that is
[12:02] that that is my my goals for the for the
[12:03] universe here.
[12:05] Uh just want to quickly go over
[12:07] uh I think this is like a very very core
[12:09] research and product problem and so
[12:12] we're really excited with the team we've
[12:13] put together but I think more
[12:15] importantly and then two of the folks
[12:16] who are here today
[12:18] uh we're working with extremely frontier
[12:22] customers. The folks who are really
[12:23] really pushing the boundaries of what
[12:26] agents can do in production
[12:29] both today and tomorrow.
[12:31] Uh and so really excited to be working
[12:32] with them and another thing I want to
[12:35] show is
[12:36] we have
[12:38] Oh, that's my email.
[12:39] Uh
[12:40] we have a beta and so
[12:43] a really really core belief we have is
[12:45] that
[12:46] this capability, this ability to own
[12:48] your own intelligence, should not be
[12:51] something that you need to consult away
[12:53] a lot of the times. It should be
[12:54] expertise you build on your own because
[12:56] of how important it is for your product.
[12:59] Um and what that means for us is we want
[13:01] to build a product that empowers any
[13:03] company to
[13:05] own their own models and mainly get to
[13:07] continual learning from real
[13:08] interactions and so here's some some
[13:11] cool screenshots from our product. I'm
[13:13] I don't know if Nico is here but I'm
[13:14] supposed to show this Nico later today
[13:15] so this is like a sneak peek. Uh
[13:18] but here's Harvey. Here's the lab
[13:19] benchmark that that Gabe was talking
[13:20] about. Really really easy to import. Um
[13:23] training a model is incredibly easy.
[13:25] We're extremely proud of the interface
[13:27] we've put together here cuz if you've
[13:28] post trained, you know, there's like 50
[13:30] million things that go wrong, 50 million
[13:32] knobs to turn, and it's all researcher
[13:34] intuition, trademark asterisk, whatever
[13:37] that means. And what we've tried to do
[13:40] is
[13:41] take all of how our researchers post
[13:43] train their models and
[13:45] use an agent behind the scenes to take
[13:48] care of most of those knobs and just
[13:49] only expose the ones you need to know to
[13:51] make post training as easy as possible.
[13:54] So, really easy to train a model, see
[13:55] how the model's doing, evaluate,
[13:58] compare it,
[13:59] uh see if it's better than the model you
[14:01] were using before, and then deploy it.
[14:03] And so, in terms of actual work you put
[14:05] in, and that was not waiting for the
[14:06] model to train,
[14:07] probably like 15 minutes. And so, that
[14:10] is the world we're we're trying to get
[14:11] to to empower all these companies and
[14:13] hopefully more folks in this room.
[14:15] Uh
[14:16] So, yeah, that's our goal. We want to
[14:18] every company to own its own experience
[14:19] layer, and we're excited to build that
[14:21] alongside of some of y'all here,
[14:22] hopefully.
[14:27] >> [applause]
[14:28] >> Thank you. It's a great talk. You know,
[14:30] I wonder like, you know, uh when you
[14:32] talk about continual learning, like uh
[14:34] what do you think about their trainable
[14:36] object
[14:38] um between model weights, harness,
[14:41] tools, application layers?
[14:43] >> Yeah.
[14:43] >> Uh how how do you think of them? How do
[14:45] how do you prioritize?
[14:46] >> Yeah, I think I like a fun fun phrase is
[14:49] that if you ask like six researchers
[14:50] what continual learning is, you're going
[14:52] to get like
[14:53] seven answers, probably. Uh
[14:56] you can be very pure about this and be
[14:58] like, "Oh, it needs to be like a human,
[15:00] and it is just the weights that need to
[15:02] be adopting in real time, one shot."
[15:04] But, the way we view it is that
[15:08] the intelligence that your product is
[15:09] run off of is a system.
[15:11] It's a system that has many components,
[15:13] and true continual learning
[15:15] is something that optimizes across that
[15:17] system
[15:18] and
[15:20] optimizes based on what parts of the
[15:22] system needs to be updated uh for the
[15:24] information that you're learning. Like a
[15:25] mental analogy that I have is like when
[15:28] you are you know, saving things, right?
[15:31] We no longer think of like where in your
[15:33] RAM or where in your hard disk to save.
[15:35] That's the level that's abstracted based
[15:36] on what makes the most sense. We think
[15:38] about models versus harnesses versus
[15:40] context in the same way. It feels wrong
[15:44] that we're having to make the decision
[15:45] off of very little priors
[15:47] what to update based on what.
[15:50] This is a scientific problem that can be
[15:52] solved. Let's do that and then let's
[15:54] abstract that away.
[16:03] Cool.
[16:06] Oh, yes.
[16:07] Yes.
[16:07] >> Um, some of the speakers today talked
[16:09] about, you know, the importance of not
[16:10] training on your customer data.
[16:12] >> Yeah.
[16:12] >> And I imagine like a big part of
[16:13] continual learning is you are learning
[16:15] from all these interactions. Um, how are
[16:17] you thinking about things like
[16:18] differential privacy? Like how do you
[16:19] actually make your system better with I
[16:22] imagine most of these application
[16:23] companies have customer specific data
[16:25] arrangements that make that very hard.
[16:27] >> 100%. I think that's an incredibly
[16:29] important problem. Uh,
[16:31] actually before this I was at Apple and
[16:32] this is a problem we worked on quite a
[16:34] bit as well.
[16:35] Um, and there's a lot of clever things
[16:37] you can do where you're not actually
[16:40] training on customer data, you're
[16:42] instead sampling distributions from your
[16:44] customer data and then synthetically
[16:46] generating your own and doing kind of
[16:48] like a
[16:49] mental models maybe like a cryptographic
[16:51] thing where you're like comparing those
[16:53] distributions to see is my data actually
[16:55] on distribution, but you're not training
[16:57] directly off of the customer data. Um,
[17:00] and so that that's totally right.
[17:01] There's a lot of interesting work there
[17:03] and it's like very central and already
[17:06] with our customers we're doing some
[17:07] interesting and and fun things in order
[17:08] to
[17:09] uh, to get over that.
[17:12] Yes.
[17:13] >> Hey, I'm Sid. I'm from Finch. Um,
[17:15] thank you.
[17:16] Um,
[17:17] I think episodic memory plays uh, a role
[17:20] in continual learning to some extent.
[17:22] For example, like if a user does
[17:23] something on our platform that corrects
[17:25] what an agent did before, we might want
[17:27] to update an agent's behavior. Does
[17:29] Trajectory have like an opinionated take
[17:31] about that in the platform?
[17:33] >> Yeah, I think
[17:35] Okay, on episodic memory and I'm just
[17:38] going to repeat here.
[17:39] On episodic memory and like what if I'm
[17:41] thinking about this correctly, how
[17:43] different types of feedback impact what
[17:46] is learned?
[17:47] >> Yes.
[17:47] >> Yes, okay. So many thoughts.
[17:51] One way to look at this is there are
[17:55] two different types of signals. There
[17:57] are signals that are just
[17:59] something went wrong. Like for example,
[18:01] if somebody like flames the agent says
[18:03] like, "You're really bad." But he
[18:05] doesn't follow anything up with that or
[18:07] just thumbs down or like drops off the
[18:08] session. Those are cases where you know
[18:10] something went wrong, but not what right
[18:13] looks like. Then you have things like
[18:15] the agent retried and then it got to the
[18:17] correct solution or you corrected it by
[18:19] saying this is a difference. And so that
[18:21] is like a
[18:22] difference we make. In the latter case,
[18:23] we're very, very confident about the
[18:25] reward associated with the with the
[18:27] output and and what we're assigning.
[18:29] With the former, we know to penalize
[18:31] that behavior, but we don't necessarily
[18:33] say like there's like a correct right
[18:34] answer. That's one way of looking at it.
[18:37] Another way of looking at it is there
[18:40] are different
[18:42] like there's like a hierarchy of like
[18:44] how pertinent the information is
[18:46] people-wise. There's some information
[18:48] that's probably globally accurate,
[18:50] globally true.
[18:51] Things like a tool call repeatedly
[18:53] failing when trying to call a certain
[18:55] tool.
[18:56] That's probably relevant to everybody.
[18:58] And so this should be trained into the
[19:00] model and the model should get better at
[19:01] learning this tool.
[19:02] A certain user is like, "I never want to
[19:06] use the sub agent. Please, please,
[19:07] please don't do it."
[19:08] That's probably not something you should
[19:10] train into the model and leave to the
[19:12] context, and
[19:14] what we were really excited about is
[19:16] this is the stuff Harvey was talking
[19:17] about where this is actually something
[19:18] that will probably happen on a per org
[19:20] basis, or per customer even further, a
[19:23] per customer basis. And so, that's
[19:25] another way to think about it as well.
[19:26] So, the hierarchy of like what the
[19:28] feedback is pertinent to.
[19:30] >> Got it. Thank you.
[19:31] >> Yeah.
[19:35] Yes.
[19:36] >> Thank you.
[19:37] I think one of the themes of today has
[19:39] kind of been this idea that there are
[19:41] some, you know, tasks or part of your
[19:43] product where you kind of want to maybe
[19:45] like experiment more, go cheaper, add in
[19:47] more open source stuff, right? And then
[19:49] other areas where kind of being at the
[19:51] frontier and using a closed model or a
[19:52] closed framework is more useful. I guess
[19:54] like extending that analogy to continual
[19:57] learning, are there tasks or workflows,
[20:00] or like what is the shape of problem
[20:02] where something like this you've kind of
[20:03] seen really matters a lot, right? Versus
[20:06] where like just using, you know,
[20:09] statically trained frontier model or
[20:11] even a statically trained open source
[20:12] model, and then like you know, using the
[20:14] harness to inject relevant information
[20:16] into the context is sufficient to kind
[20:18] of achieve what the user usually wants
[20:19] to achieve.
[20:20] >> Yeah.
[20:21] This is a great question. I think the
[20:24] level one answer is I think for the most
[20:25] part most tasks work for continual like,
[20:27] but the ones I'm most excited about are
[20:30] tasks
[20:32] that are on the frontier. The mental
[20:35] model I have that that we have for
[20:39] AI progress in in in a way is
[20:42] people will ask models, people will ask
[20:44] products
[20:45] with the expectation of what they think
[20:47] the product can do.
[20:49] Uh and maybe they'll ask at the edge of
[20:51] what the product can't do, and then
[20:54] they'll see it fail, or they'll see it
[20:55] do something wrong, and they'll retreat
[20:57] back and be like, oh, it's it wasn't
[20:58] good enough. I can't use it for this.
[21:01] I think like a great example is like,
[21:02] would I even dream of typing in some of
[21:05] the like the whack query that give the
[21:06] cursor two years ago, like definitely
[21:09] not. I was like way lower than this, but
[21:11] then over time I started querying it
[21:13] where the models were getting better and
[21:14] I was like, "Okay, maybe we can do
[21:15] bigger and bigger things."
[21:17] What we're most excited about is
[21:19] the way that has happened is like models
[21:20] have generally gotten better and we've
[21:22] been targeted pushing in certain
[21:24] directions. Uh but what we're seeing
[21:26] with some of our customers are cases
[21:27] where
[21:28] users ask for things, the model can
[21:30] barely do it, but then during training
[21:33] it learns how to do it and then the user
[21:35] can now do this thing they couldn't do
[21:36] before. That chain
[21:39] is what's really exciting about
[21:40] continual learning of like really
[21:41] pushing that frontier
[21:43] of what's possible based on what the
[21:44] user tries and cannot do.
[21:47] >> Awesome.
[21:48] Thank you, Arjun. I think we're out of
[21:49] time. Uh really appreciate you doing
[21:51] this. It's awesome. Thank you.
[21:52] >> [applause]
