Channel

AI Engineer

Digests from AI Engineer

· 20:14

Agents at Scale: Inside MiniMax's Model and the Infrastructure Behind It — Olive Song

The discussion details the engineering stack and open-source philosophy behind MiniMax's model, M3. Olive Song emphasizes that the open weights approach allows the community to build upon and optimize the model, fostering widespread intelligence access. The technical focus covers advanced training techniques—including multimodality (text, image, video) and Reinforcement Learning (RL) for long-horizon tasks like replicating academic papers (12-hour runs)—and the complex infrastructure required for deployment. Key engineering challenges discussed include writing specialized GPU kernels, optimizing the inference stack from 'day zero,' managing KV cache growth in agentic workflows, and adapting to shifting workloads from chat-based to multi-turn, tool-calling agents.

Key takeaways

  1. Open Weights Philosophy 2:07

    MiniMax advocates for open source because it aligns with their mission of making intelligence widely accessible. By releasing weights, they enable developers (like Together AI) to optimize the model's inference speed and capabilities through community contributions.

  2. Multimodality Training 8:02

    MiniMax M3 is multimodal, understanding text, code, images, and videos. Crucially, it was trained multimodally from scratch to prevent 'training collapse,' ensuring that the modalities naturally interact (e.g., visual tokens attending to text tokens).

  3. Agentic Workloads and Inference Shifts 13:40

    The workload is shifting from simple chat turns to complex agentic workflows involving hundreds of multi-turn tool calls. This requires significant optimization in the inference stack, particularly concerning KV cache management and routing.

  4. Long-Horizon RL Tasks

    Training for complex tasks (e.g., replicating an ICLR paper over 12 hours) requires careful formulation of the problem, defining environments, and optimizing reward functions within the Reinforcement Learning framework.

Watch on YouTube Full article

· 21:32

fighting slop with slop — Vaibhav Gupta, Boundary

The talk outlines a strategy for combating 'slop'—sloppy code and processes—by building sophisticated tooling layers on top of stable foundations. Vaibhav Gupta argues that while AI agents accelerate development, the core weakness lies in foundational systems (like JavaScript/TypeScript) lacking sufficient rigidity. The solution involves enforcing strict invariants through advanced type systems (like BAML), automated execution tracing, and specialized tools for design documentation and dependency visualization, allowing complex codebases to ship without requiring manual reading of every line.

Key takeaways

  1. Fighting Slop with Invariants 0:27

    Instead of relying on traditional methods like mandatory code reviews (which are difficult to enforce), the focus must be on building architectural invariants. This includes using dedicated tools for design documentation and CLI scripts that guarantee certain structural rules cannot be broken, even when integrating AI agents.

  2. The Foundational Layer Bet

    To achieve stability at scale, the focus must shift to foundational programming layers. The speaker advocates for systems that use strong type inference and guarantee error handling (e.g., making division by zero impossible) from first principles, rather than patching existing languages.

  3. Agent-Driven Verification 8:28

    Advanced tooling allows agents to constantly run over codebases, not just detecting incorrect language usage, but also identifying inefficiencies (e.g., when three tool calls were needed instead of one) and classifying issues as hallucinations or real bugs.

Watch on YouTube Full article

· 20:24

First Steps Toward Automated AI Research — Richard Socher, CEO Recursive AI

Richard Socher proposes the concept of the 'Eureka machine,' a system designed to automate scientific discovery across all fields—from physics and biology to economics. Drawing parallels with evolution and Popper's philosophy of science, he argues that humanity is at an inflection point where Artificial Intelligence (AI) can achieve Recursive Self-Improvement (RSI). This process involves building systems that improve their own code and architecture over long time horizons, accelerating scientific progress far beyond current human capacity.

Key takeaways

  1. The Eureka Machine Goal 15:07

    The ultimate goal is to build a machine that automates the entire process of scientific discovery. This requires integrating knowledge (scientific data), simulation, physical experimentation, and an agent swarm to manage all inputs.

  2. Evolutionary Analogy for Progress

    Scientific progress is viewed as an open-ended evolutionary process. Just as biology evolved over billions of years, technology and AI are expected to undergo rapid, exponential shifts (S-curves) leading to massive human flourishing.

  3. The Necessity of RSI

    AI progress is accelerating because modern AI can code. The next major step involves building a system with Recursive Self-Improvement (RSI)—an AI that has self-awareness of its shortcomings and autonomously updates its entire architecture, moving beyond manual processes.

Watch on YouTube Full article

· 13:42

Your Finance Agent's Bottleneck Is You — Ramana Siddanth Emani, Auditoria AI

The primary bottleneck in developing production AI agents, especially for regulated fields like finance, is not model capability or hardware, but the developer's manual workflow. The talk outlines how advanced agent harnesses can automate and multiply human output by implementing primitives such as sub-agents, skills, goals, and loops. By orchestrating these agents across parallel worktrees (e.g., handling multiple Jira tickets simultaneously), developers can drastically reduce time spent on repetitive tasks like testing, building, and deployment, shifting the human role from executor to final verifier.

Key takeaways

  1. The Developer Loop is the Bottleneck

    Shipping production agents fails due to developer velocity limitations. The solution lies in automating the internal developer loop rather than waiting for model or hardware upgrades (0:00, 2:37).

  2. Parallel Task Execution via Sub-Agents 7:02

    Sub-agents allow for parallel processing using isolated 'worktrees'—virtual folders where agents write and execute code independently. This enables handling multiple tasks (e.g., QA bug tickets) simultaneously, far exceeding human capacity (4:22).

  3. Minimal UX for Orchestration 8:38

    Effective agent use requires minimal User Experience (UX), consolidating all project dashboards, logs, Jira tickets, and GitHub PRs into a single pane of glass widget to reduce context switching and manual orchestration effort (5:18).

  4. Achieving Autonomy with Goals and Dreaming

    Future agent development involves combining 'goals' (setting a desired outcome) with automated loops. Furthermore, allowing agents to 'dream' by collecting customer usage patterns can drive self-improvement and feature upgrades autonomously (11:35).

Watch on YouTube Full article

· 21:37

Let's integrate AI Agents in Event-Sourced Systems — Divakar Kumar, FlyersSoft

The presentation outlines an advanced architectural pattern for integrating AI agents into existing enterprise systems, specifically targeting real-time fraud detection. Instead of replacing established Rule-Based Engines or ML models, the approach layers agentic intelligence to resolve 'gray zone' transactions—cases where current deterministic systems lack sufficient context. The architecture leverages Event Sourcing and Domain-Driven Design (DDD) principles by building a centralized semantic layer that aggregates data from multiple bounded contexts (e.g., Transaction, Device, Account). Agents then consume this enriched context via an orchestration layer in a saga pattern to reach a final verdict.

Key takeaways

  1. AI Agents Augment, Not Replace, Existing Systems

    The primary value of AI agents is not replacing existing systems (like rule-based or ML engines) but rather adding an agentic layer to handle ambiguous cases—the 'gray zone' where current models lack necessary context. The goal is to enhance business workflows using the state and history already captured by event sourcing.

  2. Context Aggregation via Semantic Layer 17:37

    To provide sufficient context for agents, data from disparate bounded contexts (Transaction, Device, Account, Payment) must be aggregated into a semantic layer or materialized view. This is achieved by propagating domain events using Change Data Capture (CDC) mechanisms or message brokers.

  3. Saga Orchestration and Agentic Decision Making

    The system uses an orchestration layer to manage the process. This layer employs a fan-out pattern, sending events simultaneously to multiple specialized agents (e.g., Risk Analyzer Agent, Behavior Analyzer Agent). A final Verdict Agent then analyzes these responses to reach a consensus event.

Watch on YouTube Full article

· 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

· 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

· 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

· 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