Topic

State Management

All digests tagged State Management

Every step you take, every call you make: the reliable agent stack — Giselle van Dongen, Restate thumbnail

· 20:50

Every step you take, every call you make: the reliable agent stack — Giselle van Dongen, Restate

This talk introduces Restate, an open-source framework designed to provide a flexible, durable foundation for building resilient, long-running, and stateful agentic systems. Restate addresses the infrastructure gap in agent development by handling complex concerns like retry logic, recovery, session isolation, and process cancellation. It operates as a server proxying requests to the agent service, using an event journal to ensure that processes can survive crashes, redeploys, and long periods of suspension (e.g., waiting for human approval) without losing state or consuming serverless execution time.

Key takeaways

  1. Durable Execution and Resilience 5:40

    Restate enables durable execution, allowing an agent process that runs for extended periods (e.g., a week) to crash and restart exactly at the point of failure, rather than starting over. This is achieved by recording all events in a journal.

  2. Modeling State with Virtual Objects 14:00

    Instead of modeling agents as simple workflows, Restate uses 'virtual objects' to model persistent, stateful entities (like a session). These objects have unique IDs and isolated state, allowing multiple agents to interact with a single run without interfering with each other's state.

  3. Advanced Control and Interaction 16:40

    The framework supports advanced control primitives, allowing external processes to signal, inject state into, or completely cancel an already running agent loop. This capability is crucial for complex, multi-agent interactions.

  4. Low Latency via Push Model 19:20

    Unlike traditional workflow orchestrators that poll for new tasks (pull model), Restate uses an event-driven, push model for invocations. This design significantly lowers latency, achieving low latencies (e.g., 45ms p99) even for multi-step workflows.

Watch on YouTube Full article

MCP Apps: Give the Model Data, Give the User a UI — Dustin Mihalik, Indeed thumbnail

· 15:34

MCP Apps: Give the Model Data, Give the User a UI — Dustin Mihalik, Indeed

This talk details the architectural challenges of building Model-Composable Platform (MCP) applications for large language models (LLMs) like Claude and ChatGPT. The core thesis is that for a UI widget to function effectively, it must be treated as a data layer, not just a visual display. The speaker outlines three critical rules for developers: all displayed information must be provided as data to the model; the tool description must explicitly state that a UI exists; and, most importantly, data processing must be strictly separated from UI rendering to maintain model context and reasoning capability.

Key takeaways

  1. Data-First Design Principle

    When building MCP apps, developers must focus on defining the data the model needs to process before considering the UI. The UI should be viewed as a side effect or result of the model exploring the underlying data.

  2. Rule 1: Show the Model Everything 5:13

    Any information displayed to the user via the UI must also be provided as structured data to the model. Failing to do so creates a 'black box' that prevents the model from answering follow-up questions about the displayed content.

  3. Rule 2: Declare the UI in the Description 8:26

    The tool description must explicitly state that a UI exists. Otherwise, the model will attempt to narrate the results underneath the widget, leading to redundant and confusing output.

  4. Rule 3: Separate Data Processing from UI Rendering 13:39

    This rule supersedes the others. The architecture must split the job into two distinct tools: one for pure data retrieval (e.g., `search_jobs`) and a separate, dedicated tool for rendering the results (e.g., `render_jobs`). This allows the model to perform complex data exploration without being limited by the UI's single call.

Watch on YouTube Full article

Agents & Arbiters - An Adventurer’s Guide to Multi-Agent Collaboration with LangGraph.js - Guy Royse thumbnail

· 59:56

Agents & Arbiters - An Adventurer’s Guide to Multi-Agent Collaboration with LangGraph.js - Guy Royse

The talk introduces multi-agent collaboration using LangGraph.js as an advanced pattern for building complex, interactive systems that move beyond fragile, scripted logic. Instead of anticipating every user action with nested `if` statements, the system uses autonomous agents (LLMs) to contribute perspectives and make decisions. The architecture is built around a graph structure that orchestrates specialized nodes—including routers, experts, arbiters, and committers—to manage state changes and generate coherent responses.

Key takeaways

  1. Agent Definition 24:28

    An agent is defined as an LLM with a system prompt defining its purpose, coupled with a collection of tools that allow it to interact with the world. These agents are composable within a graph structure.

  2. Graph Workflow Components 34:05

    The system uses an orchestration workflow (router, classifier, agents, arbiter, committer) to manage complex interactions. The router determines which specialized nodes are relevant for a given input, and the arbiter reconciles conflicting suggestions from multiple agents.

  3. Conditional Edges 38:38

    Conditional edges allow the graph's flow to be determined by an LLM's reasoning over the current state, enabling patterns like the Supervisor pattern and the ReAct (Reasoning and Acting) cycle. This is crucial for dynamic decision-making.

  4. State Persistence and Memory 48:50

    To solve context loss, the architecture utilizes a dedicated Agent Memory Server (a library/Docker image) that automatically compacts message history and extracts long-term facts asynchronously, providing continuous memory across sessions.

Watch on YouTube Full article

Agents Are Where Microservices Were in 2015 — Roberto Milev & Uday Kanagala, Navan thumbnail

· 19:28

Agents Are Where Microservices Were in 2015 — Roberto Milev & Uday Kanagala, Navan

The talk outlines that AI agents represent a paradigm shift comparable to microservices in 2015, requiring entirely new architectural patterns for reliable production deployment. Key areas of focus include managing agent statefulness (moving beyond stateless APIs), implementing advanced observability via hooks and traces, adopting skills as the primary unit of context, and establishing robust governance through guardrails at the policy layer. The industry is moving toward scoring non-deterministic trajectories rather than asserting fixed outputs.

Key takeaways

  1. Agents are Stateful by Nature 3:54

    Unlike traditional stateless API services, agents require persistent sessions and state management, necessitating specialized agentic runtimes (e.g., AWS Agent Core Runtime) [2:34].

  2. Skills as Context Unit 6:04

    To manage context effectively, the focus should be on treating 'skills'—which include instructions and tool execution logic—as pluggable units of work that allow for progressive disclosure of context [6:04].

  3. Observability via Hooks and Traces 7:16

    Because agents emit excessive thinking output, traditional logging fails. Operational reliability requires intercepting every step (pre-tool/post-tool, pre-decision/post-decision) to capture auto-traces, goals, reasoning, belief status, and confidence scores [7:16].

  4. Testing Non-Deterministic Systems 9:32

    Since agents are non-deterministic, testing must shift from asserting fixed outputs to scoring trajectories—evaluating the efficiency and completeness of the path taken toward a goal [9:32].

  5. Guardrails for Authorization 13:44

    The blurring line between an agent acting on behalf of a user versus using its own service account requires fine-grained authorization policies (guardrails) applied before and after every tool call to prevent sensitive data leakage [13:04].

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

Exo: Harnesses should see their own code and logs — Alex Krentsel thumbnail

· 47:11

Exo: Harnesses should see their own code and logs — Alex Krentsel

Exo is presented as a novel agent harness designed for fully recursive self-improvement (RSI). Unlike previous agents that only allow modification in specific areas (like memory or skills), Exo's architecture enables the agent to safely and incrementally modify all aspects of itself—including its own code, context construction policy, and tools—at runtime. This is achieved by decomposing the agent into three isolated layers: the Executor (policy/decision-making), the Exo Harness (state management/secrets), and the Sandbox (isolated execution environment). The system's ability to operate in this same medium as its output code is argued to be the key differentiator enabling true RSI.

Key takeaways

  1. Shift from Model Weights to Agent Harnesses 3:50

    The industry focus is shifting from improving LLM model weights (the 'brain') to optimizing the agent harness and tooling ('the body'). The harness provides critical structure, allowing for improvements in efficiency, cost reduction, and task performance.

  2. Full Recursive Self-Improvement (RSI) 2:33

    Exo is designed to be fully recursive, meaning it can operate on any aspect of itself—from prompts or memory to the basic harness policy. This capability allows the system to improve its own architecture and logic without external human intervention.

  3. Architectural Separation for Safety 10:38

    The agent is decomposed into three distinct layers: the Executor (stateless policy), the Exo Harness (state/secrets), and the Sandbox (isolated execution). This separation ensures that self-modification can occur safely, preventing data leaks or loss of history.

  4. Cost Optimization via Self-Improvement 30:40

    Exo demonstrated the ability to autonomously rearchitect its own Discord adapter at runtime, scoping down context assembly from across multiple threads. This resulted in a verified 96% decrease in API call costs.

Watch on YouTube Full article

Memory Harnesses for Long-Running Research Agents — Stefania Druga, Sakana.ai thumbnail

· 13:04

Memory Harnesses for Long-Running Research Agents — Stefania Druga, Sakana.ai

The presentation details the design and efficacy of 'memory harnesses' for managing state in long-running research agents. The core finding is that while memory harnesses offer no benefit when task context fits within the model's window (adding only cost), they are critical for solving long-horizon tasks where relevant information sits far outside the current context. The speaker emphasizes treating memory as a write-manage-read control loop, not merely an attached database.

Key takeaways

  1. Memory is a Control Loop, Not a Database 5:44

    The memory harness must be viewed as a 'write-manage-read' control loop wrapped around the model, rather than simply a retrieval database. This architectural focus allows for precise state management.

  2. Local Models Enable Sovereignty and Cost Control 2:36

    Running evaluations on local hardware (e.g., M3 Ultra) enables better control over the entire pipeline, which is crucial for maintaining 'sovereign AI' capabilities and reducing operational costs.

  3. Ranked Recall Outperforms Other Policies 7:16

    Across the X-Bench benchmark (over 68 questions), the 'ranked recall' policy consistently achieved the best performance, outperforming even approaches that simply gate memory usage or use an ideal 'oracle' ground truth.

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

From LLM Theory to Practical Agentic Implementations - Seth Juarez thumbnail

· 59:49

From LLM Theory to Practical Agentic Implementations - Seth Juarez

The talk demystifies Large Language Models (LLMs), arguing that their power does not come from inherent intelligence but from engineered 'harnesses' and fundamental primitives. The speaker outlines a progression of techniques—from simple completions to complex agentic loops—that allow developers to build robust, reliable AI systems by controlling the model's input context, output structure, and execution flow. Key concepts include using structured JSON for control flow, implementing tool calling via runtimes (not the LLM itself), establishing guardrails, and orchestrating multi-step workflows through shared 'threads.'

Key takeaways

  1. LLMs are Next Token Predictors 1:42

    At its core, an LLM is a giant mathematical function that predicts the next token based on input tokens. The perceived intelligence comes from the surrounding runtime logic (the harness), not the model itself.

  2. The Agentic Loop is the Core Primitive 21:20

    True agency is achieved by implementing an 'agentic loop'—a while loop in the runtime that continuously checks for and executes tool calls, feeding the results back into the context until no more tools are needed. This is the fundamental unit of agency.

  3. Guardrails and Bindings Enhance Reliability 35:05

    To prevent misuse or incorrect execution (e.g., unauthorized memory access), developers must implement guardrail functions in their runtime logic. Furthermore, 'bindings' allow injecting fixed parameters (like `user ID`) into function calls, removing the burden of context-dependent reasoning from the LLM.

  4. Composition Workflow for Multi-Step Agents 50:50

    Complex tasks are solved by chaining multiple specialized agents or prompts (e.g., Research $ ightarrow$ Draft $ ightarrow$ Review). All these components share a single, persistent 'thread' context to maintain state and pass control flow sequentially.

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

The Agent Development Lifecycle 101 by Harrison Chase thumbnail

· 45:17

The Agent Development Lifecycle 101 by Harrison Chase

The Agent Development Lifecycle outlines a systematic approach for moving AI agents from isolated demos to reliable production systems. The process is broken down into five stages: Build, Test, Deploy, Monitor, and Govern. Key focus areas include ensuring agent reliability at scale by implementing durable execution, managing complex state via virtual file systems, and using advanced observability tools like tracing and online evaluation (evals) to detect failures and drive continuous improvement.

Key takeaways

  1. Systematic Iteration is Key 3:50

    Successful teams treat agents not as one-off projects but as systems requiring systematic iteration across the entire lifecycle: build, test, deploy, monitor, and improve. The primary challenge in shipping agents reliably at scale is ensuring consistent behavior.

  2. Agent Development Components 5:50

    The core components are Build (frameworks/harnesses), Test (data sets, metrics, benchmarks like Terminal Bench 2), Deploy (durable execution, sandboxes), Monitor (tracing, online evals), and Govern (cost control, tool access management).

  3. The Role of Tracing and Observability 17:06

    Tracing is fundamental for debugging agents, allowing developers to see the inputs and outputs at every step (including tool calls) to understand why an LLM or agent failed. Online evals extend this by scoring production traces without needing ground truth.

  4. Self-Improving Agents 31:30

    Advanced platforms, like LangSmith Engine, are beginning to automate the improvement loop. They run in the background over existing traces, clustering issues and suggesting fixes (code or prompt changes), thereby drastically lowering the burden of operating agents at scale.

Watch on YouTube Full article

60% Faster Time-to-Interview: Transforming Hiring with AI Agents with LangChain thumbnail

· 18:05

60% Faster Time-to-Interview: Transforming Hiring with AI Agents with LangChain

LinkedIn details the architecture of a hiring agent built with LangChain and LangGraph that successfully cut time-to-interview by 60% for small businesses. The system evolved from static workflows to an advanced agentic control model utilizing a central planner within a plan-execute-replan loop. Key architectural components include specialized memory types (conversational and experiential), middleware hooks for PII detection, and rigorous 'harness engineering' techniques—such as state flag chaining and one-shot tool guards—to ensure the probabilistic nature of LLMs results in a dependable product.

Key takeaways

  1. Hiring is an Agent Problem

    The hiring process is inherently iterative (plan, act, observe, adapt), requiring continuous adaptation rather than being a one-shot task. This necessitates an agentic approach.

  2. Architectural Evolution to LangGraph 0:03

    The system progressed from hard-coded static workflows (if/then) to sequential LangChain chains, culminating in LangGraph for its true agentic control model featuring a central planner and plan-execute-replan loop.

  3. Choosing LangGraph 0:05

    LinkedIn selected LangGraph over 89 evaluated frameworks because it complements existing infrastructure, builds upon core LangChain primitives (runnables, tools), and allowed for zero rewrite adoption.

  4. Achieving Determinism via Harness Engineering 0:10

    To make the agent dependable, LinkedIn implemented advanced 'harness engineering' techniques, including context management (checkpoint trimming), output format determinism (template confirmation/fallbacks), and node-change determinism (state flag chaining and one-shot tool guards).

Watch on YouTube Full article