The Video Signal technical video digests

Why Off-the-Shelf AI Doesn't Understand Money — Udi Menkes, Intuit thumbnail

· 19:50

Why Off-the-Shelf AI Doesn't Understand Money — Udi Menkes, Intuit

Off-the-shelf Large Language Models (LLMs) often provide fluent but inaccurate financial advice—a phenomenon termed the 'fluent bluff'—because they lack real-world experience. The core argument is that mere context is not sufficient; true intelligence requires grounding in verifiable business outcomes. To solve this, Intuit builds systems that transform raw business data (e.g., General Ledger, P&L) into millions of State-Action-Outcome records. These structured datasets are used to train models that predict the actual impact of actions, leading to 'outcome-driven finance' and outperforming frontier LLMs in real-world decision-making.

Key takeaways

  1. The Fluent Bluff: Why Off-the-Shelf Models Fail at Money 4:08

    LLMs trained on general internet data (blogs, books) can give confident advice that is fundamentally wrong for specific business constraints. Examples include recommending a negative cash flow business acquire another property or raising prices when it risks losing all revenue.

  2. The Solution: Grounding in State-Action-Outcome Data

    Instead of relying on general knowledge, the system must be grounded by creating structured records detailing what a company *did* (Action) given its current financial status (State), and what the verifiable result was (Outcome). This moves advice from theoretical possibility to proven reality.

  3. Measuring Impact: Beyond Simple Difference 15:45

    Determining the true impact of an action requires advanced statistical methods like Conditional Average Treatment Error (CATE) to account for confounding variables, such as a company's natural propensity for success. Failing to do this leads to inaccurate conclusions about causality.

Watch on YouTube Full article

SimulationMaxxing: How Nubank ships agents 20× faster with simulations — Shreya Rajpal, Snowglobe thumbnail

· 16:29

SimulationMaxxing: How Nubank ships agents 20× faster with simulations — Shreya Rajpal, Snowglobe

Nubank achieved a massive acceleration in deploying AI agents—reporting up to 20x faster shipping—by shifting agent evaluation from relying solely on slow, expensive production data or manual curation to using grounded simulations. The core methodology involves running synthetic, multi-turn conversations against the agent within a specialized framework (Snowglobe), allowing teams to rapidly test models and variants in a continuous 'ship, observe, simulate, repeat' loop.

Key takeaways

  1. Simulations Shortcircuit the Eval Bottleneck 10:44

    Traditional agent evaluation data is complex (multi-turn, stateful trajectories) and time-consuming to gather via manual authoring or limited production traces. Simulations allow teams to generate thousands of multi-turn conversations quickly, reducing release cycles from weeks to hours.

  2. The Simulation Loop: Ship, Observe, Simulate

    A robust agent development cycle involves shipping the agent, observing real data, creating strong evaluations (using techniques like automated prompt optimization), and then using simulations to generate synthetic data. This simulated data is piped into the evaluation pipeline for continuous improvement.

  3. Closing the Sim-to-Real Gap

    To trust simulation results, it is crucial to establish metrics and processes that compare simulated performance against real production data (offline/online human review). The correlation between sim quality via evals and real data was found to be high.

Watch on YouTube Full article

Hugging Face Journal Club: Kimi K3 thumbnail

· 41:28

Hugging Face Journal Club: Kimi K3

The discussion summarizes the Kimi K3 tech report, detailing a highly complex and scaled training pipeline for large language models. Key innovations include specialized agentic structures (general, deep research, coding), multi-tier on-policy distillation across nine domain experts, and advanced infrastructure techniques like partial rollout schemes and dynamic resource scheduling. The talk emphasizes that the model's performance is achieved through sophisticated engineering efforts rather than a single breakthrough concept.

Key takeaways

  1. Multi-Tier Expert Specialization 2:00

    The training pipeline involves generating nine specialized domain experts (3 reasoning levels: low, high, max) for three general domains (general tasks, deep research, coding). These are combined using multi-tier on-policy distillation into a single student model.

  2. Partial Rollout Scheme 4:08

    A novel RL technique where the system samples $k$ rollouts from $n$ prompts. It uses an additional parameter $\lambda$ to measure completed rollouts within a budget, updating weights on that subset and pushing incomplete rollouts into subsequent iterations.

  3. Extensible Chat Template 6:42

    The Kimi K3 model utilizes an 'extensible token markup language' for its chat template. This design aims to be easy to learn during SFT while remaining flexible enough to accommodate future modalities without re-engineering the core template.

  4. Advanced Infrastructure Scaling 30:35

    The system employs sophisticated resource management, including a dynamic rollout auto throttling scheduler based on KV cache pressure and a method for collocating RL training and inference by automatically balancing GPU resources between the two tasks.

Watch on YouTube Full article

We Scored Oracle's Database Skill Live: 95% Isn't Enough thumbnail

· 14:35

We Scored Oracle's Database Skill Live: 95% Isn't Enough

The video demonstrates how Oracle's database team utilized AI 'skills'—encapsulated in a repository like `oracle/skills`—to guide AI agents in writing secure and best-practice compliant SQL. The process involved running an automated review (using Tessl) on a skill designed to improve database code generation, which initially scored 95%. Through iterative refinement and applying changes via a 'run, review, fix' cycle, the skill was successfully upgraded to a 100% success rate, showcasing a robust mechanism for encoding complex domain knowledge into AI workflows.

Key takeaways

  1. Purpose of Database Skills 5:51

    The primary function of the skill is to help agents write better SQL and database code by making them knowledgeable about the database's capabilities (e.g., property graphs, vector data). It helps discover what the database can do, rather than relying solely on general agent knowledge.

  2. Skill Review Process 13:44

    The skill was subjected to an automated review comparing it against best practices. The process involves running a 'run, review, fix' cycle, which applies changes and re-runs the validation in an agile style approach.

  3. Achieving 100% Compliance 14:35

    After making specific developer-suggested changes (e.g., adding a recommended sequence task), the skill's review score reached 100%, demonstrating continuous improvement and validation of domain knowledge.

Watch on YouTube Full article

Morgan Stanley's ALPHALAB: Multi-Agent Research Across Optimization Domains — Brendan Rappazzo thumbnail

· 20:07

Morgan Stanley's ALPHALAB: Multi-Agent Research Across Optimization Domains — Brendan Rappazzo

Morgan Stanley's AlphaLab is a multi-agent research system designed to automate quantitative finance research by managing the entire experimental lifecycle. Unlike simple code generation, AlphaLab accepts a problem in plain language and autonomously handles hypothesis formation, backtesting setup, cluster job submission (using tools like Slurm), statistical testing, and iterative refinement. The core innovation lies in its focus on building proprietary, verifiable evaluation environments—treating them as critical data inputs—allowing the system to self-improve and encode deep enterprise knowledge.

Key takeaways

  1. Full Research Automation Cycle

    AlphaLab operates in three phases: 1) Research (building context/hypotheses), 2) Evaluation Building (creating robust backtests, involving multiple critic agents to prevent forward leakage), and 3) Mass Experimentation. This allows the system to move from a natural language goal to a suite of trained models.

  2. Architecture: Strategist and Workers 15:36

    The process is managed via a Kanban/Jira-like board. A 'Strategist' agent proposes experiments, which are then assigned to 'Worker' agents responsible for writing code, configuring Slurm jobs (e.g., requiring 4 H100s), submitting the job, and performing postmortem analysis.

  3. The Value of Verifiable Environments

    The system's robustness hinges on building custom evaluation environments (evals) that mimic a private Kaggle competition. This strict format, which includes held-out validation sets, is crucial for measuring performance and encoding proprietary enterprise knowledge.

  4. Self-Improving Meta-Harness

    The ultimate goal (AlphaLab 2.0) is a self-improving system where the LLM performs meta-optimization, analyzing results and improving the harness itself, rather than just executing tasks within it.

Watch on YouTube Full article

Your Agent Didn't Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI thumbnail

· 18:26

Your Agent Didn't Fail. Your Harness Did. — Vinoth Govindarajan, OpenAI

The talk argues that most production failures in AI agents are not due to model hallucination or poor reasoning, but rather 'harness failures'—flaws in the underlying system architecture. The core principle is establishing a clear boundary: while a model can only propose an action, the surrounding harness must own the state transition, enforce ordered commits, and provide verifiable proof (the receipt) that the action was successfully executed and observed by the user.

Key takeaways

  1. Model Proposes, Harness Commits, Receipt Proves 4:06

    The model generates capability; the harness provides control. The system must own state transitions, enforce ordered mutations, and use a receipt to prove that an action was executed and visible to the user.

  2. Own the State, Order the Mutation, Prove the Action 5:20

    These three principles are critical for reliable agent systems. A fact must have a single owner (system of record) and a clear replay path; mutable state requires one ordered commit path.

  3. The Run Receipt Audit

    To audit an agent system, ask five questions: What woke it up (trigger)? What state did it inherit? Which authority did it use? What executed? And what evidence survived?

Watch on YouTube Full article

Paste This Into Claude, Never Hit a Token Limit Again thumbnail

· 20:17

Paste This Into Claude, Never Hit a Token Limit Again

This guide details advanced strategies for minimizing token consumption when interacting with Large Language Models (LLMs) like Claude and Codex. The core problem is 'reused input,' where every subsequent message resends the entire conversation history, leading to massive waste (up to 96% of tokens). Solutions are tiered: Level 1 involves user habits (e.g., editing mistakes instead of re-asking); Level 2 introduces automated tools like the 'Token Saver skill'; and Level 3 utilizes advanced frameworks such as Ringer for local, pre-model request constraint.

Key takeaways

  1. Edit Mistakes Instead of Re-Asking 4:40

    When correcting an AI error or typo, use the edit function rather than starting a new chat thread and stating 'that was wrong.' This prevents unnecessary token accumulation. (04:40)

  2. Start Clean Tasks for Job Changes 15:35

    When switching to a new, specific task, start a fresh chat thread. Continuing long conversations is good for focus but highly token-intensive and increases the volume of 'reused input.' (15:35)

  3. Carry Forward Artifacts, Not Arguments 15:35

    In multi-step processes (e.g., research followed by writing), only pass the final artifact or result from Stage A to Stage B. Do not include all previous drafts, criticisms, or rejected sources. (15:35)

  4. Use Local Retrieval and Caching

    Whenever possible, perform searches locally rather than relying on the model to search files, as this is a massive token burner. Also, use external databases (like OpenBrain) for frequently needed data points to avoid recalculation. (18:51)

  5. Enforce Hard Token Limits

    For critical workflows, use an intermediary tool like Ringer to enforce hard limits on the input/output packet size, ensuring predictable resource usage. (18:51)

Watch on YouTube Full article

Fine-Grained Authorization: The Missing Piece in Agentic AI Security - Shivay Lamba - NDC Sydney thumbnail

· 56:53

Fine-Grained Authorization: The Missing Piece in Agentic AI Security - Shivay Lamba - NDC Sydney

As Generative AI and agentic systems become more integrated into enterprise workflows, securing data access is paramount due to increased attack vectors. This talk emphasizes that traditional Role-Based Access Control (RBAC) is insufficient for modern AI applications. The solution proposed is Fine-Grained Authorization (FGA), specifically utilizing Relationship-Based Access Control (ReBAC). OpenFGA is presented as a robust, scalable tool that allows developers to enforce document-level permissions at runtime, ensuring that LLMs and agents can only access data explicitly authorized by the user's role and context. This approach is critical for securing Retrieval-Augmented Generation (RAG) pipelines against sensitive information disclosure.

Key takeaways

  1. AI Agents Require Guardrails 1:47

    Agentic systems, while powerful, must be constrained by proper security guardrails. Analogies like the Harbor Bridge and designated swimming areas illustrate that actions must be limited to authorized boundaries.

  2. FGA is Necessary for GenAI Security 20:40

    The most critical security risk in LLM applications, from an application developer's perspective, is Sensitive Information Disclosure. FGA ensures the AI respects user roles and permissions when accessing private data.

  3. ReBAC Scales Beyond RBAC 35:30

    Authorization evolved from Access Control Lists (ACL) to Role-Based Access Control (RBAC), which is coarse-grained. Relationship-Based Access Control (ReBAC) is the natural successor, allowing complex access decisions by defining relationships between subjects (users/groups) and objects (documents/folders).

  4. Pre-filtering Secures RAG Pipelines

    When implementing RAG, pre-filtering is the superior security approach. Instead of post-filtering results (where unauthorized documents might still be retrieved), a pre-filter check limits the vector search to only those documents viewable by the user's permissions.

Watch on YouTube Full article

The Cost of a Data Breach 2026, and what we can learn from the Hugging Face hack thumbnail

· 32:08

The Cost of a Data Breach 2026, and what we can learn from the Hugging Face hack

The discussion analyzes IBM's Cost of a Data Breach 2026 report, highlighting that the average breach cost is $4.99 million (a 12% increase). The central theme is the 'AI Tipping Point,' where attackers are weaponizing AI faster than defenses can deploy it. Key takeaways emphasize that basic security hygiene—such as proper access controls and encrypting PII at rest—remains critical, even in an advanced AI landscape. Furthermore, the analysis of the Hugging Face hack demonstrated how autonomous AI agents can chain zero-day vulnerabilities to breach systems, underscoring the need for open collaboration (e.g., Open Secure AI Alliance) and robust governance.

Key takeaways

  1. Data Breach Costs are Rising 5:05

    The average cost of a data breach is $4.99 million, representing a 12% increase from the previous year (Cost of a Data Breach report).

  2. Containment and Identification Remain Slow 6:52

    The mean time to identify and contain a breach remains high, averaging about two-thirds of a year.

  3. Basic Hygiene is Paramount in the AI Era 8:58

    A significant finding is that 92% of organizations experiencing an AI-related breach lacked proper AI access controls, reinforcing that foundational security practices are non-negotiable.

  4. The Need for Coalition Building 21:20

    The Hugging Face hack demonstrated the power of autonomous AI agents to chain vulnerabilities. The response requires collaborative efforts, such as the Open Secure AI Alliance, to share institutional knowledge.

Watch on YouTube Full article

Stephane Jourdan, Simon Rohrer & Pini Reznik - From Pipelines to Prompts: Surviving the Shift to AI thumbnail

· 33:28

Stephane Jourdan, Simon Rohrer & Pini Reznik - From Pipelines to Prompts: Surviving the Shift to AI

This panel discusses the seismic shift from traditional DevOps and Cloud-native practices to AI-native development. Speakers emphasize that while AI agents offer unprecedented speed in coding and diagnosing production issues (24/7), this acceleration introduces significant risks regarding code quality, system context loss, and maintainability. The consensus is that robust guardrails—such as advanced observability stacks, deterministic linting, and disciplined harness engineering—are more critical than ever to manage the complexity of AI-driven deployments.

Key takeaways

  1. AI Shift Magnitude 5:25

    The move to AI is described as potentially 10x or 100x more dramatic than the Cloud shift, impacting not just development teams but every department in an organization. The speed of change requires organizational-wide adoption of AI tools.

  2. Production Agents and Context 8:30

    AI agents are rapidly deploying fixes and features (sometimes 24 hours a day). This necessitates proactive context management, deep observability stacks (e.g., combining Elastic logs with Service Now incident reports), and knowledge of service relationships to manage the 'blast radius' of changes.

  3. Code Quality Guardrails 13:40

    The agents write code that is productive but often poor quality. Speakers strongly advise maintaining rigorous basics like linting and determinism, noting that relying solely on LLMs for perfect output is dangerous.

  4. Continuous Improvement Discipline 22:50

    The core principle of Continuous Integration/Delivery (CI/CD) must be maintained. Advanced teams are implementing self-reflecting agents that learn from both problems and solutions, treating failure feedback as a mechanism for continuous improvement.

Watch on YouTube Full article

How Forward Deployed Engineering is done at Factory — Eno Reyes thumbnail

· 21:21

How Forward Deployed Engineering is done at Factory — Eno Reyes

Forward Deployed Engineering (FDE) is evolving from traditional professional services consulting into a strategic function where engineers act as 'the tip of the spear' for product development. The core goal is to build an autonomous 'Software Factory' within a customer's environment. This factory automates the entire signal-to-deploy pipeline—from capturing external signals (e.g., bug reports, Slack conversations) through planning, coding, and rigorous validation (SAST, linters, type checkers)—with minimal human intervention. Success hinges on achieving 'agent readiness,' which measures the density of deterministic validation loops in a codebase, enabling massive migrations (e.g., 30-50 million lines of code) autonomously.

Key takeaways

  1. The Shift from Consulting to Product Strategy

    Factory argues that FDE should not be professional services work on behalf of a customer, but rather the stream of information gathered from critical customers. This data is fed back into the product to rapidly improve it, making the deployed engineer an integral part of the product's evolution.

  2. The Software Factory Pipeline 8:23

    This factory concept describes a continuous process where external signals flow in, are prioritized into plans, converted into code changes (the source of truth), pass through automated validation stages (linters, type checkers, SAST tools), and finally deploy. The goal is an uninterrupted signal-to-deploy flow without human intervention.

  3. Data Ownership and Autonomy 10:57

    To ensure scalability and security, the deployed engineer must utilize a model independent agent harness (like Droid) that guarantees the customer owns all traces and data. This allows for highly secure deployments, including air-gapping in sensitive environments like finance or healthcare.

  4. Agent Readiness as a Metric 20:05

    Autonomy is measured by 'agent readiness,' which quantifies the number of deterministic validation loops (e.g., passing linters, type checkers) present in a codebase. A high volume of these loops allows advanced agents to operate on complex tasks for extended periods without human intervention.

Watch on YouTube Full article

AI tools for Forward Deployed Engineering — Vasuman Moza, Varick Agents thumbnail

· 20:23

AI tools for Forward Deployed Engineering — Vasuman Moza, Varick Agents

The core bottleneck in enterprise AI adoption is not model intelligence or execution capability, but rather the ability to deeply understand and re-engineer complex, undocumented human business processes. Forward Deployed Engineers (FDEs) are critical for this process, mapping existing workflows—including edge cases and handoffs—and building autonomous agents on top of legacy systems (e.g., SAP, NetSuite). The technical solution involves using a Veric OS platform that builds agents on existing systems without requiring costly migrations, leveraging dependency graphs, and employing custom post-trained models to extract accurate context from messy enterprise data.

Key takeaways

  1. The AI Bottleneck is Context, Not Execution

    While modern LLMs can solve the execution of work (intelligence constraint), the primary bottleneck remains understanding the unique business processes within a specific company. Every department (e.g., healthcare sales vs. SaaS sales) operates differently, requiring deep context extraction.

  2. Forward Deployed Engineering (FDE) Role 7:24

    FDEs are responsible for mapping how humans currently perform work and then re-engineering the process around AI. This ensures that AI solutions are adoptable and deliver measurable, department-wide ROI rather than failing as isolated 'point solutions.'

  3. Non-Disruptive Deployment Strategy 17:02

    To overcome enterprise resistance to migration (e.g., spending $5 million over five years on NetSuite), agents must be built *on top* of existing systems of record (Salesforce, SAP, Dynamics) rather than requiring a full system overhaul.

  4. Agent Tooling for FDEs

    The Veric platform provides specialized tools: an Engagement Agent (assistant to synthesize notes/docs), and a Workflow Agent that ensures the constructed workflow correctly shadows real-world process edge cases. A future autonomous assistant will handle minor changes without human intervention.

Watch on YouTube Full article

How Forward Deployed Engineering is done at Cognition — Jia Wu thumbnail

· 17:38

How Forward Deployed Engineering is done at Cognition — Jia Wu

Forward Deployed Engineering (FDE) at Cognition focuses on maximizing the overlap between product capabilities and complex customer problem spaces, moving beyond simple code generation. The core value proposition is measured by tangible business outcomes—such as reducing delivery timelines or increasing PR acceptance rates—rather than merely token usage. FDE embeds within client ecosystems to identify high-leverage areas for AI agents like Devin, addressing the full software development lifecycle (SDLC) challenges including testing, review, and maintenance.

Key takeaways

  1. Shifting Focus from Tokens to Outcomes

    The industry trend is shifting away from optimizing for token usage toward measuring true business outcomes. Cognition measures value by demonstrating a real delta—for example, an 82% reduction in delivery timelines after agent activation.

  2. FDE's Role: Maximizing Problem-Product Overlap 8:36

    FDE aims to maximize the intersection between existing product domains and critical customer problems. This requires deep understanding of the client’s problem space, identifying the highest leverage points for automation.

  3. The Value is Non-Linear 3:25

    Adoption of AI agents follows a non-linear curve: initial use may be a step function, but enterprise-wide adoption and integration lead to parabolic growth as product capabilities align with the customer's full backlog.

  4. Core Mandates of FDE

    FDE operates under two mantras: relentlessly tying into the customer (who are the 'lifeblood') and prioritizing correctness and customer success at all costs. The goal is to make the customer successful, not just ship code.

Watch on YouTube Full article

How Forward Deployed Engineering is done at Ramp — Leo Mehr thumbnail

· 14:05

How Forward Deployed Engineering is done at Ramp — Leo Mehr

The talk outlines two core principles for Forward Deployed Engineering (FDE): always scoping and scaling with tokens. FDE teams must resist the urge to simply say 'yes' to every request; instead, they must rigorously scope requirements by asking context-gathering questions to ensure the right product is built. To scale this function, the entire FDE pipeline—from initial intake to spec writing—must be automated using AI agents (scaling with tokens). This requires building robust agent harnesses and implementing validation loops using evals, rubrics, and human feedback.

Key takeaways

  1. Always Scope First 5:16

    FDEs must pause before accepting urgent requests (e.g., SAP S/4HANA integrations) to gather context and determine what is truly necessary for the customer's success, rather than simply fulfilling the immediate ask.

  2. Scale with Tokens 8:24

    The future of FDE requires automating every stage of the request lifecycle—from gathering context to writing a spec—by replacing manual work with AI agents and model capabilities.

  3. Hybrid Approach is Key

    Effective modern FDE needs both human judgment (for taste and final validation) and agent volume/automation to handle the sheer scale of incoming requests.

Watch on YouTube Full article

The Dirty Secret of Forward Deployed Engineering — Natalie Meurer, Sierra thumbnail

· 16:49

The Dirty Secret of Forward Deployed Engineering — Natalie Meurer, Sierra

Forward Deployed Engineering (FDE) is not a single discipline but an outcome-focused role that has evolved significantly from initial platform stability work (DevOps) to complex data integration and customer enablement. The core thesis is that as coding becomes cheap due to AI agents, the value of engineering shifts entirely to understanding the customer's problem, integrating disparate data sources, and being accountable for measurable business outcomes.

Key takeaways

  1. FDE is an outcome-based role, not a code-writing one. 0:12

    The durable part of FDE involves integrating data, understanding the customer context, and maintaining accountability to a specific result, rather than merely writing software code.

  2. FDE's evolution tracks platform maturity. 0:06

    Early FDE focused heavily on DevOps and ensuring platform stability (e.g., deploying on an EC2 instance). This evolved into data integration using concepts like the Ontology, leading to modern platforms like Foundry that focus on 'data to decision-making.'

  3. Pricing models reflect accountability. 0:13

    The shift from seat-based pricing (assuming a tool) toward usage or outcome-based pricing confirms that the value lies in guaranteeing results, which is the hallmark of FDE.

  4. AI agents are simply FDE reborn. 0:15

    Agent engineering is viewed as a subset and manifestation of FDE principles, where engineers use LLMs to enable outcomes for customers. The role requires combining product knowledge with customer-facing solutioning.

Watch on YouTube Full article

How Forward Deployed Engineering is done at Decagon — Sunny Rekhi thumbnail

· 18:09

How Forward Deployed Engineering is done at Decagon — Sunny Rekhi

The talk details the function and evolution of Forward Deployed Engineering (FDE) at Decagon, a company specializing in AI customer service agents. FDE is described as being functionally identical to product engineering, requiring engineers to not only configure complex agent workflows for specific enterprises but also to proactively identify and build platform features that solve anticipated problems across multiple clients. The core philosophy emphasizes architectural restraint: ensuring all custom work is designed to be self-serve and compound into the overall platform, allowing the solution to scale from bespoke deployments to a generalized product.

Key takeaways

  1. FDE Blurs with Product Engineering

    The line between forward deployed service and internal product development is highly blurred. When an enterprise expresses a pain point, it should be treated as a potential product feature that needs prioritization for the entire platform (13:00).

  2. Focus on Architectural Restraint 13:40

    A critical skill in scaling FDE is exercising restraint—avoiding simple one-off patches and instead architecting solutions so they benefit future, unknown customers. This ensures the solution does not become a brittle 'black box' (8:20).

  3. Custom Work Must Compound

    The goal of every deployment is to ensure that custom integrations or workflows are systematically fed back into the platform, transforming bespoke solutions into self-service capabilities for all customers (14:18).

Watch on YouTube Full article

Training Agents 3: Reinforcement Learning thumbnail

· 1:17:20

Training Agents 3: Reinforcement Learning

This session introduces Group Relative Policy Optimization (GRPO), a reinforcement learning (RL) method that advances agent training beyond mere imitation (SFT/Distillation). GRPO trains models by sampling multiple completions per prompt and using the group's relative scores—calculated via a reward function—as the primary training signal. This approach is highly effective for complex tasks, allowing agents to learn from their own varied trajectories in an iterative loop.

Key takeaways

  1. GRPO Mechanics 20:30

    GRPO calculates advantages relative to the group average (Reward - Group Average / Group Standard Deviation). This method eliminates the need for a separate value model, reward model, or critic, simplifying the RL loop. The process involves generating multiple rollouts, scoring them with a verifiable Python function (the reward function), and updating the policy based on these relative advantages.

  2. Training Pipeline Progression 5:05

    The training pipeline typically progresses from Supervised Fine-Tuning (SFT) for dense, off-policy signals, to Distillation for richer online rollouts, and finally to RL/GRPO for sparse, on-policy learning. SFT is often used first to bootstrap the model's understanding of the task structure.

  3. Reward Function Design 26:40

    Defining a verifiable reward function is critical; it acts as a 'contract' defining success. Rewards can be composed of multiple components, such as a format check (e.g., ensuring JSON structure) and an accuracy check (e.g., passing unit tests). For agentic tasks, using test suites or compiling code provides robust signals.

  4. Interpreting Training Curves 35:00

    Monitoring training curves via tools like Track.io is essential for debugging. Key metrics include the reward (should rise), entropy (should remain stable/flat, not dive or spike), and completion length. Failure modes—such as 'reward hacking' (high reward but low test accuracy) or 'collapse' (low entropy)—require deep data inspection.

Watch on YouTube Full article

Build Smarter Voice Agents thumbnail

· 46:14

Build Smarter Voice Agents

This panel discussion provides deep insights into building production-grade voice AI agents. Key architectural recommendations favor the deconstructed cascading pipeline (ASR $\rightarrow$ LLM $\rightarrow$ TTS) due to its superior flexibility for optimization and model swapping. Engineers must prioritize managing latency within a 1–1.5 second budget, implementing robust fallback systems across all stack components (ASR, LLM, TTS), and utilizing advanced context management techniques like 'Scratchpads' to maintain conversational continuity over long interactions.

Key takeaways

  1. Architectural Choice: Cascading Pipeline 1:45

    The cascading architecture is preferred because it allows for individual optimization of the ASR, LLM, and TTS layers. This modularity provides greater flexibility than a full Speech-to-Speech (S2S) stack when integrating new models or optimizing specific components.

  2. Latency Management 4:23

    The 'golden metric' for voice agent response time is between 1 to 1.5 seconds. Exceeding this budget can be unnerving for users, making latency a primary design constraint over pure accuracy in many cases.

  3. Context and Memory Management 18:05

    To prevent negative user sentiment from repeating information, agents must implement context stores (e.g., 'Scratchpads') to track customer profiles, preferences, and key facts across multiple turns or sessions.

Watch on YouTube Full article

How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh thumbnail

· 22:20

How Forward Deployed Engineering is done at Kepler — Vinoo Ganesh

Forward Deployed Engineering (FDE) should be viewed not as a go-to-market function, but fundamentally as a product strategy. FDE engineers act as extensions of the core product team, solving concrete, small-scale customer problems in their live environment to identify generalized product opportunities. The process involves observing user workflows, defining the underlying domain language (ontology), and ensuring that temporary fixes are built with production readiness in mind.

Key takeaways

  1. FDE is a Product Strategy, Not a Role 3:35

    The core insight of FDE is that it must function as an extension of the product team to identify areas for generalization. The goal is to define and solve the underlying problem, not just implement the requested solution.

  2. Solve Small Problems First 8:11

    When a customer presents a massive requirement (e.g., a custom BI tool), focus on solving the most immediate, trivial problem first (like a Slack alert). This builds trust and allows the product team to gain ownership of the solution narrative.

  3. Observe User Pain Points 17:12

    The most valuable intelligence is found by observing user behavior (e.g., repetitive tasks, copying/pasting between tools, or using a phone during workflow). These actions indicate missing features or bugs that documentation will never reveal.

  4. Define the Ontology and Language 20:33

    FDE must define the domain's terminology (the ontology) to standardize ambiguous terms. By canonicalizing nouns (entities, e.g., 'clients') and verbs (operations), the engineer controls the language that the entire system is built upon.

Watch on YouTube Full article

Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE thumbnail

· 17:48

Forward Deployed Engineering 101 — Kevin Bai, Anthropic, ex Palantir & Rippling Founding FDE

Forward Deployed Engineering (FDE) is a go-to-market model where companies sell an 'outcome' rather than just a product or service. This involves loaning specialized engineers who build bespoke solutions on top of the company's core platform. FDE is necessary when selling highly technical platforms to non-technical, large enterprise buyers (e.g., Fortune 500 clients). To scale this model successfully, the underlying technology must be built upon a reusable platform with shared primitives, preventing the function from devolving into an unmaintainable 'dev shop.'

Key takeaways

  1. FDE Focuses on Outcomes, Not Products/Services 5:14

    The goal is to sell the final business outcome (e.g., higher throughput of sales) rather than selling a piece of software or the time of an engineer. This model allows companies to land large contracts that self-serve motions cannot reach.

  2. FDE is Required for Specific Situations 6:58

    An FDE function is only necessary when selling something very technical (like an app building platform) to a non-technical buyer. If the product is simple or the buyer is highly technical, other GTM strategies may suffice.

  3. Platform Reusability Prevents Failure 11:56

    To scale FDE successfully, engineers must build on a platform of shared primitives. If every engineer builds entirely from scratch for each customer, the function becomes an unmaintainable 'dev shop,' leading to massive maintenance costs.

  4. AI Accelerates FDE Adoption

    The current shift toward agentic and customizable platforms means that nearly all companies may face the situation of selling complex solutions to non-technical customers, making FDE a more common motion.

Watch on YouTube Full article