Topic

Distributed Systems

All digests tagged Distributed Systems

The Frontier AI Inference Cloud for Agents — Byung-Gon (Gon) Chun, FriendliAI thumbnail

· 14:59

The Frontier AI Inference Cloud for Agents — Byung-Gon (Gon) Chun, FriendliAI

The talk outlines the shift from traditional request-based LLM inference (chat) to complex, task-based agentic inference. Because agents run in long loops (plan, act, observe, repeat) and generate massive context prefixes, standard inference stacks fail. FriendliAI addresses this by presenting an 'inference cloud for agents' built on four pillars: Prefix Caching, hierarchical KV Cache Management, Cache Aware Routing, and Agent Aware Scheduling. This architecture enables open-weight models (like GLM 5.2) to achieve frontier quality at a fraction of the cost of closed models, making complex, multi-step agents economically viable for production.

Key takeaways

  1. The Unit of Work Shifts from Request to Task 5:18

    In chat, the unit is the request (optimizing for low latency). In agents, the unit is the task, which runs autonomously for minutes or hours. Optimization must therefore focus on end-to-end task latency, not single-call latency. (3:18)

  2. Open Weights Achieve Frontier Quality at Lower Cost 2:06

    Open-weight models are now capable of completing complex agentic tasks (e.g., building a tower defense game) at a usable level, rivaling closed models. For the same task, GLM 5.2 (open-weight) was approximately 5.6 times cheaper than Anthropic's Opus 4.8. (2:06)

  3. The Four Pillars of Agentic Inference Cloud 11:42

    To optimize for task latency, the stack relies on: 1) Prefix Caching (computing shared prefixes once); 2) Hierarchical KV Cache Management (across GPU, host, and disk); 3) Cache Aware Routing (sending requests to replicas holding the prefix); and 4) Agent Aware Scheduling (understanding the long-term program context). (7:02)

Watch on YouTube Full article

Large clusters for small models — Daniel Svonava, Superlinked thumbnail

· 25:07

Large clusters for small models — Daniel Svonava, Superlinked

The talk addresses the shift toward using small, specialized open-source models for AI workloads, which offers massive cost and latency advantages over managed, large-scale APIs. However, serving a diverse fleet of these small models (e.g., a contract review agent using nine different models) presents significant infrastructure challenges. Traditional top-down routing methods and proprietary serving tools are insufficient. The speaker introduces Superlinked's open-source architecture, which utilizes a gateway and a shared queue (using uNATS Jetstream) to allow workers to pull tasks and form their own optimal batches, thereby achieving double the cluster throughput.

Key takeaways

  1. Small Models vs. Large APIs

    Small open-source models can run on older, more affordable GPUs (e.g., two or three generations old), offering orders of magnitude cost savings and latency improvements compared to managed endpoints.

  2. Task Specialization 5:42

    Instead of using one large, generalized model, optimal performance is achieved by slicing the workload into tasks and deploying a specific, fine-tuned model for each task (e.g., a contract review agent running nine different models).

  3. Infrastructure Bottlenecks 10:37

    Serving diverse small models is complicated by three issues: 1) Open-source serving tools require extensive, custom tuning (a 'do-it-yourself' research project). 2) Traditional top-down routers choke on many small, fast requests because their view of worker state is stale. 3) Model adaptation (LoRAs, fine-tunes) creates friction between AI and infrastructure engineers.

  4. Decentralized Serving Architecture 17:30

    The proposed solution uses a gateway to annotate requests and drop them into a shared queue. Workers then pull tasks from this centralized queue and form their own batches, which significantly improves GPU utilization and cluster throughput.

Watch on YouTube Full article

Are LLM Performance Benchmarks Reliable? — Ashok Chandrasekar & Jason Kramberger, Google thumbnail

· 16:07

Are LLM Performance Benchmarks Reliable? — Ashok Chandrasekar & Jason Kramberger, Google

This talk addresses the critical issue of unreliable LLM performance benchmarks, arguing that often the failure point is the benchmark harness itself, not the inference server. The speakers introduce `Inference Perf`, a CNCF project, which provides a standardized, high-fidelity solution. This tool solves common pitfalls—such as Python's Global Interpreter Lock (GIL) limitations, client-side latency inflation, and non-reproducible configurations—by offering declarative configuration, robust load generation across multiple processes, and combined client/server telemetry for accurate production-scale measurement.

Key takeaways

  1. Benchmark Harness vs. System Under Test

    Many performance discrepancies are incorrectly attributed to the server when the fault lies with the benchmark harness. Issues include GIL limitations in Python, client-side latency inflation (e.g., up to 58 seconds), and non-deterministic settings (e.g., model temperature set to zero).

  2. Need for High Metric Fidelity

    Production-scale benchmarking requires observing both the system under test and the client's behavior simultaneously. The proposed solution, `Inference Perf`, provides client-side telemetry alongside server metrics to ensure accurate diagnosis.

  3. Standardization of Workloads

    The `LLMD` project provides a published workload catalog defining state-of-the-art inference tasks (e.g., agentic generation, tree of thought, batch summarization) in a standardized, declarative format, improving reproducibility across different tools.

Watch on YouTube Full article

Operating Distributed Inference Systems at Scale — Nishant Gupta & Naman Ahuja, Meta thumbnail

· 19:51

Operating Distributed Inference Systems at Scale — Nishant Gupta & Naman Ahuja, Meta

Inference workloads are rapidly becoming foundational, hyperscale infrastructure, outpacing even major microservices. The complexity has shifted from optimizing models or kernels to mastering the orchestration layer—the 'control plane.' This requires treating a request as a distributed transaction, necessitating sophisticated scheduling and reliability mechanisms that account for seven axes (e.g., GPU generation, KV cache state, tenant priority). The core optimization metric must shift from 'cost per token' to 'cost per successful task.'

Key takeaways

  1. Inference as a Distributed Transaction 11:45

    Unlike traditional RPC calls, inference involves multiple network hops (gateway, router, scheduler, runtime) where any step can retry, time out, or fail. Reliability must therefore be managed by the control plane, which sees the entire workflow, especially when partial failures occur (e.g., after streaming 200 tokens).

  2. The Shift to Orchestration 3:50

    The value has moved from simple models to the orchestration layer. The system must manage complex interactions, such as a routing decision changing the cache hit rate, which subsequently affects batch composition and GPU utilization. This coupling is the new complexity.

  3. Optimization Metric: Cost per Successful Task 14:05

    The goal of optimization is not merely minimizing cost per token or per request. The critical metric is 'cost per successful task,' as this reflects the actual value delivered to the user and accounts for retries, failures, and operational overhead.

  4. The Need for a Dedicated Control Plane 17:00

    As inference scales, it requires its own dedicated control plane, analogous to how Kubernetes managed VMs. This plane must manage resources beyond CPU/Memory, including GPU, KV cache, and token limits, to make optimal scheduling and routing decisions.

Watch on YouTube Full article

Docker, Adobe & tldraw: Where Should Your Agent Run? thumbnail

· 10:08

Docker, Adobe & tldraw: Where Should Your Agent Run?

The discussion explores the critical architectural question of where AI coding agents should execute, presenting four distinct models: Docker advocates for secure microVM sandboxes; Helix ML proposes centralized, dedicated computing resources for each agent; Adobe demonstrates running the agent loop entirely within the browser tab; and tldraw visualizes agents collaborating as characters on an infinite canvas. The consensus highlights the trade-offs between isolation, centralized control, and environmental fidelity.

Key takeaways

  1. MicroVMs for Agent Sandboxes 0:09

    Docker recommends using micro VMs instead of traditional containers for agent sandboxes because enterprise security teams view shared kernels as an unacceptable isolation boundary.

  2. Centralized Agent Infrastructure 3:03

    Helix ML argues for giving every agent its own dedicated computer on centralized infrastructure (e.g., Kubernetes) to facilitate seamless handoffs of work across global time zones.

  3. Browser-Native Agent Loops 7:33

    Adobe demonstrated an agent that runs its entire loop and controls the browser from within the browser tab, showcasing the concept of the 'self-licking ice cream cone' (SLICC).

  4. Collaborative Canvas Agents 6:13

    tldraw presents agents as interactive characters on a canvas that can coordinate, plan, and execute tasks as a team, allowing for simultaneous, visible collaboration.

Watch on YouTube Full article

The Universal Remote Control for AI — Alex Hancock, Block thumbnail

· 11:01

The Universal Remote Control for AI — Alex Hancock, Block

The talk addresses the lack of a standardized client-to-harness interface in the agentic AI stack. While the Model Context Protocol (MCP) provides a strong standard for agents performing actions (the agent going out), a standard for client software to issue tasks and receive updates is missing, leading to bespoke, non-interoperable systems. The speaker proposes the Agent Client Protocol (ACP), developed by the Zed and JetBrains teams, which standardizes communication using JSON RPC. ACP allows multiple, independent client applications (e.g., editors, terminal clients) to drive the same agent harness, significantly increasing interoperability and enabling the modular placement of the four core components: client, harness, tools, and model, especially when remote transports are implemented.

Key takeaways

  1. The Need for Client Standardization 2:03

    Currently, many agent harnesses expose custom or bespoke interfaces, often requiring a single, dedicated client application. This lack of a universal standard hinders interoperability, comparing it to needing a different browser for every website.

  2. ACP as the Universal Remote Control 5:02

    The Agent Client Protocol (ACP) was developed to allow a single, high-quality client implementation (like an editor) to control any harness, regardless of the underlying system. It is designed to be neutral and extensible.

  3. Modular Agentic Stack Architecture

    By implementing remote transports for ACP, MCP, and model endpoints, the entire agentic stack becomes modular. The client, harness, tools, and model can all be independently placed (e.g., client on a desktop, harness in a container, model in the cloud).

Watch on YouTube Full article

Are Agent Swarms USEFUL? OpenAI’s GPT-6 Astra SWARM Takeaways thumbnail

· 39:16

Are Agent Swarms USEFUL? OpenAI’s GPT-6 Astra SWARM Takeaways

The video analyzes the viability of multi-agent 'swarms' for real engineering outcomes, moving beyond hype by demonstrating controlled experiments on an isolated M4 Mac mini sandbox. The speaker runs three distinct swarms (GLM 5.3, DeepSeek v4 Pro, and Gemini 3.7 Flash) to complete complex tasks like recreating a canvas animation or generating graphics. Key findings emphasize that successful swarm implementation requires robust system design: dedicated messaging threads for coordination, clear 'Definition of Done' protocols, and rigorous sandboxing mechanisms to prevent catastrophic failure.

Key takeaways

  1. Communication is the primary unlock 23:50

    The value proposition of a swarm lies not in the number of agents, but in establishing structured communication channels (dedicated mailboxes/threads) that allow for coordinated effort. This messaging system must be engineered into the architecture.

  2. Mandatory Alignment and Kill Switches

    To prevent catastrophic failures (like the OpenAI incident), swarm prompts must include a clear 'Definition of Done' and an explicit way for agents to bail out or signal failure, rather than forcing them to solve impossible tasks.

  3. Sandboxing is Non-Negotiable

    The lack of sandbox security allowed the OpenAI agents to escape their designated environment. Robust sandboxing (e.g., local M4 Mac mini or exe.dev) must be the last line of defense in any multi-agent system.

  4. Coordination Overhead is Real

    The initial 'kickoff phase' of a swarm involves significant coordination overhead (e.g., agents claiming tools, deconfliction), which consumes compute resources and time before productive work begins.

  5. Swarms are Dangerously Viable

    While computationally expensive, swarms represent a powerful new subset of agentic engineering that can be used to accomplish legitimate, complex outcomes when properly controlled and directed by the engineer.

Watch on YouTube Full article

AI Agents Are Just Distributed Systems Now — Salman Munaf, TikTok thumbnail

· 19:48

AI Agents Are Just Distributed Systems Now — Salman Munaf, TikTok

The core argument is that AI agents, once they interact with external services (tools/APIs), cease being purely model problems and become complex distributed systems challenges. Building reliable agents requires incorporating robust distributed systems thinking—focusing on failure modes, state management, transactionality, and security controls—rather than just improving the LLM itself.

Key takeaways

  1. AI Agents as Probabilistic Coordinators 5:46

    Unlike traditional deterministic workflows that follow a predefined decision tree, AI agents act as probabilistic coordinators. This variability necessitates strong external controls (e.g., circuit breakers, spending ceilings) to ensure determinism and prevent severe consequences.

  2. Handling Failure: Timeout vs. Failure 11:59

    A timeout does not mean failure; it means unknown. To prevent unsafe side effects (like double refunds), agents must utilize request IDs and idempotency keys, allowing for status lookups to confirm if an action already succeeded.

  3. State Management and Context 17:37

    Context that influences an action is state. This state can become stale or conflict with the authoritative source of truth, requiring explicit invalidation and provenance tracking, much like managing a cache.

  4. Security and Control Boundaries

    Agents must operate with scoped credentials (separate read/write permissions) and limited tool access. Furthermore, human approval should be bound to specific actions, actors, and expiry times, not blanket privileges.

Watch on YouTube Full article

NVIDIA Dynamo in 5 Minutes: What Is It and Why Now? thumbnail

· 6:03

NVIDIA Dynamo in 5 Minutes: What Is It and Why Now?

NVIDIA Dynamo is a distributed serving layer designed to complement existing LLM inference engines (like SGLang, TensorRT-LLM, or vLLM). It addresses the complex challenges of scaling large language model inference across multi-GPU and multi-node clusters. Instead of being an inference engine itself, Dynamo coordinates workers, manages request routing, ensures fault tolerance, optimizes resource utilization through KV cache reuse, and provides a modular architecture for building complex production serving stacks.

Key takeaways

  1. Dynamo's Role in Scaling

    Dynamo acts as a distributed serving layer *around* inference engines. It coordinates the system to achieve multi-GPU and multi-node performance that single engines cannot provide alone. (0:32)

  2. Disaggregated Serving Efficiency 3:40

    It helps coordinate prefill (input prompt processing) and decode (token generation) phases across worker pools, which can have different resource needs, improving efficiency. (2:20)

  3. System Reliability and Scaling 5:05

    Dynamo provides crucial capabilities for production environments, including advanced request routing based on capacity/worker state, fault tolerance against node failures, and composability to connect various system components. (3:05)

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

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

Lecture 113: Every Microsecond Matters: Achieving Near Speed-of-Light Latency in GPU Collectives thumbnail

· 57:30

Lecture 113: Every Microsecond Matters: Achieving Near Speed-of-Light Latency in GPU Collectives

This presentation details advanced techniques for achieving near speed-of-light latency in GPU collective communication operations, crucial for modern distributed workloads like LLM inference and scientific computing. The core challenge addressed is the high overhead of traditional global memory barriers during collectives (e.g., AllReduce). The proposed solutions—including Sentinel synchronization, Low Latency (LL) protocols, and the novel LL128 atomic algorithm—eliminate these expensive barriers by using data arrival itself as a synchronization signal. These advancements are packaged into an experimental device-side API to improve performance significantly in large-scale GPU clusters.

Key takeaways

  1. Low Latency is Critical for Specific Regimes 3:58

    Collective latency matters most when message sizes are small, the operation is repeated many times (e.g., auto-regressive decoding), and communication sits directly on the critical path.

  2. Global Memory Barriers are a Major Bottleneck 10:38

    Traditional AllReduce implementations rely on global memory barriers, which can account for 40-50% of the total latency, even when optimizing the data movement itself.

  3. LL128 Atomic Algorithm Improves Scalability 22:45

    The LL128 atomic algorithm leverages 128-byte cache line atomic additions over NVLink, offering superior scalability and reduced scratch buffer space compared to previous low-latency methods.

  4. API Abstraction Simplifies Implementation 17:55

    A new experimental device-side API (Nickel LL Buffer) wraps these complex synchronization techniques (LL, Sentinel, etc.), allowing kernel writers to easily implement low-latency collectives without manually managing polling and buffer resets.

Watch on YouTube Full article

FinOps for AI Agents: Who Spent All the Tokens? — Tisha Chawla & Susheem Koul, Microsoft thumbnail

· 21:24

FinOps for AI Agents: Who Spent All the Tokens? — Tisha Chawla & Susheem Koul, Microsoft

The talk introduces TokenOps, a control plane designed to shift AI agent development from 'token maxing' (spending tokens) to 'value maxing' (maximizing value per token). It addresses the critical gap in current systems: the lack of cost governance between code execution and model calls. TokenOps operates out-of-band at the entire agent run level, utilizing a `boundary annotation` and `governor node` to implement sophisticated policies that can 'steer' an agent's behavior (e.g., instructing it to be more succinct) before hitting a budget cap, thereby preventing costly failures.

Key takeaways

  1. Shift from Token Maxing to Value Maxing

    The industry needs to move beyond simply spending tokens and focus on ensuring that every token spent has measurable business value. This requires proper attribution of costs back to specific agent runs.

  2. Run-Level Cost Control is the Missing Piece 2:38

    Existing tools (like model gateways) only control cost at the request level. TokenOps provides governance at the entire agent run layer, allowing control over complex loops and context growth.

  3. Steering vs. Halting

    Instead of simply halting an agent when a budget is exceeded (a circuit breaker), the 'steer' action uses a cost guard to predict overruns and injects instructions into the system prompt, guiding the agent toward more efficient outputs.

Watch on YouTube Full article

Stateless, Yet Durable: MCP Tasks v2 thumbnail

· 26:23

Stateless, Yet Durable: MCP Tasks v2

The session details MCP Tasks v2, an architectural evolution designed to enable durable, long-running workflows while maintaining a fundamentally stateless protocol design. Using Purchase Order processing as a concrete example, the talk contrasts the complexity and scalability issues of V1 (which relied on stateful server tracking and polling) with the simplified V2 approach. The key shift involves moving client responsibility for task ID persistence to durable storage and introducing a future notification mechanism to replace inefficient constant polling.

Key takeaways

  1. MCP Tasks v2 Simplification 17:53

    V2 eliminated the complex `task list` functionality (due to scalability concerns) and significantly changed how elicitation flows, simplifying the client-server protocol into basic polling and an explicit `update` API.

  2. Durability vs. Statelessness 4:28

    While the MCP protocol is stateless, the tasks themselves are designed as durable state machines (e.g., invoice processing), requiring robust mechanisms to track their lifecycle states (Working, Input Required, Terminal).

  3. Scaling Beyond Polling 23:50

    For massive scale (millions of tasks), constant polling is inefficient. The future direction involves implementing a notifications mechanism within the MCP Tasks protocol to allow idle tasks to consume zero resources until an event occurs.

Watch on YouTube Full article

Generative Video at the Speed of Light — Keegan McCallum, uRun thumbnail

· 8:43

Generative Video at the Speed of Light — Keegan McCallum, uRun

The presentation shifts the focus of generative video from improving quality (e.g., Sora) to maximizing efficiency and enabling long-horizon, real-time interaction. The core argument is that the limiting factor is no longer model fidelity but the serving infrastructure required for continuous, synchronized streaming. Key technical requirements include global GPU distribution, WebRTC/ICE/TURN setup, and complex pipelines capable of integrating multiple models (e.g., video-to-video transformation) in real time.

Key takeaways

  1. Shift from Quality to Efficiency 3:55

    The most significant axis of improvement is efficiency and long horizon generation, allowing for continuous streaming at a fraction of the cost compared to slower, high-quality generations. For example, real-time generation can be produced at about 1/100th the cost of minutes-long clips.

  2. Cost and Accessibility 6:24

    Generative video is becoming highly accessible: $10 can now buy roughly three hours of continuous generated video, while $50 could provide up to 15 hours of interaction.

  3. New Interaction Paradigms 7:18

    The technology enables new use cases beyond simple content creation, such as 'magic mirrors' (transforming a webcam feed in real time) and providing visual mediums for users who do not think primarily in text.

Watch on YouTube Full article

Taking Reinforcement Learning Cross Datacenter — Nan Jiang, Modal thumbnail

· 19:50

Taking Reinforcement Learning Cross Datacenter — Nan Jiang, Modal

This talk addresses scaling Reinforcement Learning (RL) post-training across geographically distributed compute resources by fundamentally changing the synchronization unit. Instead of shipping massive full checkpoints (up to 500 GB), the proposed method uses a small 'lossless patch' representing only the changes in visible weights, shrinking the transfer size from hundreds of gigabytes to potentially hundreds of megabytes. This enables the rollout fleet to operate elastically across different regions and providers, decoupling it from the central training cluster.

Key takeaways

  1. Decoupling RL Training from Compute Location 5:22

    The standard RL loop couples the trainer and rollout worker in a single fast-fabric cluster. The solution proposes that the 'rollout serving island'—a coherent endpoint or local group of endpoints—is the movable unit, allowing it to operate across scattered, autoscaled capacity (the 'bazaar') rather than being restricted to one perfect cluster (the 'cathedral').

  2. Sparse Weight Updates via Adam Absorption 8:05

    The core mechanism relies on the fact that while gradients are dense, the actual change in the served weight view is extremely small. This 'Adam absorption' phenomenon occurs because a typical Adam step (around 3 millionths) is far smaller than the BF16 rounding boundary (around 0.0039), meaning the visible value does not change significantly.

  3. Lossless Patch Synchronization 9:50

    The synchronization unit is redefined as a 'lossless patch' (a diff) rather than a full checkpoint. This patch, which includes the change index and replacement bits, allows the rollout engine to bitwise reconstruct the exact served version from a much smaller object.

Watch on YouTube Full article

Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO) thumbnail

· 56:30

Building Turbopuffer: Gergely Orosz (@pragmaticengineer ) × Simon Eskildsen (CEO)

The discussion provides a deep dive into building highly scalable and resilient infrastructure, focusing heavily on state management challenges in large-scale distributed systems. Key engineering lessons include moving beyond simple benchmarks to model real-world failure modes (e.g., connection layer failures), optimizing for P99 latency when using object storage like S3, and adapting architecture to current cloud constraints, particularly the increasing demand for CPUs driven by AI/RL workloads.

Key takeaways

  1. Modeling Failure in CI 20:46

    To ensure system reliability, it is crucial to simulate low-level failures (like database connection loss) rather than just mocking components. The use of custom proxies or tools like `GDB` allows testing the application's failure handling at the connection layer, uncovering issues that are difficult to reproduce in production.

  2. The Importance of P99 Latency 30:27

    When designing large-scale systems, especially those involving multiple round trips (like navigating a tree structure on S3), optimization must focus on the P99 latency, not just the average (P50). This is critical for accurate performance prediction.

  3. CPU Scarcity in AI Workloads 47:25

    The demand curve for CPUs is shifting right due to AI and Reinforcement Learning (RL) workloads, which require significant CPU cycles for training and general-purpose agent execution. This scarcity is a major constraint that cloud providers are managing through power allocation.

  4. Architectural Simplicity Wins 51:27

    The principle of 'simplicity above everything' was key to the development philosophy, allowing for rapid iteration and focusing on core functionality rather than complex features. This approach helped achieve significant cost reductions (e.g., reducing a client's bill by 95%).

Watch on YouTube Full article

MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal thumbnail

· 23:54

MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal

Cornelia Davis discusses MCP Tasks, a specification designed to enable durable, long-running asynchronous interactions for tools and agents that cannot complete in a single request/response cycle. The core challenge is maintaining state and functionality across infrastructure failures (network blips, process crashes) or human delays. While the initial V1 protocol was complex and stateful, the evolution to V2 significantly improves scalability by moving toward a stateless core and structured extensions, making it more viable for large-scale distributed systems.

Key takeaways

  1. The Problem of Long-Running Tasks

    Traditional request/response models fail when work takes time. MCP tasks solve this by allowing an agent to invoke a tool, receive a handle, and interact with that handle asynchronously, surviving disconnections and crashes.

  2. Durability is Paramount 6:43

    For the task to be reliable, it must be durable—meaning its state survives client disconnects, server outages, or human delays. This requirement adds significant complexity.

  3. V2 Moves Toward Statelessness 17:15

    The major improvement in the MCP Tasks V2 specification is its move toward a stateless core and structured extensions, addressing the inherent difficulties of managing stateful protocols in large-scale distributed systems.

Watch on YouTube Full article

Emulated: The Data for Fully Autonomous Software Engineers and Companies — Joseph Wang thumbnail

· 16:33

Emulated: The Data for Fully Autonomous Software Engineers and Companies — Joseph Wang

Emulated focuses on creating high-fidelity training data environments that simulate entire companies and complex infrastructure operations, moving beyond simple code diffs or single-node sandboxes. The core argument is that for AI agents to achieve true autonomy in mission-critical systems (like cloud providers), they must be trained on long-horizon tasks involving distributed cluster failures, resource provisioning across VPCs/subnets, managing cost constraints, and reasoning through real-world operational incidents.

Key takeaways

  1. The Data Gap in AI Agents 3:30

    Current benchmarks (e.g., SweBench Pro, Terminal Bench) limit agents to operating within a codebase, failing to capture the complexity of real-world tasks like PM communication, performance testing, or owning underlying infrastructure over years.

  2. Complexity Requires Full Simulation 6:10

    Real infrastructure work is not a simple code diff; it involves managing failing nodes, stale deprecated components, live traffic serving, and operational blast radius across distributed clusters.

  3. Limitations of Single-Node Sandboxes 10:40

    Standard post-training pipelines often use homogeneous single-node sandboxes. However, real cloud services require simulating resource provisioning (EC2, Cloud Run), VPCs, subnets, and security groups, which necessitates a multi-node sandbox with access to real infrastructure.

Watch on YouTube Full article

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

· 18:26

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

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

Key takeaways

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

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

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

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

  3. The Run Receipt Audit

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

Watch on YouTube Full article