The Video Signal

Channel

AI Engineer

Digests from AI Engineer

AI-Native Organisations Run on Skills: How to Structure and Scale Them — Imad Touil, QuantumBlack thumbnail

· 20:31

AI-Native Organisations Run on Skills: How to Structure and Scale Them — Imad Touil, QuantumBlack

The talk argues that in AI-native organizations, organizational know-how resides primarily within 'skills.' While skills offer deterministic outcomes for complex workflows, ungoverned skills quickly accumulate as a form of technical debt due to duplication and quality decay. To scale effectively, organizations must adopt governance principles—borrowing from the microservices era—by implementing a centralized skills platform that provides metadata, search, versioning, access control, and clear ownership.

Key takeaways

  1. Skills are the core of organizational know-how 11:43

    The agentic software stack relies heavily on 'skills' (the deterministic component) within its outer workflow loop. If skills are unstructured, the resulting workflow is not truly deterministic.

  2. Governance prevents technical debt 20:30

    Without governance, teams repeatedly build similar skills (duplication), quality degrades because skills aren't retested against new models, and ownership is unclear. This creates a new class of technical debt.

  3. A centralized platform is mandatory for scale

    Scaling requires a central skills catalog with metadata, dependency mapping, versioning (to pull the current release), access control, and named human owners across architecture, infrastructure, and security.

Watch on YouTube Full article

Your Code Has Bugs. Lean4 Has Proofs: Formal Verification for Engineers — Varun Pant, AWS thumbnail

· 10:07

Your Code Has Bugs. Lean4 Has Proofs: Formal Verification for Engineers — Varun Pant, AWS

As AI coding agents generate massive amounts of code, traditional checks (probabilistic model grading, input-limited tests, human review) are insufficient to guarantee correctness for all inputs. Formal verification provides mathematical proof that code satisfies a precise specification. The methodology involves humans owning the specification and machines handling both the implementation and the formal proof. Tools like Lean allow the same language for defining code and proofs, enabling robust systems where production code (e.g., Rust) is reconciled against specifications written in Lean, often through differential random testing.

Key takeaways

  1. Limitations of Current Code Checks

    None of the usual checks—AI model grading (probabilistic), unit tests (limited inputs), or human review (non-scalable)—can guarantee that code is correct for every possible input. Formal verification provides mathematical proof of correctness for all inputs.

  2. The Specification Hierarchy 2:00

    In formal verification, humans own the specification (what 'correct' means). This specification must be validated first because it is the upstream artifact; everything else (code and proof) is downstream from it. The AI coding agent then implements code based on this spec.

  3. Lean as a Unified Language 4:00

    Lean functions as both a programming language and a proof assistant, eliminating translation layers. It allows the same language to define definitions (code) and proofs (theorems).

Watch on YouTube Full article

How do you diffuse AI into the real world? — Varun Shenoy, Long Lake thumbnail

· 17:46

How do you diffuse AI into the real world? — Varun Shenoy, Long Lake

The deployment of advanced AI agents into real-world service industries is not merely a technological challenge but an operational one. Drawing parallels to the adoption of electricity and Ford's assembly line, the speaker argues that technology diffusion takes generations. Long Lake addresses this by acquiring and operating services businesses (e.g., property management) rather than selling software. Their approach focuses on building AI agents that move beyond simple 'co-pilots' to become autonomous 'co-workers,' leveraging proprietary ground truth data collected from messy, real-world tasks—a process requiring deep, physical co-design with the industry.

Key takeaways

  1. AI Diffusion Takes Generations 1:30

    The adoption of general-purpose technologies (GPTs) is slow. Just as electricity took decades to fully integrate into industries like Ford's, AI requires massive operational shifts—ripping out old processes and retraining staff—to achieve full diffusion. [1:30]

  2. The Value of Owning the Outcome 2:36

    Long Lake does not sell AI software; they acquire and operate services businesses (e.g., HOA, architecture). By being the operator/owner, they bear the risk when the AI fails, ensuring deep integration and accountability that external vendors cannot match. [2:36]

  3. The Progression from Co-pilot to Co-worker 6:18

    AI agents must progress through stages of autonomy: Co-pilot (simple RAG chatbot) $ ightarrow$ Synchronous Agent (real-time, two-way interaction) $ ightarrow$ Asynchronous Agent (background work, external triggers) $ ightarrow$ Long-running Agent $ ightarrow$ AI Co-worker (proactive partner). Achieving the co-worker requires earning the right to do more through iterative field deployment. [6:02]

Watch on YouTube Full article

How to Get Your Org to Adopt Coding Agents (Without Shipping Garbage) — Eyal Blum, Figma thumbnail

· 17:43

How to Get Your Org to Adopt Coding Agents (Without Shipping Garbage) — Eyal Blum, Figma

The talk outlines Figma's strategy for safely adopting AI agents in a large-scale codebase. The core message is that successful adoption requires shifting focus from simply prompting agents to building robust verification mechanisms and structured planning processes. Key recommendations include making communication attention-aware (marking human vs. AI text) and structuring complex tasks using detailed plans, which are then broken down into small, independently verifiable components.

Key takeaways

  1. The Role of Skeptics in Adoption 5:25

    Best engineers, who hold institutional knowledge (the 'mental duct tape'), tend to be the slowest adopters because they are best positioned to spot failure modes and missing validation. Instead of forcing adoption, organizations should involve these skeptics by making them responsible for defining the roadmap to make AI safe.

  2. The Three Acts of AI Adoption 0:45

    AI adoption follows a three-act process: (1) Simple, successful use cases; (2) Applying practices to bigger problems where AI fails badly and trust breaks down; and (3) Building the real skill by implementing proper guardrails, context, and prompting for scale.

  3. Planning Over Prompting 10:30

    For complex features, spending significant time writing a detailed plan is more effective than simply prompting the agent. A good plan must start with a 'Why' (executive summary) and be broken down into small parts that can each be verified independently.

  4. Attention-Aware Communication

    Since human attention is scarce, it is crucial to build a culture of self-communication by explicitly marking what content was generated by AI versus what was written by a human (e.g., starting PR descriptions with a manual summary).

Watch on YouTube Full article

From AI-Assisted to AI-Native: Building a Frontier Development Team — Clare Liguori, AWS thumbnail

· 20:57

From AI-Assisted to AI-Native: Building a Frontier Development Team — Clare Liguori, AWS

Frontier development represents a step-function improvement in productivity using AI agents, moving beyond simple coding assistance. The core finding is that success is not dependent on the tools themselves, but rather on intentionally changing engineering workflows and building new habits. Key practices include investing heavily in agent context, slowing down to refactor codebases (e.g., migrating from untyped languages like Python/JavaScript to TypeScript or Rust), implementing parallel agent execution, making intent explicit via documentation, and shifting testing left using local deterministic mocks.

Key takeaways

  1. Frontier Development Definition

    Productivity gains are characterized by engineers writing only 1-2% of the code; agents running for hours without interruption; and multiple agents operating in parallel. This represents a median productivity improvement of 4.5x to over 10x compared to previous AI phases (0:00, 7:04).

  2. The Importance of Process Over Tools 11:44

    A pilot study involving 50 teams on existing codebases found that the difference between <3x and >4.5x productivity gains was determined by how the team worked, not the AI tools used (9:21).

  3. New Bottleneck Identification 18:58

    As coding speed increases dramatically, the bottleneck shifts from writing code to decision-making speed and organizational review processes. Fast decisions, especially reversible ones, are critical for scaling (11:38).

Watch on YouTube Full article

How to avoid disaster when vibe-coding a billing engine — Andrew Garvin, Stripe thumbnail

· 17:49

How to avoid disaster when vibe-coding a billing engine — Andrew Garvin, Stripe

Andrew Garvin discusses the complexities of building a billing engine, particularly when integrating advanced AI agents. He emphasizes that because billing involves deep business logic and real money, full autonomy is risky. The solution presented is using agentic tools (like Stripe Projects) to accelerate development into controlled test environments (sandboxes), rather than deploying directly to production. Key architectural components include portable 'skills files' for context and verbose error messaging for self-correction.

Key takeaways

  1. Agent Guardrails are Essential for Billing 11:53

    Billing carries deep business logic; therefore, the recommendation is to use coding agents only to accelerate development into a test environment (sandbox), not to ship directly to production. This minimizes risk when dealing with financial data.

  2. Skills Files Provide Contextual Guardrails 10:02

    To manage complexity, Metronome uses an extensible set of portable 'skills files' that provide necessary context and API knowledge to the agent, removing friction during setup and evolution.

  3. Shift from Seats to Credits (Usage-Based Pricing) 17:18

    The rise of agents operating entire systems necessitates a shift away from seat-based pricing models toward usage-based credit systems. This is crucial because the value may accrue to a single agent/user, not a fixed number of logins.

Watch on YouTube Full article

Productionizing LLM Gateways: Architecture, Tradeoffs and Hard Lessons — Kanish Manuja, Twilio thumbnail

· 16:24

Productionizing LLM Gateways: Architecture, Tradeoffs and Hard Lessons — Kanish Manuja, Twilio

This talk details the architecture and trade-offs involved in building an LLM Gateway—a middleware layer managing routing, authentication, fallbacks, and governance between applications and model providers. The core challenge is that availability, latency, guardrails, and cost cannot all be maximized simultaneously during degradation. Key architectural advice includes preferring per-request fallbacks over blind retries or circuit breakers, tracking P99 latency per model/route (not gateway-wide), and treating guardrails as unreliable services requiring fail-open/fail-close decisions.

Key takeaways

  1. LLM Gateway Core Trade-offs 2:11

    An LLM gateway must manage a permanent fight between availability, latency, guardrails, and cost. Degradation forces the system to sacrifice one of these four elements (1:21).

  2. Fallback Strategy 2:33

    Instead of blind retries or circuit breakers, implement per-request fallbacks (trying Model A, then B if A fails) or parallel requests for low-latency needs. This prevents multiplying cost and tail latencies (2:33).

  3. Latency Measurement Best Practices 7:08

    Do not measure gateway-wide latency; instead, track P99 per model and per route. Setting timeouts on a per-model/per-route basis is critical to preventing silent outages (7:08).

  4. Guardrails as Services 10:40

    Treat guardrails (e.g., toxicity filters, PII checks) like any other service that can fail. Teams must decide in advance whether the system should 'fail open' (serve request despite failure) or 'fail close' (block request) (10:40).

  5. Centralization vs. Governance 13:02

    While many teams seek a central gateway, the underlying need is often centralized governance (e.g., cost tracking, rate limiting), which can be achieved by decentralizing traffic while centralizing policy enforcement (13:02).

Watch on YouTube Full article

How to Generate Mergeable Code with a Context Engine — Peter Werry, Unblocked thumbnail

· 18:36

How to Generate Mergeable Code with a Context Engine — Peter Werry, Unblocked

The presentation introduces the concept of a Context Engine designed to overcome limitations in current AI agents. Agents often suffer from 'satisfaction of search' and lack deep organizational context (intent, conventions, past decisions), behaving like new employees who reset their knowledge for every task. A Context Engine solves this by ingesting data from diverse sources—including GitHub PRs, Slack discussions, and architecture documents—to provide a comprehensive understanding that allows agents to generate accurate plans, show their work, and prevent compounding errors during complex development tasks.

Key takeaways

  1. The Context Problem in AI Agents 6:59

    Agents struggle because they lack access to 'unknown unknowns'—the critical organizational context like team conventions or architectural rationale. Simply attaching a wiki is insufficient; the agent needs guided, synthesized information.

  2. The Compounding Effect of Context 16:43

    The true value of a context engine is not in solving the first task, but in preventing compounding errors. Without proper context, agents may operate on wrong assumptions, forcing costly loops and significantly increasing time/token usage.

  3. The Role of Seniority Signals

    Advanced review agents can use signals like reviewer seniority or expertise to boost the visibility of important past comments, ensuring critical institutional knowledge is surfaced during code reviews.

Watch on YouTube Full article

Can LLMs Write Fast Multi-GPU Kernels? — Simran Arora, Together AI thumbnail

· 30:00

Can LLMs Write Fast Multi-GPU Kernels? — Simran Arora, Together AI

Multi-GPU AI workloads are increasingly bottlenecked by inter-node and intra-node communication links rather than individual GPU compute power. The speaker introduces ParallelKittens, a set of minimal primitives designed to simplify writing high-performance multi-GPU kernels. A benchmark called ParallelKernelBench tests whether frontier LLMs can generate optimized CUDA kernels for complex real-world patterns (e.g., data parallelism across tensor/expert dimensions). While models show promise in generating correct kernels, their ability to reason about critical architectural trade-offs—such as collective ordering, data partitioning, or choosing between transfer mechanisms (Copy Engine vs. TMA)—remains limited.

Key takeaways

  1. The Bottleneck Shift 17:04

    Improvements in compute (e.g., A100 to B200) have outpaced improvements in communication links (Intra-node: 3x; Inter-node: 2x). This forces the bottleneck off the individual GPU and onto the interconnects, causing standard PyTorch/NCCL baselines to fall below 50% of their communication-aware roofline.

  2. Kernel Development Simplification 2:20

    The speaker's team developed ParallelKittens, a small set of primitives that adds minimal lines to a single GPU kernel but enables state-of-the-art multi-GPU performance in production environments (e.g., Together AI).

  3. LLM Performance on Kernel Generation 20:40

    On the ParallelKernelBench, the best frontier models solved 28 out of 87 problems zero-shot. While scaling up attempts increased correctness to 36/87, the performance gain (speedup) plateaued near 31%. Failures are not syntax but stem from inability to reason about complex trade-offs.

Watch on YouTube Full article

How Anthropic Builds: Lessons from Labs — Mike Krieger, Anthropic thumbnail

· 26:11

How Anthropic Builds: Lessons from Labs — Mike Krieger, Anthropic

Mike Krieger discusses the evolution of building with AI models, emphasizing that ambition requires being 'unreasonable' in tool usage and process design. He details advanced development workflows—such as porting large codebases (e.g., Python to TypeScript) over a weekend using LLMs—and outlines modern organizational structures for research labs (like Anthropic's), which prioritize rapid iteration through 'persevere or pivot' cycles rather than rigid project management. Key technical shifts include moving from task delegation to expressing end-state goals, and utilizing advanced features like tagging for multi-agent, proactive code development.

Key takeaways

  1. Be Unreasonable in AI Usage 4:15

    The first generation of AI products often constrained access to tools and degrees of freedom. To maximize potential, users must be 'unreasonable' in their prompts, moving beyond simple task delegation to defining the desired end state.

  2. The Importance of Intent Over Code Lines 17:17

    In large codebases (e.g., 2,000 line PRs), the bottleneck is no longer review time but human comprehension. The trend is shifting toward sharing 'Claude code artifacts' that explicitly lay out intent, trade-offs, and rationale alongside the code.

  3. Labs Structure for Rapid Iteration 19:13

    Anthropic Labs operates on a two-week 'persevere or pivot' cycle. Teams are assembled around 'bets,' and the structure deliberately avoids tying people to specific projects, allowing for quick disbandment and reassembly.

  4. Scaling Requires Pre-Measurement 23:50

    Drawing from Instagram's scaling experience, it is crucial to pre-measure everything that might be needed (metrics) and implement thoughtful knobs and feature flags for dynamic runtime configuration.

Watch on YouTube Full article

The Agentic Commerce Stack — Ahnaf Prio, Best Buy thumbnail

· 20:38

The Agentic Commerce Stack — Ahnaf Prio, Best Buy

The talk outlines the architectural shift required for 'Agentic Commerce,' moving beyond brittle browser automation (like DOM reading or screenshotting) toward standardized protocols. The core solution involves defining specific primitives—such as MCP, A2A, ACP, UCP, and AP2—that allow AI agents to interact directly with merchant APIs without triggering fraud alarms. Successful implementation requires rigorous testing using behavioral and protocol compliance 'evals.'

Key takeaways

  1. Agentic Commerce Scope 2:08

    Approximately 45% of all agent sessions on major platforms (e.g., ChatGPT, Google Gemini) are related to shopping, indicating a massive market opportunity ($7B to $65B by 2030).

  2. Failure of Early Agents 5:08

    Early attempts using screenshots and reading the DOM were slow, clunky, and brittle. Furthermore, automated browser actions often trigger fraud alarms at the payment stage.

  3. The Need for Standardization 7:36

    To scale, commerce must standardize its primitives. Instead of relying on search catalogs, merchants should provide structured product feeds to protocols like ACP and UCP. The process involves the agent calling a merchant checkout API directly (no browser needed).

  4. Payment Mandates with AP2 16:41

    Autonomous payments require more than just tokens. AP2 (Agentic Payment Protocol) is an extension that mandates defining the authorizing party, a spend ceiling, and a revocation URL.

  5. Testing with Evals

    Building agentic commerce requires intense testing (evals) focused on behavior, protocol compliance, and latency benchmarks. Failure to test can lead to agents being misused in production (e.g., asking programming questions).

Watch on YouTube Full article

KV Cache-Aware Routing and P/D Disaggregation on Kubernetes — Yuchen Fama & Ashish Kamra, Red Hat thumbnail

· 21:48

KV Cache-Aware Routing and P/D Disaggregation on Kubernetes — Yuchen Fama & Ashish Kamra, Red Hat

This talk details advanced strategies for optimizing LLM inference in complex agentic workloads, moving beyond the limitations of steady-state public benchmarks. The focus is on two critical levers: KV Cache-Aware Routing and Prefill/Decode (P/D) Disaggregation. Implementing these techniques—using frameworks like LLMD—significantly improves latency and throughput by managing volatile cache usage and separating compute-bound prefill from memory-bandwidth-hungry decode phases, particularly in the middle concurrency band.

Key takeaways

  1. Agentic Workloads vs. Benchmarks 5:29

    Real-world agentic workloads exhibit chaotic multi-turn interactions (up to 3,000 turns) with high cache hit rates (>90%) and massive input/output ratios (often >100:1), which standard public benchmarks fail to capture [0:00], [3:29].

  2. KV Cache Routing Optimization 10:28

    Implementing KV cache-aware routing (via Endpoint Picker) is a cost-effective optimization, as the token cost difference between cached and uncached tokens can be as high as 10x [5:12]. This helps solve Time to First Token (TTFT) issues.

  3. P/D Disaggregation Benefits 15:28

    Separating prefill and decode into independent, scalable pods prevents 'phase interference'—where a long prefill stalls token generation (decode)—leading to drastically reduced P99 Inter Token Latency (ITL) from ~900ms down to ~100ms [9:28], [10:46].

  4. Prerequisites for PD 17:26

    Effective P/D disaggregation requires an advanced, high-speed network fabric like RDMA or RoCE to facilitate the transfer of KV caches between prefill and decode workers [10:46]. If such a fabric is unavailable, aggregated serving may be preferable.

Watch on YouTube Full article

The Death of Developer Advocates — Stephanie Jarmak, Sourcegraph thumbnail

· 18:16

The Death of Developer Advocates — Stephanie Jarmak, Sourcegraph

Developer Relations (DevRel) is evolving from focusing solely on human developers to incorporating AI agents as primary users and recommenders. The core strategy must shift toward Generative Engine Optimization (GEO), ensuring that product documentation and tooling are machine-readable, highly discoverable in registries (like MCP), and directly address specific pain points encountered by autonomous agents.

Key takeaways

  1. The Agent as a New User Persona 10:40

    Agents interact with tools by calling APIs, reading documentation, and recovering from errors. They represent a critical new user base that must be measured for friction points (e.g., burning an entire turn on a guessed parameter) to improve the developer experience.

  2. Measuring Agent Interaction and Friction 8:56

    Benchmarking tools, such as CodeScaleBench, must track agent traces with and without product tooling. This data reveals where agents fail or struggle, allowing teams to fix underlying tool interaction issues.

  3. Shifting Focus to GEO (Generative Engine Optimization) 12:22

    The goal of DevRel is moving from Search Engine Optimization (SEO) to Generative Engine Optimization (GEO). Content must be structured, authoritative, and designed for agents to quote accurately when recommending a product.

  4. DevRel as an Interdisciplinary Function 15:15

    The role of DevRel is no longer confined to one department; it requires collaboration across Engineering (building agent interfaces/evals), Product (owning the end-to-end agentic experience), and Marketing (managing content funnels for agents).

Watch on YouTube Full article

How AI Agents Let GTM Teams Scale — Justin Joyce, Cloudflare thumbnail

· 19:15

How AI Agents Let GTM Teams Scale — Justin Joyce, Cloudflare

Justin Joyce details how Cloudflare utilizes a three-pillar approach powered by AI agents to solve scaling issues in traditional Go-To-Market (GTM) operations. The core problem—that manual processes and knowledge gaps limit efficiency—is addressed by building self-service capabilities, automating data analysis, and proactively pushing insights to users. This framework allows non-technical staff to query complex data using 'skill files' and enables reps to access expert-level information via an internal agentic workspace (Cloudflare OS).

Key takeaways

  1. The GTM Scaling Problem 5:20

    Traditional GTM processes suffer from the 'context gap' (switching between different customer calls) and the 'expert gap' (inconsistent execution among reps), leading to significant inefficiency. Back-office teams often rely on manual work in Excel or limited dashboards, which fail to meet all operational needs.

  2. Pillar 1: Scaling Analysis via Skill Files 10:53

    To empower non-SQL users, the team built role-specific 'skill files.' These allow business users to ask questions of data directly and quickly, eliminating bottlenecks that previously required a dedicated data engineer. This capability is used both for back-office analysis and building GTM skills.

  3. Pillar 2: Scaling Insight (Pushing the Story) 15:00

    Instead of forcing users to search dashboards, insights are proactively delivered through synthetic weekly summaries. This is achieved by transforming data dimensions (time, manager, metric) and using a multi-agent workflow: a first draft agent, a second reviewer agent for veracity checks, and a third 'tone agent' that crafts the message, ensuring risks and opportunities are weighted equally.

  4. Pillar 3: Self-Service via Cloudflare OS 17:15

    The internal tool, Cloudflare OS, is an agentic workspace running on Workers and Durable Objects. It allows GTM teams to perform complex tasks—such as building QBR decks, account plans, or forecast briefs—by interacting with curated expert skills without needing manual intervention.

Watch on YouTube Full article

Knowledge Systems: The New GTM Stack — Jeffrey Wang, Exa thumbnail

· 18:49

Knowledge Systems: The New GTM Stack — Jeffrey Wang, Exa

Jeffrey Wang argues that Go-To-Market (GTM) strategy must be treated as an AI engineering problem. The core thesis is that GTM is fundamentally a data problem, requiring the creation of a 'live model of your world' that autonomous agents can act upon. He details systems like Exa (a search engine for agents), the ICP dashboard for classifying the Total Addressable Market (TAM), and Request Lens for real-time customer signal detection. Key architectural principles include making the system API-first, recognizing that consistent UIs still complement flexible chatbots, and prioritizing arbitrary customizability over rigid build vs. buy decisions.

Key takeaways

  1. GTM as a Data Problem 4:56

    The goal is to build a live model of the world—combining internal data (customer usage) with external data (web activity, company information)—that agents can programmatically act on. This shifts GTM from a purely sales function to an engineering challenge.

  2. Agent-First Requires API-First 16:59

    For any agent system (whether it's a GUI or a chatbot) to access data, the underlying systems must expose robust programmatic interfaces (APIs). This is critical for enabling agents to function.

  3. System Components: ICP Dashboard & Request Lens 8:38

    The ICP dashboard uses Exa's embeddings over the internet to classify every company in the TAM and estimate anticipated spend. Request Lens provides real-time alerts when significant customer signals occur (e.g., signups, search surges).

  4. The Value of AI Cloning (Jeffbot) 13:42

    An agent can be trained on historical data to mimic a user's professional style and decision-making. Jeffbot was built by analyzing 760 emails and hundreds of past decisions, creating 'evals' to calibrate its judgment against the founder’s own behavior.

Watch on YouTube Full article

How We Got LLMs to Recommend Our Open Source Library — Christopher Burns, Inth thumbnail

· 16:27

How We Got LLMs to Recommend Our Open Source Library — Christopher Burns, Inth

The talk details how modern developer experience primitives must adapt for consumption by Large Language Models (LLMs) and autonomous agents. The core argument is that optimizing documentation requires moving beyond traditional SEO methods to focus on agent-facing artifacts. Key strategies include manually curating `LLMs.txt`, serving bundled markdown files, and ensuring the repository structure (`node_modules`) contains necessary context for coding agents.

Key takeaways

  1. Agent Inbound is the New Standard

    Inbound traffic sources are shifting from human discovery to LLMs (e.g., Claude, ChatGPT) recommending libraries like C15T. This requires optimizing for 'agent primitives' rather than just developer experience.

  2. Manual Optimization Beats Automation 9:52

    For critical files like `LLMs.txt`, manually writing the content is significantly more effective than generating it automatically; 'forty good lines beat a thousand lines of noise.'

  3. Bundling Context in Node Modules

    Coding agents rarely visit live documentation sites. To improve discoverability, developers should ship bundled markdown documents and an `AGENTS.md` file directly within the package's `node_modules` directory.

Watch on YouTube Full article

Building GTM AI Agents: Lessons from Deploying to 6,000 Users — Sait Izmit, Snowflake thumbnail

· 20:39

Building GTM AI Agents: Lessons from Deploying to 6,000 Users — Sait Izmit, Snowflake

This talk details the process of building and scaling an internal Go-To-Market (GTM) AI assistant using Snowflake Co-work. The speaker emphasizes that successful deployment hinges less on technological capability and more on strategic execution: prioritizing quality over coverage, managing user trust, and planning for continuous architectural evolution. The system has processed over one million questions for 6,000 users, evolving from simple agent instructions to a complex architecture involving semantic views, skills, and MCP connections.

Key takeaways

  1. Quality Over Coverage 6:56

    Focusing on high accuracy (e.g., 95% correct) for a smaller set of critical questions is more effective than attempting to cover all possible data points with lower accuracy, as the first few interactions build user trust.

  2. Phased Rollout and Activation 9:06

    AI tools must follow a controlled launch process: Pilot (proving accuracy), Beta (e.g., 10% of users, tracking >70% retention rate), and General Availability (GA). The biggest failure point is often activation and change management, not the technology itself.

  3. Addressing the Collapsing Wow Factor 14:16

    After initial novelty wears off, the roadmap must evolve beyond simple Q&A. The progression should move from 'Talk to your data' (democratization) to 'Automate workflows' (integrations/MCPs), then to 'Team building skills,' and finally 'Hyper-personalization.'

Watch on YouTube Full article

The Missing Layer in Agentic AI — Giedrius Šteimantas, Oxylabs thumbnail

· 15:04

The Missing Layer in Agentic AI — Giedrius Šteimantas, Oxylabs

The video addresses a critical gap in agentic AI: the lack of robust infrastructure for interacting with the open web. The speaker argues that relying solely on large language models (LLMs) or general browser automation is inefficient, expensive, and unreliable. By applying principles from professional web scraping—specifically prioritizing cost control, validating content before processing, and using a browser only when absolutely necessary—the agent's performance can be dramatically improved across all stages of the purchase workflow.

Key takeaways

  1. The Core Problem in Agentic AI 13:55

    Many agents fail or waste resources because they assume an HTTP 200 status code means valid content. Feeding LLMs large HTML blocks containing CAPTCHAs or non-product data leads to wasted tokens (e.g., wasting 70% of tokens when only three out of ten pages are valid).

  2. Discovery Stage Optimization 9:50

    Instead of using a browser with a predefined list of retailers, the agent should use a dedicated search API. This approach returns compact JSON (<2,000 tokens), is fast (<700ms), and allows the agent to fan out queries across many popular search engines.

  3. Decision Stage Optimization

    The decision stage can be optimized by replacing browser scraping with a dedicated scraper API. This ensures only valid content is returned, fails loudly (with explicit errors on blocks), supports markdown, and allows parallel requests while billing only for successful results ('No cure, no pay').

  4. Checkout Stage Enhancement

    Since the checkout process requires highly dynamic interaction, a browser is necessary. The solution involves hardening the agent using Playwright MCP combined with an Oxylabs headless browser that provides stealth, residential proxy support, and geolocation capabilities.

Watch on YouTube Full article

Einstein Arena: Harnessing Collective Agent Intelligence for Open Science — James Zou, Together AI thumbnail

· 16:56

Einstein Arena: Harnessing Collective Agent Intelligence for Open Science — James Zou, Together AI

The presentation advocates for a paradigm shift in AI agent development: moving from designing restrictive 'workflows' to building flexible 'environments.' These environments provide infrastructure, incentives, and guardrails (like the Einstein Arena and DSGym) that allow agents to collaborate and compete on open-ended problems, leading to emergent collective intelligence and solving complex scientific and computational challenges.

Key takeaways

  1. Environment Design vs. Workflow Design

    The core thesis is that specifying *where* an agent works (the environment) is superior to telling it *how* to work (the workflow), as environments enable greater creativity and intelligence emergence.

  2. Einstein Arena: Open Scientific Collaboration 0:05

    This platform allows agents to collaborate on open-ended scientific problems, featuring curated problems, a deterministic verifier, a discussion forum, and a live leaderboard. Agents achieved new solutions for the kissing number problem in 11 dimensions (reaching 604 spheres) through collaboration.

  3. DSGym: Data Science Evaluation Environment 0:11

    DSGym is a unified environment for evaluating and training data science agents, featuring curated tasks across diverse domains (biology, physics, economics). It addresses the vulnerability of existing benchmarks to 'shortcuts' by requiring execution-verified trajectories.

Watch on YouTube Full article

The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp thumbnail

· 20:51

The Agent Behind the Curtain: Building the Oz Cloud Agent Platform — Safia Abdalla, Warp

The presentation details the architecture and philosophy behind Warp's cloud agent platform, emphasizing that a successful developer tool must 'absorb complexity before it reaches the user.' The platform achieves this by providing structured environments (sandboxes) and flexible integration points (multi-harness support). Core functionality revolves around advanced agent orchestration—managing complex workflows across multiple sub-agents via both prompting (`/orchestrate`) and comprehensive API exposure. This approach allows non-developers to build sophisticated tooling on top of the system, significantly automating tasks like issue triage and pull request reviews in open-source repositories.

Key takeaways

  1. Platform Complexity Absorption 0:03

    A core principle is that platforms must hide underlying infrastructure complexity from the user. This includes managing where agents run (sandboxes) and supporting diverse developer preferences without fragmentation.

  2. Multi-Harness Support 0:05

    The platform accommodates various developer workflows and tools (harnesses), ensuring consistency by providing structured guardrails around the chosen tool, regardless of whether it is a custom or native solution.

  3. Agent Orchestration 0:08

    Since real engineering rarely fits into one prompt, agents are designed to orchestrate sub-agents for complex tasks. This can be triggered via a dedicated command (e.g., `/orchestrate`) or programmatically through the exposed API.

  4. API Composability 0:09

    All key primitives—including spinning up agents, managing compute environments, and handling artifacts—are exposed via a robust API. This allows external users (even non-engineers) to build custom tooling (e.g., Slack bots) on top of the platform.

Watch on YouTube Full article