The Video Signal

The Video Signal technical video digests

The Era of Compound Engineering — Kieran Klaassen, Every/Cora thumbnail

· 20:38

The Era of Compound Engineering — Kieran Klaassen, Every/Cora

The talk introduces 'Compound Engineering,' a methodology for building complex software products using AI by shifting focus from writing code to optimizing the system's memory and knowledge base. The core principle is that development efficiency increases when time is spent teaching the AI what it got wrong (system refinement) rather than just generating new features. This process inverts complexity accumulation, aiming for each subsequent feature to be easier to build than the last.

Key takeaways

  1. The Compound Engineering Loop 10:25

    The development loop involves Brainstorming $\rightarrow$ Planning $\rightarrow$ Working $\rightarrow$ Reviewing $\rightarrow$ Polishing $\rightarrow$ Compounding. The human must be 'brain-on' at both the start (defining the problem) and the end (raising the bar/taste).

  2. The 50/50 Rule of Improvement 13:30

    Allocate 50% of time to building the feature and 50% to teaching the system what it did wrong or how it can learn. This knowledge extraction is crucial for long-term efficiency.

  3. Token Efficiency through Memory 15:03

    Storing solutions and learnings within a repository (compounding) makes future interactions more token-efficient because the AI does not need to perform deep research or correction passes; the solution is already embedded.

  4. Inverting Complexity 20:38

    The goal of Compound Engineering is that each shipped feature makes the next one easier, counteracting the typical accumulation of complexity in software development.

Watch on YouTube Full article

IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork thumbnail

· 16:17

IT Admin for the AI Workforce — Sarthak Aggarwal, Decawork

Enterprises are adopting autonomous AI agents as a 'second workforce,' shifting focus from model behavior to operational safety and governance. The core challenge is managing agents that possess tools, private data, and delegated authority. To mitigate risks—exemplified by incidents like the Replit breach and zero-click CVEs like EchoLeak—the architecture must implement robust identity standards and strict privilege separation, ensuring that planning (intent) is separated from execution (action).

Key takeaways

  1. Capability vs. Employment Readiness 1:48

    A working demo only proves capability; it does not prove employment readiness. An agent with a goal, tools, private data, and delegated authority acts as an 'actor,' requiring governance controls like identity, owner definition, policy scoping, and reliable revocation.

  2. The Need for Agent Identity Standards 4:08

    Current identity systems (like OAuth token exchange) provide the right shape but lack a dedicated agent identity standard. Agents require a defined lifecycle—provisioning, authorization, monitoring, and revocation—mirroring human employee management.

  3. Privilege Separation Architecture

    To ensure bounded authority, the system must separate trusted intent from untrusted content processing. The Planner turns authenticated intent into a typed, logged plan, while the Executor runs that plan without holding standing credentials, preventing actions outside the defined scope.

Watch on YouTube Full article

Prototyping as Leadership: How a CTO Ships with AI Agents — Hursh Agrawal, The Browser Company thumbnail

· 18:18

Prototyping as Leadership: How a CTO Ships with AI Agents — Hursh Agrawal, The Browser Company

The speaker argues that autonomous AI agents have fundamentally changed the role of a leader, transforming 'building' from an extracurricular activity into a core job function. By leveraging overnight development loops, leaders can now prototype features, optimize LLM calls, and train custom models with minimal hands-on time. Success hinges on establishing robust organizational scaffolding, including trustworthy CI, feature flags, and rigorous code hygiene.

Key takeaways

  1. Building is Now Part of the Job

    Due to autonomous coding agents, the manager's schedule can now be used for building. This shift allows leaders to stay current with rapidly changing frontier models and demonstrate capabilities via working prototypes rather than just theoretical discussions.

  2. The Overnight Development Loop 10:56

    A core workflow involves a 'co-worker agent' gathering context (from Slack, Jira, Notion) into a comprehensive prompt. This prompt is then handed to a coding agent overnight (4–8 hours), resulting in a report and a functional package ready for review the next morning.

  3. Judgment Remains Human 7:05

    While modern models excel at execution, they are not yet reliable at judgment. Leaders must provide high-level context and strategic direction to guide the agents effectively.

Watch on YouTube Full article

The Last Human Code Review: Building Trust in AI-Generated Code — Itamar Friedman, Qodo thumbnail

· 18:54

The Last Human Code Review: Building Trust in AI-Generated Code — Itamar Friedman, Qodo

The bottleneck in modern software development is shifting from writing code to managing governance and context within the Software Development Life Cycle (SDLC). The speaker argues that AI models are no longer the primary constraint; instead, the critical challenge is codifying 'tribal knowledge'—the undocumented best practices, architectural contracts, and historical failure data held by senior developers. Future code review must transition from line-by-line diff checking to reviewing a comprehensive software graph that tracks inter-service dependencies and potential contract breaks across multiple concurrent Pull Requests (PRs).

Key takeaways

  1. The Bottleneck Shift

    The primary bottleneck is no longer writing code, but rather the governance layer within the SDLC. Organizations must address how to automate or enhance code review processes that validate architectural standards and business intent.

  2. Two Competing Philosophies 5:38

    Engineering leaders are split into two camps: those who insist every line of code requires human trust/review, and those who prioritize velocity by shipping bugs quickly and fixing them post-deployment. The chosen philosophy dictates the necessary tooling and governance strategy.

  3. Context is the Constraint 8:39

    The limitation is not model reasoning ability; it is the scattered nature of context—which resides across competing instruction files, internal team standards, and undocumented knowledge held in developers' heads or Slack threads. Codifying this context is paramount.

Watch on YouTube Full article

AI Agents vs Business Rules: Which Should Make Decisions? thumbnail

· 10:25

AI Agents vs Business Rules: Which Should Make Decisions?

The video compares Business Rules Engines (BREs) and AI Agents for automating decisions. BREs use explicit, deterministic logic (e.g., 'if X and Y then Z') and are ideal for structured data where the outcome is predictable. Conversely, AI agents utilize Large Language Models (LLMs) to process context and unstructured data, operating probabilistically by predicting next tokens. The optimal approach is often a hybrid model: using BREs first for quick, clear-cut decisions, and escalating complex or messy requests to an agent, which then passes its recommendation through deterministic guardrails and potentially human oversight.

Key takeaways

  1. Business Rules are Deterministic 2:05

    BREs operate on fixed conditions (e.g., 'order < 30 days' AND 'not final sale'), providing a consistent, predictable answer based on simple boolean logic. The output is a fixed function of the input.

  2. AI Agents are Probabilistic 2:50

    Agents use LLMs to work from goals and context, predicting responses from patterns learned during training. Because they operate over a probability distribution, running the same request twice can yield different outcomes.

  3. Hybrid Approach is Recommended 7:10

    The most effective decision-making systems combine both: BREs handle simple, structured requests first (due to speed and cost), while complex or ambiguous cases are escalated to an AI agent for judgment. The agent's output should then pass through deterministic guardrails.

Watch on YouTube Full article

Lecture 112: Production Megakernels for Real-World Inference thumbnail

· 58:05

Lecture 112: Production Megakernels for Real-World Inference

The lecture details 'megakernels,' a novel approach for optimizing production inference by moving beyond traditional kernel-based GPU programming models. Instead of launching multiple small kernels with associated overheads (e.g., global synchronization, SRAM clearing), megakernels fuse the entire forward pass into a single, persistent kernel running on an on-device interpreter. This significantly reduces launch overhead and enables fine-grained scheduling by allowing cores to dynamically pick up slack from slower units, maximizing GPU utilization.

Key takeaways

  1. Mega Kernels vs. Traditional Kernels 2:00

    Traditional GPU programming involves launching many small, self-contained kernels (grids) sequentially, incurring overheads like global synchronization and SRAM clearing between launches. Mega kernels persist the entire forward pass into one kernel, eliminating these boundaries.

  2. Compiler Search and Optimization 5:20

    The system uses a compiler search mechanism to decide whether to mega-kernelize an operation or leave it as a traditional kernel graph (e.g., using Kublo ops). The choice is based on minimizing wall-clock runtime, especially when arithmetic intensity is low.

  3. Symbolic Representation of Work 8:00

    To handle dynamic shapes (e.g., sequence length $S$ and context length $P$), the system represents tensor shapes, extents, strides, and barriers symbolically using expressions. This allows the compiler to generate a single work queue that doesn't need rebuilding when runtime dimensions change.

  4. Dependency Tracking (Barriers) 6:20

    Fine-grained dependency tracking is managed using barriers, which are treated as tensors. The goal is to maximize the number of barriers by partitioning tensor dimensions by dependency, allowing consumers to start processing before all producers have finished.

Watch on YouTube Full article

Why Your Enterprise Tech Stack Isn’t Ready for AI Agents — Christopher Lovejoy & Saul Howard thumbnail

· 19:15

Why Your Enterprise Tech Stack Isn’t Ready for AI Agents — Christopher Lovejoy & Saul Howard

The talk addresses why traditional enterprise tech stacks are insufficient for deploying AI agents in highly regulated industries like healthcare. The core argument is that focusing on achieving high accuracy during a Proof of Concept (POC) often leads to architectural debt when attempting productionization. To build scalable, compliant systems, engineers must prioritize non-functional requirements—specifically auditability, data security, and human oversight—from the outset. This requires adopting specialized primitives: immutable event logs, schema-driven object storage for sensitive data, and treating humans and models as equivalent agents.

Key takeaways

  1. Audit Trail vs. Developer Log 0:05

    In regulated environments (e.g., HIPAA, SOC 2), an audit trail must be a complete record of every action taken by the agent, every place it accessed data, and the authorization behind each step—not merely a developer log like those found in DataDog [5:19].

  2. Prioritize Constraints Over Accuracy 0:12

    Engineers should take regulatory constraints seriously first (e.g., auditability) and design the architecture around them, rather than bolting compliance requirements onto a high-performing POC [12:07].

  3. The Three Architectural Primitives 0:08

    Effective AI agent systems require three core primitives: an immutable append-only event log (for state tracking), schema-driven object storage (for data separation and Zero Trust), and human/model agent equivalency (for seamless escalation) [8:30].

  4. Evals as a Byproduct 0:10

    By implementing these three primitives, robust evaluation (evals) can emerge naturally—allowing for action replay, testing on production data without exposure, and comparing human vs. model performance—rather than being an afterthought [10:37].

Watch on YouTube Full article

Don’t be data poor — Anuj Iravane, Anterior thumbnail

· 16:46

Don’t be data poor — Anuj Iravane, Anterior

The talk addresses the critical problem of 'data poverty' in highly regulated domains like healthcare, where the most valuable data (Patient Health Information or PHI) is ephemeral and legally prohibited from being retained, anonymized, or derived for dataset creation. The core solution presented is synthetic data generation. This process involves reversing the standard inference workflow—starting by sampling a desired label and reasoning trace, and then generating the necessary unstructured medical record that would have produced it. The resulting pipeline uses an LLM-based, coarse-to-fine approach, ensuring high fidelity while maintaining domain expert control.

Key takeaways

  1. Reverse Inference for Data Generation 5:20

    Instead of running the forward task (Unstructured Data + Policy $\rightarrow$ Label), the method reverses this by sampling a label and a reasoning trace first, then generating the input data that supports it. This circumvents the diversity problem inherent in standard LLM generation.

  2. Domain Expert Ownership (Human-in-the-Loop) 11:30

    To ensure generated data is useful, domain experts (clinicians) must own the pipeline. This is achieved by enabling them to interject at any point in generation and modeling the entire workflow as a skills-based system running on an agent harness.

  3. Synthetic Data Fidelity 14:35

    The generated data can be highly accurate, with early results showing that in a blind review, clinicians were only able to distinguish synthetic from real records about 60% of the time.

Watch on YouTube Full article

How to build an AI-Native Health Company — Dan Feng, Maven Clinic thumbnail

· 17:19

How to build an AI-Native Health Company — Dan Feng, Maven Clinic

The transition to an AI-native company requires a fundamental shift in process and culture, moving away from lengthy planning cycles toward rapid, iterative development. While building software is now fast (minutes), the expense lies in arguing requirements. Build engineers must adapt by adopting short-cycle planning (2–4 weeks) and implementing rigorous, multi-layered testing strategies to manage AI-specific risks like hallucination. Key process changes include limiting Pull Request (PR) size (capped near 500 lines) and running integration tests multiple times to ensure reliability.

Key takeaways

  1. Shift Planning Focus 10:32

    Instead of spending weeks or months finalizing requirements, focus on delivering value in the next two to four weeks. Long-term plans (1 year) should only serve as directional inspiration, not rigid commitments.

  2. Redefining Code Review

    Due to increased code output from AI tools, traditional code review must change. Engineers can self-certify simple PRs, and large features should be stacked into multiple smaller PRs (capped near 500 lines) to maintain meaningful review quality.

  3. AI Reliability Testing

    For GenAI solutions, failure modes must be categorized (tolerable vs. not acceptable). Critical processes require consensus among multiple models (e.g., using different LLMs to review the same receipt) and running integration tests many times, rather than just once.

Watch on YouTube Full article

Managed Deep Agents - Tools thumbnail

· 6:21

Managed Deep Agents - Tools

This video details how to extend the functionality of a managed deep agent by implementing custom tools. Tools allow agents to interact with external systems (like databases or proprietary APIs) beyond built-in capabilities. Custom tools are defined as standard Python/TypeScript functions decorated with `@tool` and require detailed docstrings, which guide the Large Language Model (LLM) on how and when to use them.

Key takeaways

  1. Purpose of Tools

    Tools give agents capability by allowing interaction with the outside world, such as looking up data in databases or taking actions via external APIs. Built-in tools (e.g., web search) are provided by the underlying model, while custom tools address specific organizational needs.

  2. Defining Custom Tools

    In Python, a custom tool is defined as a function decorated with `@tool` from `LangChain tools`. The function's name becomes the tool name, its parameters are what the LLM must fill out, and the docstring serves as the primary description for the agent.

  3. Integration Process 2:00

    To use a custom tool, define it in a separate file (e.g., `tools/lookup.py`), and then import and pass the function reference into the agent definition script.

Watch on YouTube Full article

Managed Deep Agents - Skills thumbnail

· 8:29

Managed Deep Agents - Skills

Skills allow managed deep agents to access specialized contexts and executable scripts dynamically, moving beyond static instructions. Skills are defined in a structured folder (`skills`) using `skill.md` files, which utilize 'progressive disclosure'—only basic information is given to the LLM initially. This system enables agents to perform complex tasks, such as asking follow-up questions or running Python scripts, and allows for centralized management of these skills via Context Hub without requiring code redeployment.

Key takeaways

  1. Skills vs. Instructions

    While instructions are always visible in the agent context, skills provide specialized, optional contexts that the agent can read or execute only when needed (progressive disclosure).

  2. Skill Definition Structure 2:05

    Each skill resides in a dedicated folder under `skills/` and requires a `skill.md` file. This file must contain front matter fields: `name` (the skill name) and `description` (what is shown to the LLM).

  3. Executing Scripts 5:40

    Skills can contain executable scripts (e.g., Python files like `hello.py`). The agent can identify, read, execute these scripts, and use their output as part of its response.

Watch on YouTube Full article

Managed Deep Agents - Instructions and Context Hub thumbnail

· 5:40

Managed Deep Agents - Instructions and Context Hub

This video details how 'Instructions' define the behavior of Managed Deep Agents. These instructions are stored in a dedicated Context Hub, allowing developers to modify agent behavior directly through the UI without needing to redeploy code. The process involves syncing local changes (e.g., modifying `instructions.md`) with the production Context Hub via commands like `mda deploy`, and understanding how conflicts between local and deployed instructions can be resolved.

Key takeaways

  1. Instructions Define Agent Behavior

    Instructions are the core component defining an agent's behavior, typically placed within the system prompt. Changing these instructions immediately impacts the agent's output (e.g., changing response language from Italian to Spanish).

  2. Context Hub for Non-Code Changes 2:05

    The Context Hub allows agents to be updated by modifying instructions in a UI, which automatically propagates changes to the deployed agent without requiring code redeployment.

  3. Syncing Local and Production Instructions 3:50

    When running `MDA deploy`, if the Context Hub has been manually edited (e.g., in production), the deployment process pauses, allowing the user to choose whether to override the hub-edited instructions with the local version or vice versa.

Watch on YouTube Full article

Managed Deep Agents - Quickstart thumbnail

· 8:11

Managed Deep Agents - Quickstart

This quickstart guides users through scaffolding, configuring, testing, and deploying a Managed Deep Agent (MDA). The process involves using the MDA CLI to initialize a project structure, setting up API keys for model providers (e.g., OpenAI), defining agent instructions (`instructions.mmd`), and integrating tools like web search. Testing is done locally via `MDA dev` in LangSmith Studio before deploying the final version to the production environment.

Key takeaways

  1. Project Scaffolding 0:25

    Use `uv tool install managed deep agents` followed by `MDA innit <project-name>` to scaffold the agent project. This creates necessary files like `agent.py`, `instructions.mmd`, and populates environment variables.

  2. Agent Configuration 2:05

    The agent's behavior is defined in `instructions.mmd`. Model selection (OpenAI, Google, Anthropic) and tool definitions (e.g., web search) are configured within the project files.

  3. Local Development Cycle 3:20

    To test locally, run `uv sync` to install dependencies, followed by `MDA dev`. This spins up a local LangSmith Studio environment for iteration and testing.

  4. Production Deployment 4:40

    Deployment requires a paid Langsmith account. The process syncs context to the Context Hub—a centralized location for instructions and skills that can be edited via UI without redeployment.

Watch on YouTube Full article

Trading Desks to Clinical Trials: Parallels in Applied Vertical AI — Ayush Bhardwaj, Allos AI thumbnail

· 20:02

Trading Desks to Clinical Trials: Parallels in Applied Vertical AI — Ayush Bhardwaj, Allos AI

The talk outlines a structured methodology for building and iterating in applied vertical AI, arguing that model infrastructure and APIs are commodities. The true 'moat' lies not in the technology itself, but in proprietary data and deep domain expertise. The process requires narrowing the problem scope, curating unique datasets (like failed experiments or trade theses), and crucially, integrating a human domain expert ('the user') to create an endless learning loop that guides prompt refinement and error analysis.

Key takeaways

  1. The Moat is Domain Expertise 12:30

    In vertical AI, the competitive advantage does not come from the model (e.g., Claude or ChatGPT) or the infrastructure; it comes from proprietary data and domain expertise which must be curated by human experts.

  2. Focus on Narrow Tasks 6:35

    When formulating a problem for an AI agent, do not try to solve everything at once. Break down complex tasks into very narrow, specific steps (e.g., ranking stocks based on IT capital expenditure in US equities).

  3. The Importance of Proprietary Data 8:00

    Generic data sources are insufficient. The most valuable assets are proprietary datasets that are expensive to acquire or withheld by industry players (e.g., failed clinical trials, internal trade theses).

  4. Hire the User, Not Just the Model 15:30

    The single most critical step is hiring a domain expert ('the user'). This person guides the tool by curating sources, refining prompts, and performing judgment—a process that transforms generic AI tools into industry-specific assets.

Watch on YouTube Full article

Healthcare’s Agent Bytecode: X12 as the Harness for AI Agents — Vasant Kearney, Onlay thumbnail

· 20:25

Healthcare’s Agent Bytecode: X12 as the Harness for AI Agents — Vasant Kearney, Onlay

The presentation argues that reliable AI agents in healthcare claims processing must treat X12 not merely as a file format, but as an underlying structural 'harness' or contract. This approach is necessary because various payer systems (phone portals, web interfaces, and X12 feeds) are often built by disparate teams and can contradict each other, meaning no single surface represents the ground truth. By grounding agentic execution in the structured rules of X12—which governs every stage from eligibility (270) to payment (835)—developers can build systems that maintain data integrity until downstream evidence proves otherwise.

Key takeaways

  1. Goal: Cost and Patient Experience 1:46

    The primary objective when solving healthcare problems is twofold: driving overall cost reduction and improving the patient experience. Technical solutions must be grounded in these concepts.

  2. X12 as a Structural Harness 8:16

    Instead of viewing X12 only as a data format, it should be treated as a contract that defines the relationship between providers and payers. This structure guides agentic execution across all claim lifecycle steps (e.g., eligibility check 270 to payment 835).

  3. Enterprise Memory Constraints

    For reliable, large-scale systems in healthcare, memory must be stored in a database rather than on local disk, ensuring logical separation and preventing data loss or contamination.

  4. Skepticism of LLMs

    While AI models are powerful, developers must remain 'AI pilled' yet highly skeptical. Over-reliance on overpowered or expensive models can negate cost savings goals; testing and validation must be rigorous to prevent system failure when introducing new models.

Watch on YouTube Full article

Shipping AI to a Million Patients Without an A/B Test — Jared Joselowitz, Ufonia thumbnail

· 19:15

Shipping AI to a Million Patients Without an A/B Test — Jared Joselowitz, Ufonia

The talk details how Ufonia built a comprehensive safety and evaluation stack for Dora, a conversational AI used in clinical post-op follow-ups. Because randomized A/B testing is unethical and illegal when dealing with patients, the system cannot rely on reactive rollbacks or standard model benchmarks. Instead, the approach shifts to rigorous simulation (the 'inner loop') using frameworks like Matrix, which employs simulated patients (PatBot) and an expert LLM judge (BevJudge). Safety is proven by optimizing prompts against a cost matrix (e.g., prioritizing sensitivity over overall accuracy) and utilizing automated prompt optimizers like Jeppa, ensuring the system ships evidence, not just a model.

Key takeaways

  1. Safety Constraints in Healthcare AI 3:50

    Standard software safety nets (A/B testing, rollbacks) fail when dealing with patients because randomizing into a worse variant is unethical and illegal; once a call is made, it cannot be undone. The model card's benchmark scores are insufficient defense at post-incident reviews.

  2. The Necessity of Simulation 10:50

    Since real-world testing (the 'outer loop') is too risky, the process must emulate high-reliability industries like self-driving cars. The simulation framework, Matrix, uses an LLM (PatBot) to play the patient against hazards written by clinicians.

  3. Automated Hazard Detection 13:50

    A second LLM, BevJudge, validates simulated dialogues. It is trained and validated against a corpus of 240 examples labeled by 10 clinicians from 10 specialties, achieving expert-level performance (e.g., F1 score of 0.96) with near-perfect sensitivity.

  4. Optimizing Prompts via Cost Matrix 17:00

    Instead of manual prompt engineering, the process uses optimizers like Jeppa (Genetic Pareto), which iteratively updates prompts based on a defined cost matrix. This allows optimization for specific metrics, such as maximizing sensitivity (catching red flags) over general accuracy.

Watch on YouTube Full article

Guardrails First: Engineering Member-Facing Health AI — Rashi Agrawal, Hinge Health thumbnail

· 21:49

Guardrails First: Engineering Member-Facing Health AI — Rashi Agrawal, Hinge Health

The talk outlines critical architectural guardrails necessary for deploying member-facing healthcare AI. The core argument is that most safety failures are not model flaws but architectural decisions made before any tokens are generated. Safety must be built into three non-negotiable foundations: protecting PHI at the pipeline boundary, ensuring deterministic code layers handle high-stakes decisions (like emergency routing), and implementing continuous monitoring using multiple signal sources.

Key takeaways

  1. Architectural Failures vs. Model Failures

    Most AI safety failures in healthcare are architectural decisions, not model failures. The system must be designed to prevent failure at the structural level before considering prompt engineering.

  2. Three Non-Negotiable Foundations 3:55

    1) Constraint is the architecture (not just policy). 2) Deterministic rules must belong above the model layer, as anything that can never be wrong cannot be left to probability. 3) Safety must be a continuous evaluation layer, not a one-time gate.

  3. PHI Protection at Ingestion 8:47

    Instead of treating PHI redaction as a runtime problem (on the dashboard), the architecture must strip PHI at the pipeline boundary during ingestion, ensuring it is never stored in the data lake.

  4. Deterministic Code Layer for High Stakes 13:35

    Irreversible decisions (e.g., emergency escalation to 911/988, intent routing) must be handled by a deterministic code layer that runs *before* the LLM processes the turn. The model should not get a vote on high-stakes calls.

  5. Decision Framework: Worst Case Wins

    When stakeholders disagree on a feature launch, severity must be set by the worst plausible outcome (the maximum potential harm), not the average case or current capacity. When unsure, default to the safer mistake.

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

The MCP Tasks Extension thumbnail

· 21:31

The MCP Tasks Extension

The session details the evolution of the MCP Tasks Extension protocol, designed for orchestrating complex, asynchronous workflows that cannot be completed in a single synchronous request. The speaker compares the older 1.120 specification with the modern 1.720 spec, highlighting major architectural improvements including statelessness, enhanced security, and simplified communication paths to better support multi-agent systems and durable execution.

Key takeaways

  1. Asynchronous Workflow Handling 2:00

    The Task Protocol allows for long-running operations (e.g., batch migrations, model training) by introducing a non-blocking task ID and polling mechanism, moving beyond the limitations of synchronous client-server calls.

  2. Protocol Simplification and Security 5:45

    The new 1.720 specification significantly reduces complexity by consolidating capability checks (from three layers to one) and eliminating the insecure `task/list` method, which previously risked exposing all running tasks on the server.

  3. Improved Interaction Model 7:30

    The new protocol replaces the blocking `tasks/result` call for user input with a non-blocking flow. If the server requires input, it changes the status to 'input required,' and the client uses the dedicated `tasks/update` method to send the response.

  4. Statelessness and Reliability 8:40

    The updated approach is more amenable to stateless architectures, which aligns with modern best practices for scalable service design. The result of a completed task now comes directly in the `tasks/get` response.

Watch on YouTube Full article

MCPs for Observability Stacks thumbnail

· 24:28

MCPs for Observability Stacks

This session details how MCP servers enhance traditional observability stacks by integrating AI capabilities for proactive system management. By correlating metrics, logs, traces, and events, MCPs allow engineers to move beyond reactive monitoring. Key features include automated anomaly detection (using techniques like setting business boundaries), natural language querying, and the use of 'skills'—reusable playbooks that guide AI agents through complex tasks such as root cause analysis, metric cleanup, and model selection for time series forecasting.

Key takeaways

  1. Shift to Proactive Observability 1:45

    The goal of modern observability is to move from reactive incident response to proactive anomaly detection, aiming to reduce Mean Time To Resolution (MTTR) by correlating telemetry across the entire stack.

  2. MCP's Role in Analysis 3:25

    MCP servers enable AI agents to query and correlate data, automating root cause analysis. This capability replaces manual dashboard navigation and complex query writing using natural language prompts.

  3. Advanced Anomaly Detection 5:18

    Anomaly detection identifies unusual patterns (spikes or drops) that deviate from expected behavior. Accurate detection requires defining 'business boundaries' to provide necessary context for the model.

  4. Automated Workflow and Model Selection 17:08

    MCPs can use specialized 'skills' (reusable playbooks) to perform complex tasks. For instance, an AI assistant can analyze a query's time series characteristics and recommend switching between forecasting models (e.g., from Prophet to IMADS online).

Watch on YouTube Full article