Topic

LLM Orchestration

All digests tagged LLM Orchestration

Schedules for Managed Deep Agents: Cron jobs, prompts, and Slack delivery thumbnail

· 3:26

Schedules for Managed Deep Agents: Cron jobs, prompts, and Slack delivery

This video demonstrates how to implement automated, recurring tasks using Schedules for Managed Deep Agents. By configuring cron jobs, agents can run autonomously to generate and deliver structured reports (e.g., a weekly Salesforce pipeline summary) to external channels like Slack, without manual intervention. The process involves defining the schedule syntax, deploying the agent to LangSmith, and ensuring the agent has access to necessary tools and context.

Key takeaways

  1. Automated Reporting via Cron Jobs

    Schedules allow agents to send recurring messages that invoke tools or leverage context, such as generating a weekly pipeline summary for the sales team.

  2. Schedule Configuration 0:01

    Schedules are defined by creating a file in the schedules directory, specifying a cron job, a time zone, a prompt, and optional input context.

  3. Deployment and Monitoring 0:01

    The scheduled agent must be deployed to LangSmith using a deploy command, allowing users to inspect the configured cron jobs and prompts within the LangSmith UI.

Watch on YouTube Full article

Ship a GitHub PR From a Slack Message with Managed Deep Agents thumbnail

· 3:27

Ship a GitHub PR From a Slack Message with Managed Deep Agents

This walkthrough introduces Patch, an agent built using LangChain's Managed Deep Agents (MDAs). Patch automates the process of converting natural language feature requests from a Slack message into a fully drafted GitHub Pull Request (PR), complete with descriptions and code changes. The agent successfully demonstrated implementing features (e.g., adding a share button, changing the background color) for a Tetris side project, proving that complex integrations—including Slack communication, GitHub interaction, and code sandboxing—can be achieved with minimal code.

Key takeaways

  1. Slack-to-GitHub PR Automation

    Patch allows development discussions held in Slack to immediately trigger the creation of a GitHub PR, eliminating the need for manual PR drafting and code sharing via screenshots.

  2. Multi-System Integration Simplicity 2:09

    Managed Deep Agents simplify connecting disparate systems (Slack, GitHub, Sandbox) into a single agent workflow using only a few lines of code.

  3. Agent Configuration Components 2:31

    The agent's functionality is defined by modular files: `agent.py` (defines the agent name and model, e.g., Claude Sonnet 5), `instructions.md` (specifies goals and procedures), and dedicated connectors for Slack, GitHub, and the sandbox.

Watch on YouTube Full article

5 Voice Agent Failure Modes You'll Hit in Week One — Venky B, Plivo thumbnail

· 26:46

5 Voice Agent Failure Modes You'll Hit in Week One — Venky B, Plivo

This talk details five critical failure modes encountered when deploying voice AI agents from a proof-of-concept (PoC) environment to production scale. The core message emphasizes that successful production deployment requires shifting focus from end-to-end transcript processing to structured data collection, rigorous latency management, and building robust normalization layers between the LLM and Text-to-Speech (TTS) components. Key technical recommendations include using smaller, self-hosted open-source models for low latency, treating data collection as unit-testable field validation, and normalizing all output before synthesis.

Key takeaways

  1. Latency and Time to First Audio (TTFA) 9:54

    Industry average TTFA often falls between 750ms and 1,200ms, leading to user drop-off. To improve this, the speaker recommends using smaller, self-hosted open-source models (e.g., Quen 3.5, Gemma 4) to target under 300ms, balancing cost, intelligence, and latency.

  2. Data Collection Must Be Structured 19:20

    Instead of treating input as a single transcript, data collection should be modeled like structured fields (e.g., using Pydantic or Zod). This approach significantly increases accuracy (from ~30% to mid-90s) by allowing validation and error handling per field (e.g., phone numbers, addresses).

  3. Normalization Layer is Critical 24:30

    Never feed raw LLM output directly to a TTS engine. A dedicated normalization layer must be implemented to strip markdown/emojis, apply custom pronunciation dictionaries, and control speaking speed (e.g., 0.7x or 0.8x) to ensure proper pronunciation of entities.

  4. Transcription is Brittle by Default 20:40

    Transcription engines struggle with proper nouns, jargon, and code-switched languages. Solutions include implementing dynamic keyword boosting and post-processing the raw transcript using an LLM layer, which provides necessary domain context.

Watch on YouTube Full article

Agents Without Code: Skills, YAML, and Filesystems Replaced Python — Philipp Schmid, Google DeepMind thumbnail

· 18:28

Agents Without Code: Skills, YAML, and Filesystems Replaced Python — Philipp Schmid, Google DeepMind

The presentation details the evolution of LLM agents, demonstrating a shift from complex, brittle Python code loops to declarative, file-based definitions using system instructions and skills. The speaker shows that modern agent architectures, such as the Gemini API's anti-gravity agent, utilize a hosted sandbox and network proxy to manage state and credentials securely. This allows agents to operate using general-purpose tools (like GitHub CLI or Google Search) defined in files (e.g., `AGENTS.md`), drastically reducing the need for thousands of lines of custom orchestration code.

Key takeaways

  1. The Agent Evolution: Code to Files

    Agent development is moving away from writing explicit Python loops, JSON schemas, and tool routing logic. The core functionality is now expressed in files (Markdown/Skills) that define instructions, rules, and capabilities, allowing the model to use general tools.

  2. Server-Side State Management 14:02

    The new architecture handles complex tasks by moving loops, tool routing, session state, and context compaction to the server side, requiring only a single API call with new inputs.

  3. Security and Isolation 12:32

    A hosted sandbox and network proxy ensure that the agent never sees the actual credentials, injecting tokens only when outbound requests are made, and allowing domain restriction for enhanced security.

  4. Focus on Domain Logic 16:40

    The primary work for developers is now defining the domain instructions, rules, and evaluation criteria (the 'what'), rather than writing the infrastructure code (the 'how').

Watch on YouTube Full article

Teaching agents to pay — Anna Spysz, Stripe thumbnail

· 19:10

Teaching agents to pay — Anna Spysz, Stripe

This talk introduces 'agent-to-commerce,' detailing how AI agents can move beyond research assistance to execute complex transactions on behalf of users. The infrastructure relies heavily on structured data protocols like the Universal Commerce Protocol (UCP) and requires merchants to publish a `merchant capabilities manifest` and JSON catalogs, rather than relying on traditional website browsing. Security is maintained through shared payment tokens, ensuring that the payment provider—not the agent or merchant—enforces transaction limits and guardrails.

Key takeaways

  1. Agent Discovery vs. Human Browsing 5:13

    Agents do not browse websites; they read structured data (JSON) from a `merchant capabilities manifest` to understand supported payment methods, endpoints, and product catalogs. This makes merchants 'agent-ready.'

  2. The Role of UCP in Transactions 5:40

    The Universal Commerce Protocol (UCP) acts as a shared language defining how agents initiate, update, complete, and cancel purchases across multiple merchants and agents.

  3. Security via Shared Payment Tokens 13:46

    During checkout, the agent receives and passes a 'shared payment token' (representing a raw card number or wallet). The seller only unwraps what is necessary, and the payment provider enforces all limits, mitigating risk.

Watch on YouTube Full article

Preferences Over Benchmarks: Model Routing — Archana Kamath & Tyler Gillam, DigitalOcean thumbnail

· 15:54

Preferences Over Benchmarks: Model Routing — Archana Kamath & Tyler Gillam, DigitalOcean

The talk argues that relying on public benchmarks to select a single best LLM is flawed; model selection must be based on specific operational preferences. The solution presented is an Inference Router—a purpose-built Mixture of Experts (MoE) model that dynamically selects the optimal LLM for each request based on declared constraints, including task type, cost tolerance, required latency, and system prompts. This approach significantly reduces inference costs and improves performance stability compared to using a single premium model across all tasks.

Key takeaways

  1. Model selection must be preference-driven, not benchmark-driven 4:02

    The 'right' model depends on the specific request context (task, cost, latency) and cannot be determined by a single public leaderboard. For instance, classification may use a small open model for cost efficiency, while code review requires a frontier model for accuracy.

  2. Model orchestration is the new phase of cloud optimization

    Due to exploding inference costs and single-model risk, advanced model orchestration (like routing) is becoming a critical discipline for production applications.

  3. The router optimizes cost and speed per task

    In live demos, the router successfully matched tasks (e.g., code generation, test writing) to specialized models (e.g., GLM 5.2, Claude 3 Sonnet), resulting in significantly lower total session costs (e.g., 8 cents vs. 25 cents) while maintaining comparable quality.

  4. The router is customizable and open-source 5:20

    The solution runs on an open proxy plan and a purpose-built routing model (both open source), allowing users to define custom decision tree rules, set failover policies, and evaluate performance using internal metrics rather than external leaderboards.

Watch on YouTube Full article

Building Agents Is Trivial Now, Context Is the Next Frontier — Jeff Ng, Unblocked thumbnail

· 13:22

Building Agents Is Trivial Now, Context Is the Next Frontier — Jeff Ng, Unblocked

While cloud primitives and frameworks have made defining AI agents trivial—reducing complexity from requiring dedicated systems for checkpointing, sandboxing, and observability—the primary failure point remains missing organizational context. The speaker argues that simple access layers (like Multiple Connectors/MCPs) are insufficient because 'access is not understanding.' A Context Engine solves this by connecting disparate data sources (docs, code, tickets, conversations) to provide a synthesized, task-relevant understanding that agents can act upon, preventing critical errors and outages.

Key takeaways

  1. Agent Development Complexity Has Decreased

    Six months ago, building an agent required significant effort to solve infrastructure problems like state persistence (checkpointing), isolated sandboxes, and observability. Modern cloud primitives (e.g., Cloudflare, Vercel) have absorbed this 'plumbing,' simplifying agent definition to selecting a model, instructions, tools, and sandbox location.

  2. The Context Gap is the New Bottleneck 7:01

    Agents struggle with institutional knowledge—the decisions, failures, and postmortems stored across different systems (Slack threads, documentation). An agent lacking this full picture can make confidently wrong recommendations, potentially causing outages.

  3. Context Engines Provide Synthesized Understanding

    A Context Engine goes beyond simple data access by building a model of the organization. It reconciles conflicting results across multiple datasets (docs, code, tickets, conversations) and delivers a synthesized understanding that an agent can act on, rather than just raw documents.

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 - 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

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

Evolution of agentic surfaces — Gagan Bhat & Isabella Kai He, Anthropic thumbnail

· 31:24

Evolution of agentic surfaces — Gagan Bhat & Isabella Kai He, Anthropic

The evolution of agentic surfaces (from the Messages API to Claude Managed Agents) addresses the challenge that static harnesses become limiting factors as underlying LLMs improve. The core architectural shift is decoupling the agent's 'brain' (the reasoning loop) from its 'hands' (the tool execution environment/sandbox). This separation significantly improves reliability, allows for parallel setup, and boosts performance by achieving up to 60% faster time-to-first-token at P50. Managed Agents provide production-grade infrastructure—including session logging, credential vaults, and self-hosted sandboxes—enabling developers to focus on defining the agent's task and context rather than managing complex operational overhead.

Key takeaways

  1. Harnesses Encode Stale Assumptions 11:42

    As models improve (e.g., Opus 4.5 eliminating 'context anxiety'), fixes built into older harnesses become pure overhead, adding latency or discarding cache incorrectly. Managed Agents are designed to be agile and adapt to model evolution.

  2. Decoupling Brain from Hands 20:00

    Separating the agent loop (brain) from the tool execution environment (hands/sandbox) improves reliability, allowing the brain to resume from a durable session log even if the hands fail. It also allows model reasoning to start immediately while container setup runs in parallel.

  3. Self-Improving Agents via Dreaming 27:30

    The system utilizes durable session logs and memory state, which can be fed into a periodic batch process called 'dreaming.' This process extracts new insights to automatically update the agent's memory, making subsequent sessions smarter.

Watch on YouTube Full article

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley thumbnail

· 20:08

Anthropic's CCA Exam as a Field-Guide for Agentic Engineering — Frank Coyle, UC Berkeley

The presentation uses Anthropic's Claude Certified Architect (CCA) exam structure to guide engineers through agentic AI best practices by focusing on anti-patterns. Key principles include mastering 'agentic loops' over simple sequences, ensuring specialized subagents only have limited tools, and rigorously managing context via techniques like forking and compaction to prevent groupthink and token overflow.

Key takeaways

  1. Prioritize Looping Mechanisms 12:30

    Agentic workflows should leverage loops (e.g., `while true`) rather than simple sequences, as looping provides the necessary power for complex computation, paralleling the foundational concepts of Turing completeness.

  2. Use Stop Reasons for Control 7:40

    Instead of blindly using an agent's response, robust workflows must branch logic based on the model's `stop reason`. This is crucial because the LLM cannot execute tools; it only provides parameters that external code must run.

  3. Specialize Agents and Tools 15:30

    Avoid 'overloading' a single agent with all available tools. Specialized subagents, each equipped with one or two specific tools, are significantly more effective and maintain focus.

  4. Manage Context Isolation

    To prevent context pollution and 'groupthink,' isolate subtask outputs (e.g., using a 'context fork') so that only necessary summaries return to the main thread, preventing unbounded context growth.

Watch on YouTube Full article

Managed Deep Agents explained in 20 minutes thumbnail

· 18:17

Managed Deep Agents explained in 20 minutes

Managed Deep Agents provides an integrated framework to simplify the entire lifecycle of building, running, and deploying AI agents into production. It addresses the complexity of agent infrastructure by bundling the open-source Deep Agents harness with necessary components like durable execution, context management (via Context Hub), sandboxes, and scheduling capabilities, allowing developers to move from local business logic directly to a scalable, managed deployment on LangSmith.

Key takeaways

  1. Agent Architecture Components

    An agent requires three layers: 1) Business Logic (provided by the user, e.g., prompts/tools); 2) Harness (orchestrates context and passes data to the model); and 3) Infrastructure (runtime, sandboxes, etc.). Managed Deep Agents bundles these into a seamless package.

  2. Production Readiness 2:05

    The framework handles complex production requirements such as durable execution, fault tolerance, streaming, queueing, run cancellation, and rollbacks, which are necessary when moving agents from local development to cloud serving.

  3. Decoupled Context Management 5:05

    Context (instructions and skills) is stored in the dedicated Context Hub. This allows non-developers to edit and maintain agent context via a UI without requiring code changes or redeployments, significantly improving collaboration.

  4. Deployment Workflow 10:30

    The process involves initializing the project using `MDA innit research assistant`, defining components (e.g., tools in `tools/search.py`), and deploying via `MDA deploy`. This pushes context to Context Hub and creates a deployment on LangSmith.

Watch on YouTube Full article

Building Deep Agents and Deploying in Production thumbnail

· 15:40

Building Deep Agents and Deploying in Production

Deep Agents are defined as a sophisticated 'harness' built around foundational LLMs, providing the necessary infrastructure—beyond just the model itself—to make agents reliable and useful in production. The system integrates core primitives like memory, tools, file systems (acting as scratchpads), and middleware hooks. For deployment, critical considerations include implementing durable execution via checkpointing, managing short and long-term memory stores, establishing robust Role-Based Access Control (RBAC) for tool access, and designing for human oversight (human in the loop).

Key takeaways

  1. Deep Agents are a 'Harness' 0:27

    An agent is conceptualized as an LLM plus a harness. The harness encompasses all infrastructure—including system prompts, memory management, tools, file systems, and middleware—that makes the model reliable for a given task. (0:27)

  2. Deep Agents Architecture 6:58

    Deep Agents represent the highest level of abstraction in the LangChain stack, built on top of LangGraph, which provides the core composable nodes and edges necessary for complex agent workflows. (4:18)

  3. Production Reliability Requirements

    For production deployment, agents must handle long-running tasks using durable execution (checkpointing) to recover from failures at any step, manage short/long-term memory across sessions, and incorporate human approval loops. (9:48)

Watch on YouTube Full article

The Unreasonable Effectiveness of Separating the Task from the Model — Maxime Rivest, DSPy thumbnail

· 17:11

The Unreasonable Effectiveness of Separating the Task from the Model — Maxime Rivest, DSPy

The talk introduces DSPy, an open-source Python framework designed to bring software engineering principles—reusability, composability, and testability—to AI programs. The core philosophy is the 'unreasonable effectiveness of separating the task from the model' by defining tasks strictly through a programmatic interface called the Signature. This approach allows developers to focus on the business logic (the contract) while keeping the underlying implementation flexible for experimentation with different models, weights, and techniques.

Key takeaways

  1. The Power of the Signature

    By defining a task's inputs and outputs (the Signature) first, developers create an abstraction layer that allows them to swap out underlying implementations (models, prompts, etc.) without changing the core workflow. This provides significant agility for AI engineering.

  2. Three Pillars of Task Specification 8:00

    To fully specify an AI task, DSPy advocates using three components: 1) Instructions (what should happen), 2) Constraints/Code (what must happen, enforced by code like self-recheck or chaining), and 3) Evaluation Metrics (what good looks like).

  3. Future Direction: Automation and Learning 10:35

    DSPy is evolving toward automating implementation details. Future versions, including DSPy 4.0, aim to allow models to write code beneath a signature and enable programs to learn directly from user interactions while respecting the defined inputs/outputs.

Watch on YouTube Full article

Sandboxing, Agent Harnesses, and Agent Teamwork thumbnail

· 1:19:54

Sandboxing, Agent Harnesses, and Agent Teamwork

The discussion explores the evolution of AI agents from simple task execution to sophisticated SRE (Site Reliability Engineering) capabilities. The core argument is that true value lies not in faster triage (Mean Time To Resolve - MTTR), but in building an agent that learns and compounds operational memory across an organization's entire stack. Key architectural shifts include moving beyond rigid, deterministic tools toward non-deterministic problem solving, requiring advanced techniques like sandboxing, environment simulation, and establishing governance structures for multi-agent teams.

Key takeaways

  1. The Value Shift: Learning over Triage 20:05

    AI agents' primary value is shifting from simply reducing MTTR to building an agent that learns from every investigation. The goal is creating a compounding operational memory, allowing the system to improve its decision-making process and predict failure modes rather than just reacting to alerts.

  2. Harnesses Define Agent Capability 3:25

    The 'harness' is defined as everything between the user and the LLM—including prompts, skills, file systems, and tools. The challenge is balancing necessary guardrails (to prevent agents from doing wrong things) with enough freedom to allow for complex, non-deterministic problem solving.

  3. The Need for Cross-Environment Testing 23:55

    Because every company's infrastructure (e.g., Gojek vs. Uber) is unique, agents cannot simply be trained on general knowledge. Durable development requires simulating and testing agent performance across diverse, idiosyncratic production environments.

  4. Future State: Agent Teams and Governance 1:03:22

    The next frontier involves multi-agent systems (e.g., a Coding Agent working with an SRE Agent). These teams require defined governance structures, similar to a RACI matrix, ensuring agents know their roles and how to share context without losing isolation.

Watch on YouTube Full article

Peter Wilson & Davide Eynard - cq - Stack Overflow for Agents - AI Native DevCon June 2026 thumbnail

· 31:32

Peter Wilson & Davide Eynard - cq - Stack Overflow for Agents - AI Native DevCon June 2026

The session introduces CQ (Mozilla.ai's proposal), a system designed as a 'Stack Overflow for agents.' Its core purpose is to standardize and share knowledge units (KUs) across autonomous AI agents—locally, within an organization, or publicly. This prevents agents from repeating mistakes, wasting tokens, and ensures that lessons learned by one agent can benefit all others, thereby improving the reliability of complex automated workflows.

Key takeaways

  1. Knowledge Unit (KU) Standardization 17:09

    A KU is a standardized knowledge artifact (stored in JSON format) capturing solutions to novel problems. It includes domains, insights, actions taken, summaries, and metadata (languages/frameworks).

  2. Agentic Context Management 6:15

    Effective agent performance relies heavily on context injection. The system aims to move beyond simple memory files by allowing agents to query a centralized knowledge base for relevant solutions before starting a task.

  3. Layered Sharing Model 20:40

    CQ supports three levels of knowledge sharing: local (SQLite database, no review), private/team (requires user authentication and human-in-the-loop review), and public commons (CQ Exchange).

Watch on YouTube Full article

FORGET Loop Engineering. Agentic Engineering is about THIS thumbnail

· 34:18

FORGET Loop Engineering. Agentic Engineering is about THIS

The video argues that 'Loop Engineering' is an insufficient and inaccurate mental model for modern software development with AI agents. The superior approach is **Agentic Engineering**, which focuses on building complex AI developer workflows (ADWs) within a 'software factory.' These ADWs orchestrate three core actors of value creation—Engineers, Agents, and Code—to automate the entire development lifecycle, from planning to deployment, thereby scaling impact and accelerating development far beyond what simple loops can achieve.

Key takeaways

  1. Shift Focus from Loops to Workflows

    Loop engineering is a poor rebrand of the Software Development Life Cycle (SDLC). The focus must be on building comprehensive AI developer workflows that combine code execution with agents, rather than focusing solely on iterative loops.

  2. The Three Actors of Value Creation 2:00

    Successful agentic engineering requires understanding and strategically placing three actors: the human engineer, specialized AI agents, and deterministic code. Code is highlighted as the most reliable actor because it costs zero tokens and runs consistently.

  3. Scaling Developer Workflows 4:00

    Advanced workflows move beyond simple loops by integrating multiple validation steps (e.g., linting, type checking, formatting) and scaling compute through specialized sandboxes for parallel execution. This process is the core of building a 'software factory.'

  4. Meta-Engineering: Building the System 8:00

    The most valuable engineering effort is not working on the application layer, but performing meta-work on the agentic layer—building the system that orchestrates and manages all other components (the 'system that builds the system').

Watch on YouTube Full article

When millions of AI agents meet thumbnail

· 42:38

When millions of AI agents meet

This discussion explores the shift from traditional Large Language Models (LLMs) to autonomous AI agents capable of executing multi-step plans, transacting, and delegating tasks. The concept of an 'agentic economy' suggests a future where intelligence is distributed across specialized agents rather than residing in single systems. Key technical challenges discussed include managing agent failure rates, preventing automation bias, securing the system against malicious 'agentic traps,' and developing robust orchestration protocols for complex, real-world workflows.

Key takeaways

  1. Agent vs. Language Model 0:35

    An LLM merely provides continuation or a reply to a prompt; an AI agent observes a state of the world and performs actions in an environment (e.g., purchasing tickets, sending emails). Agents use LLMs under the hood but are wrapped in a harness that enables multi-step planning and automation [0:35].

  2. Distributed Intelligence 28:40

    The future may not be defined by Artificial General Intelligence (AGI) as a single entity, but rather by 'distributed intelligence'—a 'society of specialists.' This model suggests that specialized, smaller models are cheaper to run and more reliable than one massive generalist model [17:20].

  3. Agentic Security Risks 22:26

    The deployment of agents at scale introduces significant cybersecurity risks. These include 'agentic traps' (malicious code or prompts in the environment) and 'dynamic cloaking,' where web pages display different content for humans versus agents, potentially inducing jailbreaking [1:50].

Watch on YouTube Full article