The Video Signal technical video digests

· 19:09

Wearing the Agent: From Group Chats to Glasses — Sai Krishna Rallabandi

The talk addresses the architectural shift required for agentic systems moving from single-user deployments to complex group chats and wearable devices. The speaker argues that these multi-user environments fundamentally break single-user assumptions, necessitating a complete redesign of memory management and security layers. Key challenges include preventing information leaks when multiple skills collide (security) and efficiently curating evolving conversations over long periods without context bloat (memory).

Key takeaways

  1. Group Settings Break Single-User Assumptions

    Agents designed for one user fail in group settings because the complexity of tracking multiple participants, maintaining privacy, and managing shared information requires unique architectural solutions.

  2. Security Must Be Designed at the Action Surface 12:24

    Instead of trying to guard all input (which is impossible due to vast surface areas like web pages, emails, and GitHub issues), security must focus on designing a deterministic guard layer that monitors actions—specifically when the agent reads or exports variables (e.g., bash variables) before taking action.

  3. Memory Requires Atomic Information Extraction

    Traditional memory methods are insufficient for groups. The system must move beyond storing raw conversation logs and instead extract high-value, atomic facts from the discussion. This requires designing sophisticated auto-raters to determine relevance, hierarchy, and temporal importance.

Watch on YouTube Full article

· 16:24

We Vetted 2000 AI Skills Before They Reached Developers — Lucas Palma, Nubank

Lucas Palma details how Nubank addressed AI skills—which function like supply chain dependencies—being a significant security risk in a regulated financial environment. To mitigate this, they built 'Skill Vector,' a comprehensive security review system that sits between the skill and the internal marketplace. This system vets every skill using a hybrid approach: deterministic checks (e.g., regex for unsafe instructions) followed by LLM analysis to assess context and behavior before granting permissions or allowing deployment.

Key takeaways

  1. Treat AI Skills as Dependencies

    AI skills must be treated like any other software dependency, requiring rigorous vetting and security gates, rather than just configuration files.

  2. Hybrid Security Scanning is Essential 12:17

    The most effective approach combines deterministic checks (for easy risks) with LLM review (for contextual behavior analysis), ensuring comprehensive coverage.

  3. Security Gates Must Be Comprehensive

    Vetting must cover the entire workflow, including local developer testing, CI/CD steps, PR feedback, and integration into a formal vulnerability management program.

Watch on YouTube Full article

· 22:30

How Kepler Built Verifiable AI for Financial Services — Vinoo Ganesh

The talk details how Kepler built a verifiable AI system for financial services, addressing the core limitation that Large Language Models (LLMs) are inherently non-deterministic probability machines. To achieve reliable work product—such as DCF models or investment memos—the system must augment the LLM with a deterministic substrate. This architecture enforces three tenets: Atomic Provenance (tracking every number's source), Scope Determinism (separating reasoning from computation), and Reconciliation/Derivation Chains (ensuring numerical accuracy through verifiable steps). The goal is to shift AI's edge from content generation to verifiable, traceable output.

Key takeaways

  1. LLMs are Probability Machines, Not Deterministic Calculators 4:17

    AI models excel at next token prediction (writing) but fail when deterministic accuracy is required, such as arithmetic or pulling specific figures from filings. Using LLMs for verification alone is insufficient because they are non-deterministic.

  2. The Need for Verifiability in Finance 7:07

    In finance, information must be traceable to its source (provenance). The challenge is moving beyond simple citation (an after-the-fact audit) to true deterministic verification of a number's correctness.

  3. The Three Tenets of Verifiable AI 15:26

    Kepler’s platform ensures numerical accuracy through three mechanisms: Atomic Provenance (writing references instead of numbers), Scope Determinism (separating the model's reasoning from deterministic computation), and Reconciliation/Derivation Chains (tracking every step to produce a final number).

  4. AI Must Be Modeled Like a Portfolio Manager (PM) 20:01

    The system must not let the LLM perform computation. Instead, it uses deterministic tools to calculate figures and pull data from structured sources like XBRL or filings, ensuring the model only dictates *what* needs to be computed, not *how*. This is crucial for producing reliable work product.

Watch on YouTube Full article

· 21:09

Persona Engineering: A Field Guide to AI Synthetic Personas — Ishan Anand, InsightSciences.ai

Synthetic personas, powered by LLMs, offer a powerful method for simulating human behavior in market research. However, they are not ground truth and must be treated like weather forecasts—predictive models operating within defined regimes. The talk emphasizes that accuracy is often misleading; failure modes include the model inventing latent confounders (e.g., using price as a proxy for product quality) and extreme prompt sensitivity to variable ordering. Robust validation requires measuring the full distribution shape, not just average agreement.

Key takeaways

  1. Treat Synthetic Personas as Forecasts, Not Facts

    Synthetic personas are bounded systems; they predict potential outcomes but cannot guarantee absolute truth. Validation must involve comparing distributions against real-world data (the 'noise floor') rather than aiming for a perfect match.

  2. Beware of Latent Confounders 9:52

    LLMs can invent or infer confounders when context is missing. Poorly grounded prompts allow the model to 'play improv,' leading to skewed results (e.g., an inverted U-shaped purchase probability curve where price increases lead to increased purchase likelihood). Rich prompting must specify personality, context, and study construction.

  3. Focus on Distribution Shape, Not Just Average Accuracy 20:49

    When evaluating performance, focus on metrics that capture the entire shape similarity of the distribution (e.g., using correlation and specific shape metrics). LLMs often lose variation details when averaging results, which is a critical failure mode.

  4. Behavior vs. Stated Attitude 15:07

    LLMs are trained on what people *say* (text/surveys) and perform better predicting stated attitudes than actual behaviors or actions, which require more complex transcription into text.

Watch on YouTube Full article

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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

· 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