DEV Community: Richard Dillon

Deep Agents: Building Long-Running Autonomous Agents with LangChain's New Framework

Richard Dillon — Mon, 20 Apr 2026 12:03:14 +0000

Deep Agents: Building Long-Running Autonomous Agents with LangChain's New Framework

The era of single-turn, reactive agents is ending. As engineering teams push toward workflows that span hours instead of seconds—internal coding pipelines, multi-stage research synthesis, iterative design systems—the limitations of flat tool-calling architectures become painfully obvious. You cannot orchestrate a code review that spawns test generation, runs CI, waits for human approval, and then deploys without a fundamentally different approach to agent architecture. LangChain's Deep Agents framework, announced alongside Deep Agents Deploy in March 2026, represents the clearest attempt yet to provide production-grade abstractions for this class of problem.

This isn't just another wrapper. Deep Agents introduces a layered architecture where planning loops, persistent memory, and sub-agent delegation are first-class concerns—not afterthoughts bolted onto a ReAct loop. The framework sits deliberately above LangGraph (which gives you fine-grained state machine control) and the standard LangChain abstractions (which optimize for quick iteration). If you're building agents that need to survive restarts, coordinate specialized sub-agents, and maintain coherent long-term memory across sessions, this is the stack to understand.

The use cases driving adoption are telling: Open SWE for internal coding agents that autonomously fix bugs across repositories, GTM workflow automation that coordinates across CRM systems and communication channels, and design iteration systems like the Moda case study where agents loop through revision cycles with human feedback gates. In this deep-dive, we'll dissect the architecture, walk through the key APIs, examine deployment considerations, and build a working research-then-draft agent from scratch.

The Deep Agents Architecture: Planning, Memory, and Sub-Agents

The Deep Agents framework rests on three architectural pillars that distinguish it from simpler agent implementations: planning loops that decompose goals into task graphs, persistent memory that survives across sessions and crashes, and sub-agent delegation that enables specialized capabilities to run in parallel.

Planning Mechanism

Traditional agents operate on flat tool-calling sequences—the model decides the next action based on the current state, executes it, and repeats. This works for simple tasks but falls apart when you need hierarchical goal decomposition. Deep Agents introduces a planning layer that generates task graphs before execution begins. The planning model analyzes the high-level objective, identifies dependencies between subtasks, and produces a directed acyclic graph (DAG) of work items. Each node in this graph can represent a direct tool call, a sub-agent invocation, or a human approval checkpoint.

This approach parallels findings from the W&D paper on parallel tool calling, which demonstrated that research agents achieve significant speedups when tool calls without mutual dependencies execute concurrently. Deep Agents extends this to sub-agent coordination: a parent agent can spawn multiple child agents in a single planning step, wait for their results in parallel, and then synthesize findings before proceeding.

Memory Subsystem

The memory architecture draws heavily from recent research on temporal reasoning in conversational AI. The APEX-MEM framework introduced property graphs with timestamp annotations for resolving when facts were learned and whether they remain valid. Deep Agents implements a similar approach: events are stored in append-only logs with temporal metadata, and the memory retrieval system can answer queries like "what did we learn about this repository before the last deployment?" rather than just "what do we know about this repository?"

The MongoDB integration announced in the LangChain + MongoDB partnership provides durable checkpointing out of the box. Every state transition, planning decision, and sub-agent result gets persisted to MongoDB Atlas, enabling crash recovery and long-running workflows that span days.

Sub-Agent Delegation

Sub-agents aren't just function calls with extra steps—they're fully autonomous agents with their own planning loops, memory contexts, and tool access. The parent agent maintains a registry of available sub-agents with capability descriptions, and the planning model can decide to delegate tasks to the most appropriate specialist. This mirrors the "harness" concept from LangChain's architecture documentation: the separation between orchestration logic (what needs to happen and when) and compute execution (the actual work). The parent agent is the orchestrator; sub-agents are the compute layer.

Hands-On: Code Walkthrough

Let's build a research-then-draft agent that demonstrates the core Deep Agents patterns. This agent accepts a topic, spawns specialized sub-agents for search and summarization, uses long-term memory to avoid redundant work, and produces a structured Markdown report.

"""
research_agent.py
A Deep Agent that coordinates search and summarization sub-agents
to produce research reports with persistent memory.

Requires:
- langchain-core >= 0.3.42
- langchain-deepagents >= 0.1.8
- langchain-mongodb >= 0.2.1
- langchain-community >= 0.3.20 (for TavilySearchResults)
"""

from langchain_deepagents import DeepAgent, SubAgent, PlanningConfig
from langchain_mongodb import MongoDBCheckpointer, MongoDBMemory
from langchain_community.tools import TavilySearchResults
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
from typing import List, Dict, Any
import os

# Initialize the planning model - Claude 3.5 Sonnet works well for planning tasks
planning_model = ChatAnthropic(
    model="claude-sonnet-4-20250514",
    max_tokens=4096,
    temperature=0.1  # Low temperature for more deterministic planning
)

# Configure MongoDB checkpointer for crash recovery
# This persists every state transition to Atlas
checkpointer = MongoDBCheckpointer(
    connection_string=os.environ["MONGODB_URI"],
    database_name="deep_agents",
    collection_name="research_agent_checkpoints",
    # Enable TTL for automatic cleanup of old checkpoints
    ttl_seconds=86400 * 30  # 30 days retention
)

# Long-term memory backend with temporal resolution
# Stores facts with timestamps for "when did we learn this?" queries
memory_backend = MongoDBMemory(
    connection_string=os.environ["MONGODB_URI"],
    database_name="deep_agents",
    collection_name="research_memory",
    # Enable vector search for semantic retrieval
    vector_index_name="memory_vector_index",
    embedding_dimensions=1536
)

# Define the search sub-agent's tool
search_tool = TavilySearchResults(
    max_results=5,
    search_depth="advanced",
    include_raw_content=True
)

@tool
def extract_key_claims(content: str) -> List[Dict[str, str]]:
    """Extract key claims and their supporting evidence from content."""
    # In production, this would call a specialized extraction model
    # Here we're showing the tool interface pattern
    return [{"claim": content[:200], "evidence": content[200:400]}]

# Define the search sub-agent
search_subagent = SubAgent(
    name="search_agent",
    description="Searches the web for current information on a topic. "
                "Use this for gathering primary sources and recent developments.",
    tools=[search_tool],
    model=ChatAnthropic(model="claude-sonnet-4-20250514"),
    # Sub-agents can have their own planning constraints
    max_iterations=10,
    # Memory scope: this sub-agent shares memory with parent
    memory_scope="shared"
)

# Define the summarization sub-agent
summarization_subagent = SubAgent(
    name="summarization_agent", 
    description="Condenses and synthesizes information from multiple sources. "
                "Use this after gathering raw sources to produce coherent summaries.",
    tools=[extract_key_claims],
    model=ChatAnthropic(model="claude-sonnet-4-20250514"),
    max_iterations=5,
    memory_scope="shared"
)

# Configure planning behavior
planning_config = PlanningConfig(
    # Maximum depth of planning recursion
    max_planning_depth=3,
    # Timeout for individual sub-agent invocations (seconds)
    sub_agent_timeout=300,
    # Enable parallel sub-agent execution when dependencies allow
    parallel_execution=True,
    # Replan if a sub-agent fails rather than failing the whole workflow
    replan_on_failure=True
)

# Initialize the Deep Agent
research_agent = DeepAgent(
    name="research_report_agent",
    description="Produces comprehensive research reports by coordinating "
                "search and summarization specialists.",
    planning_model=planning_model,
    memory_backend=memory_backend,
    checkpointer=checkpointer,
    sub_agents=[search_subagent, summarization_subagent],
    planning_config=planning_config,
    # Path to custom instructions file
    instructions_path="./AGENTS.md"
)

# Example invocation
async def generate_report(topic: str, session_id: str) -> str:
    """
    Generate a research report on the given topic.
    Uses session_id for memory continuity across invocations.
    """
    result = await research_agent.ainvoke(
        {
            "objective": f"Research the topic '{topic}' and produce a "
                        f"structured Markdown report with citations.",
            "output_format": "markdown",
            "max_sources": 10
        },
        config={
            "session_id": session_id,
            # Enable LangSmith tracing for observability
            "callbacks": [],  # LangSmith callbacks auto-inject when configured
            # Memory retrieval configuration
            "memory_config": {
                "retrieve_before_planning": True,
                "max_memory_items": 50,
                # Skip sources we've already processed in this session
                "dedupe_by": "url"
            }
        }
    )
    return result.output

# Run the agent
if __name__ == "__main__":
    import asyncio

    report = asyncio.run(generate_report(
        topic="Recent advances in parallel tool calling for AI agents",
        session_id="research-session-001"
    ))
    print(report)

The AGENTS.md file referenced above provides custom instructions that guide agent behavior:

# Research Report Agent Instructions

## Planning Guidelines
- Always check memory for previously researched sources before searching
- Spawn search_agent first to gather sources, then summarization_agent to synthesize
- If fewer than 3 high-quality sources found, replan with broader search terms

## Output Requirements
- Include inline citations linking to source URLs
- Structure reports with: Executive Summary, Key Findings, Detailed Analysis, Sources
- Flag any conflicting information between sources

## Safety Constraints
- Do not include speculation presented as fact
- Mark any information older than 6 months as potentially outdated

To view execution traces and debug planning decisions, access the LangSmith dashboard where each planning step, sub-agent invocation, and memory operation appears as a nested span with latency and token cost attribution.

Deployment Patterns: Deep Agents Deploy and Sandbox Execution

Running long-running agents in production requires infrastructure that most teams don't want to build themselves. Deep Agents Deploy, announced as "an open alternative to Claude Managed Agents", provides a hosted runtime specifically designed for agents that execute over minutes or hours rather than seconds.

Infrastructure Abstraction

Deep Agents Deploy handles the unglamorous but critical concerns: process isolation, crash recovery, timeout management, and resource allocation. When your agent spawns ten sub-agents in parallel for a research task, the runtime distributes these across worker pools and manages backpressure. When a network partition causes a checkpoint failure, the runtime automatically retries from the last durable state.

This separation mirrors the architecture pattern OpenAI introduced in their Agents SDK evolution: the harness (orchestration logic) runs on managed infrastructure while compute (the actual LLM calls and tool executions) can be distributed across different environments. Deep Agents Deploy implements this pattern with first-class support for LangGraph-based sub-agents.

Hardware Acceleration

The NVIDIA enterprise integration enables hardware acceleration for compute-intensive sub-agents. When a Deep Agent spawns multiple sub-agents that each need to process large documents or run inference on specialized models, the langchain-nvidia package routes these to NIM microservices running on GPU infrastructure. This becomes significant when your planning DAG has wide parallelism—ten sub-agents each running a 70B parameter model benefit substantially from NIM's optimized batch inference.

Durability and Cost

MongoDB-backed checkpoints provide durability guarantees that in-memory state cannot. If your agent is three hours into a complex workflow and the host process dies, resumption picks up from the last checkpoint rather than starting over. The MongoDB partnership specifically targets this use case: vector search for memory retrieval and document checkpointing unified in a single database you're likely already running.

Cost attribution in long-running agents requires tracking spend across sub-agent invocations. LangSmith Fleet provides identity-based cost tracking where each Deep Agent instance accumulates costs from all its sub-agent invocations, enabling accurate per-workflow billing and optimization.

Security Considerations

For agents that execute code—and most production agents eventually do—sandboxing is non-negotiable. LangSmith Sandboxes provide isolated execution environments for code-generation sub-agents, preventing arbitrary code execution from compromising your infrastructure. For runtime policy enforcement on tool calls, the Agent Governance Toolkit integrates with Deep Agents to enforce constraints like "this agent cannot call external APIs after 6 PM" or "this agent cannot modify files outside the /workspace directory."

Evaluation and Observability for Long-Running Agents

Traditional LLM evaluation—comparing model outputs to gold-standard responses—breaks down for autonomous agents. When an agent takes 47 steps to complete a task, the final output might be correct even if step 23 was wildly inefficient. Conversely, an incorrect final output might result from a single bad decision at step 12 that cascaded through the rest of the workflow.

The Observability Gap

The State of Agent Engineering survey found that 89% of production teams use observability for their agents, but evaluation remains the biggest blocker to deployment confidence. Teams can see what their agents are doing but struggle to systematically assess whether the agents are doing it well.

LangSmith addresses this with trace-based evaluation: each planning step, sub-agent result, and memory operation gets captured as a span that can be individually scored. You define evaluators that examine not just the final output but the quality of intermediate decisions:

from langsmith.evaluation import RunEvaluator

class PlanningQualityEvaluator(RunEvaluator):
    """Evaluates whether the agent's planning was efficient."""

    def evaluate_run(self, run, example=None):
        # Extract planning steps from the trace
        planning_spans = [s for s in run.child_runs 
                         if s.name.startswith("planning_")]

        # Score based on planning efficiency metrics
        replan_count = sum(1 for s in planning_spans 
                          if "replan" in s.name)

        # Penalize excessive replanning
        score = max(0, 1.0 - (replan_count * 0.2))

        return {"key": "planning_efficiency", "score": score}

Skills as Evaluated Capabilities

Deep Agents introduces "Skills"—reusable, versioned capabilities that agents can attach. A "web_research" skill encapsulates the ability to search, filter, and synthesize web content. Each skill has associated evaluators that run during CI to ensure capability regressions don't ship to production. When you upgrade from web_research@1.2 to web_research@1.3, the skill's evaluation suite must pass before deployment.

Harness Optimization

The hill-climbing approach to harness configuration uses evaluation feedback loops to optimize agent behavior. You define success metrics (task completion rate, average step count, cost per task), run the agent against a benchmark suite, and systematically adjust harness parameters—max_planning_depth, sub_agent_timeout, memory retrieval limits—to improve metrics. This transforms agent tuning from intuition-driven to data-driven.

What This Means for Your Stack

When to choose Deep Agents over LangGraph: Deep Agents adds value when your workflow requires persistent memory across sessions, autonomous goal decomposition, or sub-agent coordination. If you're building a customer support bot that handles single queries, LangGraph's lower-level abstractions are simpler and faster to iterate on. If you're building an internal coding agent that maintains context across PRs, learns from past reviews, and coordinates linter, test-runner, and documentation sub-agents, Deep Agents provides the right level of abstraction.

Memory backend selection: The MongoDB Checkpointer makes sense for teams already running Atlas—you get vector search for memory retrieval and checkpointing in a single managed database. For teams with existing PostgreSQL infrastructure, PostgresSaver provides equivalent durability with pgvector for semantic retrieval. The temporal reasoning features from the APEX-MEM research are currently better supported in the MongoDB backend.

Migration path: Existing LangGraph agents can be wrapped as sub-agents within a Deep Agent orchestrator. This enables incremental migration: start by wrapping your most complex workflow as a Deep Agent while keeping simpler agents on LangGraph. The shared memory scope ensures the orchestrator and sub-agents maintain consistent context.

Cost and latency tradeoffs: Long-running agents accumulate token costs across planning iterations and sub-agent invocations. Set max_planning_depth limits based on your cost tolerance. Monitor speculative_waste_ratio in LangSmith—this metric shows how often the planning model generates plans that get abandoned due to execution failures. A high ratio indicates either overly ambitious planning or unreliable tools.

Team readiness: Deep Agents requires observability maturity. If your team isn't already using LangSmith tracing for existing LLM workflows, start there before deploying autonomous agents. The State of Agent Engineering findings make this clear: teams without observability infrastructure struggle to debug and optimize agent behavior.

Security posture: Enable Sandboxes for any code-execution sub-agents—this is not optional for production deployments. Integrate with the Agent Governance Toolkit for runtime policy enforcement. Define explicit constraints on what tools each sub-agent can call and under what conditions.

What to Build This Week

Build a code review coordination agent that demonstrates the full Deep Agents architecture:

Parent Agent: Accepts a PR URL, plans the review workflow, coordinates sub-agents, maintains memory of past reviews on this repository
Static Analysis Sub-Agent: Runs linters and type checkers, reports findings
Security Review Sub-Agent: Scans for common vulnerabilities, checks dependency updates
Test Coverage Sub-Agent: Identifies untested code paths, suggests test cases
Documentation Sub-Agent: Checks for missing docstrings, outdated README sections

Configure MongoDB checkpointing so the review survives interruptions. Use the AGENTS.md file to encode your team's code review standards. Set up LangSmith tracing and build a custom evaluator that scores review thoroughness against a benchmark of manually-reviewed PRs.

The goal isn't a production-ready tool—it's hands-on experience with planning DAGs, sub-agent coordination, persistent memory, and trace-based evaluation. These are the primitives that every non-trivial agent will require as we move from demos to deployment.

Sources

- Introducing the Agent Governance Toolkit - Microsoft Open Source

This is part of the **Agentic Engineering Weekly* series — a deep-dive every Monday into the frameworks,
patterns, and techniques shaping the next generation of AI systems.*

Follow the Agentic Engineering Weekly series on Dev.to to catch every edition.

Building something agentic? Drop a comment — I'd love to feature reader projects.

AI Weekly: Agent Wars Escalate as Anthropic Reclaims Benchmark Crown and Infrastructure Reality Bites

Richard Dillon — Mon, 20 Apr 2026 12:02:37 +0000

AI Weekly: Agent Wars Escalate as Anthropic Reclaims Benchmark Crown and Infrastructure Reality Bites

The battle for AI supremacy entered a new phase this week as Anthropic's Claude Opus 4.7 narrowly reclaimed the top spot on agentic coding benchmarks, while OpenAI responded by expanding Codex's desktop automation capabilities in a direct challenge to Anthropic's computer use features. Meanwhile, a sobering Reuters analysis put hard numbers on the gap between AI ambitions and physical reality—a $7 trillion gap, to be precise.

OpenAI Beefs Up Codex With Desktop Control, Taking Direct Aim at Anthropic

OpenAI announced significant enhancements to its Codex agent this week, rolling out expanded desktop automation capabilities that position the tool as a direct competitor to Anthropic's computer use features. The update, detailed in OpenAI's enterprise AI roadmap, gives Codex substantially more power over user desktop environments, including the ability to navigate file systems, manipulate application windows, and execute multi-step workflows across different programs.

The timing is no coincidence. Anthropic's computer use capabilities, introduced with Claude 3.5 Sonnet in late 2024, established an early lead in the "agents that control your screen" category. OpenAI's enhanced Codex represents a calculated move to close that gap before enterprise adoption patterns solidify. According to VentureBeat's coverage of the announcement, the new features include improved error recovery when desktop automation encounters unexpected UI states—a critical pain point in earlier agentic systems.

Industry observers note this escalation reflects broader "agent wars" dynamics between major AI labs. As models converge on similar benchmark performance, the competitive differentiation increasingly comes from how effectively these systems can operate autonomously in real-world computing environments. OpenAI appears to be betting that enterprise customers will favor tighter integration with existing productivity workflows over raw model capability alone.

Anthropic CPO Departs Figma Board Amid Reports of Competing Product Launch

In a move that sent ripples through both AI and design tool communities, Anthropic's Chief Product Officer departed from Figma's board of directors this week. TechCrunch reported that the departure stemmed from plans to launch a product that would compete directly with Figma's collaborative design platform.

The resignation highlights an increasingly awkward tension: AI companies that once positioned themselves as infrastructure providers are now eyeing the application layer—including tools built by their own board affiliates. For Figma, which has spent years building a collaborative design ecosystem, the prospect of an AI-native competitor backed by one of the leading foundation model companies represents an existential-level threat.

The departure raises broader questions about AI companies' expansion strategies. Anthropic has historically emphasized its role as a model provider and safety research organization, but the design tool space represents lucrative territory where AI capabilities could fundamentally reshape workflows. Single-prompt generation of complex design assets, AI-driven prototyping, and intelligent design system management are all areas where foundation model capabilities could disrupt incumbent tools.

Industry analysts suggest this move may accelerate consolidation in the design tool market, as traditional players race to integrate AI capabilities before AI-native alternatives mature.

Agentic Programming Updates

The agentic AI landscape continues its rapid evolution, with new data underscoring both the opportunity and organizational challenges ahead. According to UiPath's 2026 report, 78% of executives say they need to reinvent their operating models to capture agentic AI value—a stark admission that current organizational structures weren't designed for autonomous AI systems.

Architecture patterns are maturing quickly. The era of solo agents handling tasks in isolation is giving way to multi-agent systems featuring centralized control layers that coordinate specialized agents, handle inter-agent communication, and maintain coherent state across complex workflows. This "orchestration layer" approach mirrors microservices patterns from traditional software architecture.

Quality control practices are adapting accordingly. Agentic QA—where AI agents review AI-generated code for security vulnerabilities, architectural consistency, and adherence to coding standards—is becoming standard practice in mature development organizations. The irony of AI checking AI isn't lost on practitioners, but the approach has proven more scalable than human review alone.

For those tracking the space, the awesome-ai-agents-2026 GitHub repository now catalogs over 340 resources across 20 categories, updated monthly. Key framework categories that have emerged include IDE-native agents, terminal/CLI agents, autonomous software engineers, and multi-agent orchestration platforms—reflecting the field's rapid specialization.

InsightFinder Raises $15M to Debug Where AI Agents Go Wrong

InsightFinder announced a $15 million funding round this week, targeting the growing observability gap as enterprises deploy increasingly autonomous AI agents. The company's platform focuses specifically on helping organizations diagnose why and where AI agent workflows fail—a problem that grows more critical as agents handle longer, more complex task chains.

The funding reflects a maturing market reality: deploying AI agents is relatively straightforward; understanding what they're doing and why they fail is considerably harder. Traditional application performance monitoring tools weren't designed for systems where the "application logic" is an emergent property of model behavior rather than deterministic code paths.

InsightFinder's approach involves capturing detailed traces of agent reasoning, tool calls, and environmental interactions, then using specialized models to identify failure patterns and root causes. Enterprise customers report that debugging time for agent failures has dropped by 60-70% compared to manual log analysis.

The round signals broader investor confidence in the AI operations tooling layer. As VentureBeat noted, the "AI observability" category has attracted over $200 million in venture funding in 2026 alone, suggesting that operational maturity—not just raw capability—is becoming the key enterprise adoption bottleneck.

Claude Opus 4.7 Reclaims Top Spot With 64.3% SWE-bench Pro Score

Anthropic released Claude Opus 4.7 this week, narrowly reclaiming the crown for most powerful generally available large language model. The new release achieved 64.3% on SWE-bench Pro agentic coding tasks—a significant jump from the 53.4% score posted by its predecessor and enough to edge past both GPT-5.4 and Gemini 3.1 Pro on key benchmarks.

The visual processing improvements are equally striking. Performance on XBOW tests—which measure fine-grained visual understanding—jumped from 54.5% to 98.5%, suggesting Anthropic has made substantial progress on multimodal capabilities that translate directly to computer use and GUI automation tasks.

Notably absent from the public release: Mythos, Anthropic's more powerful successor model that reportedly surpasses Opus 4.7 by a significant margin. According to the VentureBeat report, Mythos remains restricted to enterprise security partners, suggesting Anthropic is taking a staged approach to releasing its most capable systems.

The LLM comparison data tracking these releases shows benchmark competition has intensified dramatically—margins between leading models are now measured in single percentage points rather than the double-digit gaps common in 2024.

$7 Trillion Reality Check: AI Infrastructure Dreams Hit Power Wall

A sobering Reuters analysis published this week put hard numbers on the gap between AI ambitions and physical reality. Meta, xAI, and other major players are collectively targeting data centers consuming 110 gigawatts—roughly equivalent to Japan's entire electricity consumption. The price tag for this infrastructure build-out: approximately $7 trillion.

NVIDIA CEO Jensen Huang's recent estimate that each major AI data center requires a minimum $60 billion investment underscores the scale challenge. These aren't software problems solvable with clever engineering; they're physical infrastructure constraints that require years of permitting, construction, and grid upgrades to address.

The Reuters analysis questions whether current AI business models can sustain these capital requirements. Revenue from AI services would need to grow by orders of magnitude to justify infrastructure investments at this scale—a bet that assumes continued exponential capability improvements translating into proportional commercial value.

Power availability has emerged as the critical bottleneck. Even companies with unlimited capital face multi-year timelines to secure sufficient electricity, leading to creative solutions like locating facilities near nuclear plants or acquiring entire utility companies. The irony isn't lost on observers: the most advanced AI systems humanity has built are ultimately constrained by our ability to move electrons.

Google AI Mode Now Enables Side-by-Side Web Exploration

Google rolled out a significant update to its AI Mode this week, introducing side-by-side web exploration that lets users browse source materials while interacting with AI-generated responses. The feature, announced alongside the global rollout of Gemini 3.1 Flash Live, addresses persistent user demand for source verification in AI-assisted search.

The implementation reflects Google's attempt to thread a difficult needle: providing the convenience of AI-synthesized answers while preserving the web's role as a navigable information ecosystem. Users can now click on any cited source within an AI Mode response to open it in a split-screen view, examining the original context without losing their AI conversation thread.

For publishers who have worried about AI reducing web traffic, the feature offers a partial olive branch—though whether it meaningfully increases click-through rates remains to be seen. Early data from Google suggests users do engage with source materials roughly 40% of the time when the side-by-side option is available.

The broader trend points toward hybrid AI-augmented browsing becoming the default web experience. Rather than choosing between traditional search and AI chat interfaces, users increasingly expect both simultaneously—a pattern that VentureBeat suggests will reshape how websites are designed and optimized.

Adobe Firefly Assistant Aims to Unify Creative Suite With Single-Prompt Control

Adobe launched its Firefly AI Assistant this week, a cross-application tool that spans Photoshop, Premiere Pro, Illustrator, and other Creative Cloud applications. The headline capability: a single natural language prompt can orchestrate actions across multiple apps simultaneously—edit an image in Photoshop, apply matching color grading in Premiere, and generate complementary vector assets in Illustrator, all from one command.

The integration represents Adobe's most aggressive move yet to defend its creative tool dominance against AI-native competitors. As TechCrunch coverage notes, startups have been chipping away at individual Creative Cloud use cases with AI-first approaches; Adobe's response is to leverage its multi-application ecosystem as a moat that single-purpose AI tools can't easily cross.

Early user feedback suggests the workflow consolidation delivers genuine productivity gains for complex projects, though the learning curve for effective prompting remains steep. Power users report that crafting prompts that reliably produce desired cross-application results requires substantial experimentation.

The assistant also introduces persistent project context—it remembers style decisions, brand guidelines, and user preferences across sessions and applications. For creative teams working on large-scale projects, this contextual memory could prove more valuable than the generation capabilities themselves.

What to Watch

The infrastructure reality check from Reuters deserves close attention in coming months—if power constraints force AI labs to slow capability scaling, the entire competitive dynamic could shift toward efficiency optimization rather than raw capability races. Meanwhile, the narrowing benchmark gaps between Claude, GPT, and Gemini suggest we're approaching a regime where model differentiation comes from tooling, ecosystem integration, and deployment flexibility rather than benchmark scores. Expect the agent wars to intensify as that new competitive landscape takes shape.

Sources

- Anthropic releases Claude Opus 4.7 | VentureBeat

Enjoyed this briefing? Follow this series for a fresh AI update every week, written for engineers who want to stay ahead.

Follow this publication on Dev.to to get notified of every new article.

Have a story tip or correction? Drop a comment below.

LangSmith Fleet: Managing Agent Identity, Permissions, and Skills at Enterprise Scale

Richard Dillon — Mon, 13 Apr 2026 12:05:36 +0000

LangSmith Fleet: Managing Agent Identity, Permissions, and Skills at Enterprise Scale

The LangChain team quietly shipped one of the most significant architectural changes to LangSmith in March 2026, and it wasn't a new model integration or a flashy UI overhaul. They renamed Agent Builder to Fleet—a seemingly cosmetic change that signals a fundamental shift in how enterprises should think about their AI agent portfolios. This isn't about building better individual agents anymore; it's about managing dozens or hundreds of agents as a coordinated organizational capability. If you're running more than a handful of agents in production, this is the infrastructure layer you didn't know you needed.

The timing is deliberate. LangChain's State of Agent Engineering report revealed a troubling gap: 89% of organizations have observability in place, but most lack centralized governance for their agent portfolios. Teams are spinning up agents in silos, duplicating prompt engineering effort, and losing track of which agents have access to what resources. Fleet directly addresses this governance vacuum by introducing three primitives that enterprise deployments desperately need: agent identity, role-based permissions, and reusable Skills.

With 300+ enterprise customers now processing over 15 billion traces, LangSmith has accumulated hard-won lessons about what breaks at scale. Fleet codifies these patterns into infrastructure that prevents the debugging nightmare of "which agent caused this production incident?" before it happens.

Fleet Architecture: Identity and Permissions Model

The core insight behind Fleet's design is deceptively simple: every agent in your organization needs a stable, auditable identity that persists across deployments, versions, and team ownership changes. This sounds obvious until you realize how most teams currently manage agents—as anonymous graph definitions deployed via CI/CD with no central registry.

Fleet's identity system assigns each agent a unique organizational identifier that ties together its definition, deployment history, performance metrics, and access patterns. This identity travels with the agent across environments. When your compliance checking agent runs in staging versus production, it's the same identity with environment-specific configuration, not two unrelated deployments you have to mentally correlate.

The permission model layers role-based access control on top of these identities. Fleet distinguishes between several permission levels: viewers can observe agent behavior and metrics, editors can modify prompts and tool configurations, deployers can push agents to production environments, and administrators can retire agents or transfer ownership. These map cleanly to organizational realities—your ML platform team shouldn't need to ask a Slack channel before deploying a new agent version, but they probably shouldn't be editing the legal team's contract review prompts without approval.

Sharing mechanisms enable cross-team agent reuse without the current anti-pattern of exporting agent definitions as JSON and importing them into another workspace. When a shared agent is updated, teams consuming it can see the update and choose to adopt it—version control semantics applied to agent definitions. This preserves provenance: you always know which team owns the canonical definition and what modifications downstream teams have made.

Integration with enterprise identity providers happens at the organization level. Fleet supports SSO and SAML authentication, which means your existing Okta groups or Azure AD roles can map directly to Fleet permissions. The compliance team's AD group gets viewer access to all agents; the ML platform team's group gets deployer access. No separate permission system to maintain.

The audit trail functionality captures agent lifecycle events comprehensively: creation timestamp and creator identity, every modification with diff visibility, deployment events across environments, permission grants and revocations. This isn't just for compliance checkbox exercises—it's the forensic evidence you need when a production agent starts behaving unexpectedly six weeks after someone made a "minor prompt tweak."

Skills: Equipping Agents with Reusable Capabilities

If identity and permissions form Fleet's governance layer, Skills represent its knowledge management layer. A Skill is a modular, shareable knowledge package that can be attached to any agent in your fleet. The March 2026 newsletter announced the first open-source Skills alongside the Fleet rename, establishing an ecosystem pattern that will likely expand significantly.

The architectural insight here addresses a real pain point: domain expertise shouldn't be trapped inside individual agent definitions. When your engineering team figures out the optimal way to interact with your internal APIs—the authentication dance, rate limiting patterns, error recovery logic—that knowledge currently lives in one agent's prompts. Every subsequent agent that needs API access must rediscover or copy-paste this expertise.

Skills separate domain expertise from agent orchestration logic. A "Company API Integration" Skill encapsulates authentication patterns, retry strategies, and response parsing conventions. A "Legal Document Formatting" Skill knows your organization's citation styles, confidentiality markings, and section numbering conventions. These Skills attach to agents without modifying the agent's core orchestration graph.

The skill attachment model supports both static and dynamic binding. Static attachment happens at agent definition time—you declare that your contract review agent always uses the Legal Document Formatting Skill. Dynamic attachment allows agents to discover and request Skills at runtime based on task requirements, though this requires more sophisticated capability negotiation that most teams won't need initially.

Version management for Skills solves the knowledge distribution problem. When your platform team improves the API Integration Skill—say, adding support for a new authentication method—that improvement propagates to all agents using the Skill. Teams can pin to specific Skill versions for stability or track the latest version for continuous improvement. The semantics mirror dependency management in traditional software development, which makes the mental model accessible to engineering teams.

The skill definition format establishes a standard structure that includes capability declarations (what the Skill enables), knowledge content (prompts, examples, patterns), tool bindings (if the Skill requires specific tool access), and configuration parameters (organization-specific customization points). This standardization means Skills can be shared not just within organizations but eventually across the emerging ecosystem of function calling improvements that the broader community is developing.

Hands-On: Code Walkthrough

Let's build a practical Fleet setup with multiple agents, custom Skills, and proper permission configuration. This example creates a document processing fleet for a legal department with shared compliance capabilities.

# fleet_setup.py
# Requires: langsmith>=0.3.0, langchain>=0.4.0, langgraph>=0.3.0

from langsmith import Client
from langsmith.fleet import (
    Fleet, 
    AgentIdentity, 
    Skill, 
    PermissionSet,
    SkillAttachment
)
from langgraph.graph import StateGraph
from typing import TypedDict, Annotated
import operator

# Initialize the LangSmith client with Fleet capabilities
client = Client()
fleet = Fleet(client=client, organization_id="your-org-id")

# Define agent identity with comprehensive metadata
# This identity persists across deployments and environment changes
contract_reviewer_identity = AgentIdentity(
    name="contract-reviewer-v1",
    display_name="Contract Review Agent",
    owner_team="legal-ops",
    purpose="Reviews vendor contracts for compliance issues and risk factors",
    deployment_environments=["staging", "production"],
    tags=["legal", "compliance", "vendor-management"],
    # Metadata for organizational classification
    metadata={
        "cost_center": "LEGAL-001",
        "data_classification": "confidential",
        "review_frequency": "quarterly"
    }
)

# Register the identity with Fleet - this creates the audit trail
registered_identity = fleet.register_agent(contract_reviewer_identity)
print(f"Agent registered with ID: {registered_identity.fleet_id}")

# Define a reusable Skill for compliance checking
# Skills encapsulate domain expertise separate from orchestration
compliance_checking_skill = Skill(
    name="corporate-compliance-rules",
    version="1.2.0",
    description="Encapsulates corporate compliance requirements for contract review",

    # Knowledge content that will be injected into agent context
    knowledge_content="""
    ## Corporate Compliance Requirements

    All vendor contracts must be reviewed against these criteria:

    1. DATA HANDLING: Contracts involving PII must include:
       - Data processing addendum (DPA)
       - SOC 2 Type II certification requirement
       - Data residency clauses for EU customers (GDPR)
       - Breach notification timeline (max 72 hours)

    2. FINANCIAL TERMS: Flag for legal review if:
       - Auto-renewal clauses exceed 1 year
       - Liability caps below $1M for critical services
       - Payment terms shorter than Net 30
       - Price escalation clauses above 5% annually

    3. TERMINATION RIGHTS: Require:
       - Termination for convenience with 90-day notice
       - Immediate termination for material breach
       - Data return/deletion obligations post-termination

    4. INDEMNIFICATION: Standard requirements:
       - Mutual indemnification for IP infringement
       - Vendor indemnification for data breaches caused by vendor
       - Carve-outs for gross negligence
    """,

    # Configuration parameters that can be customized per-organization
    config_schema={
        "liability_threshold": {"type": "number", "default": 1000000},
        "auto_renewal_max_years": {"type": "number", "default": 1},
        "breach_notification_hours": {"type": "number", "default": 72}
    },

    # Tags for discoverability in the Skill registry
    tags=["legal", "compliance", "contracts", "vendor-management"]
)

# Register the Skill with Fleet
registered_skill = fleet.register_skill(compliance_checking_skill)
print(f"Skill registered with ID: {registered_skill.skill_id}")

# Define the agent's state structure
class ContractReviewState(TypedDict):
    contract_text: str
    compliance_issues: Annotated[list, operator.add]
    risk_score: int
    recommendation: str
    skill_context: dict  # Injected by Fleet at runtime

# Build the LangGraph workflow for contract review
def analyze_data_handling(state: ContractReviewState) -> dict:
    """Check contract against data handling requirements from Skill."""
    # Skill context is automatically injected by Fleet
    skill_rules = state.get("skill_context", {}).get("knowledge_content", "")

    # Your LLM call here would use skill_rules in the prompt
    # This is where domain expertise from the Skill gets applied
    issues = []

    # Simplified example - real implementation would use LLM
    contract = state["contract_text"].lower()
    if "data processing addendum" not in contract and "dpa" not in contract:
        issues.append({
            "category": "DATA_HANDLING",
            "severity": "HIGH",
            "finding": "Missing Data Processing Addendum (DPA)",
            "remediation": "Request DPA from vendor before signing"
        })

    return {"compliance_issues": issues}

def analyze_financial_terms(state: ContractReviewState) -> dict:
    """Check financial terms against Skill-defined thresholds."""
    skill_config = state.get("skill_context", {}).get("config", {})
    liability_threshold = skill_config.get("liability_threshold", 1000000)

    issues = []
    # Implementation would parse contract and check against thresholds
    return {"compliance_issues": issues}

def calculate_risk_score(state: ContractReviewState) -> dict:
    """Aggregate issues into overall risk score."""
    issues = state.get("compliance_issues", [])
    high_severity = sum(1 for i in issues if i.get("severity") == "HIGH")
    medium_severity = sum(1 for i in issues if i.get("severity") == "MEDIUM")

    # Risk score: 0-100, higher = more risk
    score = min(100, high_severity * 25 + medium_severity * 10)

    recommendation = "APPROVE" if score < 25 else "REVIEW" if score < 50 else "REJECT"

    return {"risk_score": score, "recommendation": recommendation}

# Construct the graph
workflow = StateGraph(ContractReviewState)
workflow.add_node("data_handling", analyze_data_handling)
workflow.add_node("financial_terms", analyze_financial_terms)
workflow.add_node("risk_calculation", calculate_risk_score)

workflow.add_edge("data_handling", "financial_terms")
workflow.add_edge("financial_terms", "risk_calculation")
workflow.set_entry_point("data_handling")
workflow.set_finish_point("risk_calculation")

graph = workflow.compile()

# Attach the Skill to the agent identity
# This creates the binding between agent and reusable knowledge
skill_attachment = SkillAttachment(
    agent_id=registered_identity.fleet_id,
    skill_id=registered_skill.skill_id,
    version_constraint="~1.2.0",  # Accept 1.2.x patches automatically
    config_overrides={
        "liability_threshold": 2000000,  # Org-specific override
    }
)

fleet.attach_skill(skill_attachment)
print(f"Skill attached to agent")

# Configure permissions for the agent
# RBAC model controls who can view, edit, deploy, or retire
permissions = PermissionSet(
    agent_id=registered_identity.fleet_id,
    rules=[
        # Legal ops team has full control
        {"principal": "group:legal-ops", "role": "admin"},
        # General counsel can view and deploy
        {"principal": "group:general-counsel", "role": "deployer"},
        # All legal staff can view metrics and outputs
        {"principal": "group:legal-all", "role": "viewer"},
        # ML platform team can deploy but not modify prompts
        {"principal": "group:ml-platform", "role": "deployer"},
        # Compliance team needs read access for audits
        {"principal": "group:compliance", "role": "viewer"},
    ]
)

fleet.set_permissions(permissions)
print("Permissions configured")

# Register the compiled graph with the agent identity
# This connects the LangGraph definition to the Fleet identity
fleet.register_graph(
    agent_id=registered_identity.fleet_id,
    graph=graph,
    environment="staging"
)

# Query the Fleet to verify setup
agents = fleet.list_agents(team="legal-ops")
for agent in agents:
    print(f"\nAgent: {agent.display_name}")
    print(f"  Fleet ID: {agent.fleet_id}")
    print(f"  Skills: {[s.name for s in fleet.get_agent_skills(agent.fleet_id)]}")
    print(f"  Permissions: {fleet.get_permissions(agent.fleet_id).summary()}")

# Example: Run the agent with Fleet context injection
result = fleet.invoke(
    agent_id=registered_identity.fleet_id,
    input={
        "contract_text": """
        VENDOR SERVICES AGREEMENT
        This agreement between Acme Corp and BigCloud Inc...
        Payment terms: Net 15
        Auto-renewal: 3 years
        Liability cap: $500,000
        """
    },
    environment="staging"
)

print(f"\nReview Result:")
print(f"  Risk Score: {result['risk_score']}")
print(f"  Recommendation: {result['recommendation']}")
print(f"  Issues Found: {len(result['compliance_issues'])}")

This implementation demonstrates Fleet's key capabilities: persistent agent identity, Skills as reusable knowledge packages, and permission configuration that maps to organizational structure. The skill_context injection pattern keeps domain expertise separate from orchestration logic while making it available where needed.

Observability and Governance at Fleet Scale

Fleet-level observability transforms how you monitor agent portfolios. Instead of drilling into individual agent dashboards and mentally aggregating patterns, Fleet provides organizational views that answer questions like "which agents had the highest error rates this week?" or "which teams are consuming the most LLM tokens?"

The aggregated metrics dashboards span invocation counts, error rates, latency distributions, and token consumption across your entire agent fleet. You can slice these metrics by team, deployment environment, or custom tags. When leadership asks "how much are we spending on AI agents in the legal department?", you can answer with actual data rather than estimates.

Polly, LangSmith's AI assistant that reached general availability alongside Fleet, can analyze fleet-wide patterns and suggest optimizations. This isn't just a chatbot interface to your metrics—Polly can identify correlations across agents that humans miss: "Three agents in the legal-ops team show similar latency spikes every Monday morning, likely correlated with the weekly contract upload batch job."

The correlation between agent identity and LangSmith traces enables per-agent performance drilling that was previously impossible. Every trace automatically tags with the Fleet identity, so you can see exactly how the contract-reviewer-v1 agent performed across all its invocations—not just one deployment, but the complete behavioral history. This longitudinal view reveals drift patterns: if an agent's error rate creeps up over weeks, you can correlate with Skill updates or permission changes that might explain the regression.

Compliance reporting leverages the audit trail to generate reports showing which agents accessed which tools and when. For regulated industries, this isn't optional—legal frameworks are struggling to keep pace with agentic AI, and organizations that can demonstrate clear governance have an advantage. Fleet's event export integrates with enterprise monitoring systems like Datadog and Splunk, feeding agent lifecycle events into existing security and compliance workflows.

Cost attribution by agent identity enables chargeback and budget planning at the organizational level. When the CFO asks why the AI infrastructure budget tripled, you can show exactly which teams and which agents drove the increase—and more importantly, what business value they delivered.

What This Means for Your Stack

If you're operating five or more agents in production, Fleet's identity system addresses a concrete debugging problem: the "which agent did this?" nightmare. When a customer reports unexpected behavior, you need to trace from the symptom back to a specific agent, version, and invocation. Without stable identities, this requires manual correlation across deployment logs, trace IDs, and team knowledge about what's running where.

Skills reduce duplicated prompt engineering effort across your organization. If you've ever watched multiple teams independently solve the same problem—formatting API responses correctly, handling authentication retries, structuring outputs for downstream systems—you've experienced the knowledge fragmentation that Skills address. The investment in creating a Skill pays dividends across every agent that attaches it.

The permission model becomes essential before you give non-engineering teams access to modify agent behavior. The trend toward democratized agent creation is accelerating, and without permission controls, you face either a security nightmare or a bottleneck where engineers review every change. Fleet's RBAC model lets you give marketing the ability to tweak their content agent's prompts without giving them access to the production deployment pipeline.

The migration path from Agent Builder is relatively smooth: existing agents automatically receive Fleet identities when you enable Fleet on your workspace. Skill extraction is manual—you'll need to identify reusable knowledge currently embedded in agent prompts and factor it into Skills. This is work worth doing regardless of Fleet, as it forces you to document tribal knowledge that currently exists only in specific prompts.

Evaluate Fleet alongside whatever agent registry solution you currently have (or more likely, don't have). Many teams are using internal wikis, spreadsheets, or Notion pages to track agents—fine for two or three agents, increasingly untenable as portfolios grow. Fleet provides a programmatic registry with API access, which enables automation that informal registries can't support.

Start with identity and permissions before investing heavily in Skills. Governance foundations enable safe skill sharing later; without them, Skills become another vector for uncontrolled changes propagating across your fleet. Get the audit trail and permission model in place first, then layer Skills on top once you've established who can modify what.

What to Build This Week

Project: Agent Fleet Inventory and Skill Extraction

Before you can benefit from Fleet, you need to understand what you're managing. This week's project is a comprehensive inventory of your current agent portfolio with identification of skill extraction candidates.

Start by cataloging every agent your organization runs: the ones in production, the ones in staging that "will ship soon," and the forgotten experiments still consuming compute in someone's sandbox. For each agent, document: owner team, purpose, tools it accesses, data it processes, current deployment status, and rough monthly cost.

Next, analyze the prompts across these agents looking for duplicated expertise. Common patterns include: API interaction conventions, output formatting requirements, domain-specific terminology definitions, error handling approaches, and citation/attribution styles. These are your Skill extraction candidates.

Create one Skill from the most duplicated pattern you find. Define its knowledge content, configuration parameters, and tags. Attach it to two existing agents and verify they behave consistently. This gives you hands-on experience with the Skill model before you scale.

Finally, draft an RBAC policy for your fleet. Which teams should be viewers, editors, deployers, or administrators for which agents? Map this to your existing identity provider groups. You don't need Fleet to implement the policy—having it documented means you're ready when Fleet permissions become available in your workspace.

The deliverable is a Fleet readiness document: agent inventory, three skill extraction candidates with rough definitions, and an RBAC policy ready for implementation. This preparation work ensures you can adopt Fleet deliberately rather than reactively when the tooling matures.

Sources

- Data-Driven Function Calling Improvements in Large Language Models

This is part of the **Agentic Engineering Weekly* series — a deep-dive every Monday into the frameworks,
patterns, and techniques shaping the next generation of AI systems.*

Follow the Agentic Engineering Weekly series on Dev.to to catch every edition.

Building something agentic? Drop a comment — I'd love to feature reader projects.

AI Weekly: Intel-Google CPU Alliance, Meta's Proprietary Pivot, and the $7 Trillion Infrastructure Reality Check

Richard Dillon — Mon, 13 Apr 2026 12:04:55 +0000

AI Weekly: Intel-Google CPU Alliance, Meta's Proprietary Pivot, and the $7 Trillion Infrastructure Reality Check

The battle lines in AI infrastructure are being redrawn this week. As GPU costs and power demands reach breaking points, we're seeing major players hedge their bets—Intel and Google doubling down on CPU-based inference, Big Tech signing nuclear power deals, and Meta surprising everyone by abandoning its open-source commitment for a proprietary model that crushes the competition. Meanwhile, Chinese AI continues its relentless advance with Zhipu AI's massive new open-source release.

Intel and Google Forge Expanded Partnership to Double Down on AI-Optimized CPUs

Intel and Google announced an expanded partnership on April 9, 2026, signaling a significant strategic bet that CPU-based AI inference can offer a viable alternative to the GPU-dominated landscape that NVIDIA currently controls.

The partnership focuses on developing AI-optimized CPU architectures specifically designed for inference workloads—the computationally intensive task of running trained models in production. While GPUs have dominated AI training and increasingly inference, the collaboration suggests both companies see an opportunity in the growing cost pressures facing enterprise AI deployments.

The timing is notable. Data center operators are grappling with skyrocketing power consumption and GPU procurement costs that have become untenable for many organizations. CPUs, while historically slower for AI workloads, offer advantages in power efficiency, existing infrastructure compatibility, and procurement flexibility that enterprise customers increasingly value.

For Intel, the partnership represents a lifeline in the AI hardware race where the company has struggled to compete with NVIDIA's dominance. For Google, which operates one of the world's largest inference infrastructures for services like Search and Gemini, diversifying beyond GPUs and its own TPUs makes strategic sense as AI becomes core to every product.

The real question is whether optimized CPU inference can close the performance gap enough to matter for latency-sensitive applications—or whether this remains primarily a cost optimization play for batch workloads.

Big Tech Pours Billions into Next-Gen Nuclear as AI Power Demands Explode

The AI infrastructure buildout has collided head-on with physical reality: these systems need staggering amounts of electricity, and the tech industry is now putting financial heft behind next-gen nuclear power to secure it.

Meta, xAI, and other hyperscalers are now targeting data center deployments requiring a combined 110 GW of power—roughly equivalent to the entire electricity consumption of Germany. NVIDIA CEO Jensen Huang has publicly estimated that each major AI infrastructure buildout requires a minimum $60 billion investment, a figure that doesn't even account for the long-term power generation infrastructure needed to sustain operations.

Startups like Oklo are capitalizing on this demand, securing long-term power purchase agreements with tech customers desperate for clean, reliable baseload power. The attraction of nuclear is clear: unlike solar and wind, it provides consistent output regardless of weather, and next-generation small modular reactor designs promise faster deployment timelines than traditional nuclear plants.

But the numbers remain daunting. As Reuters analysis notes, AI infrastructure ambitions are crashing into a $7 trillion reality check when accounting for sustainable power solutions. The gap between AI's appetite for compute and the planet's ability to power it sustainably is arguably the defining constraint of this technology era—one that neither algorithmic efficiency gains nor hardware improvements alone can solve.

Meta Breaks from Open-Source Playbook with Proprietary Muse Spark Model

In a move that caught the AI community off guard, Meta launched Muse Spark, its first proprietary model since the company committed to its open-weight Llama strategy. The shift represents a significant philosophical reversal for a company that had positioned open-source AI as a competitive moat against OpenAI and Google.

The performance justification is substantial. Muse Spark achieved an Artificial Analysis Intelligence Index score of 52, nearly tripling the 18 scored by Llama 4 Maverick. On the CharXiv Reasoning benchmark, Muse Spark posted an 86.4, outperforming both Claude Opus 4.6's 65.3 and GPT-5.4's 82.8. These aren't incremental improvements—they suggest Meta has been holding back capabilities in its public releases.

The timing provides context for the decision. Chinese models from Alibaba and DeepSeek now account for 41% of downloads on Hugging Face, effectively commoditizing the open-weights space that Meta pioneered. When your open-source strategy mainly benefits competitors with lower labor costs and fewer regulatory constraints, the calculus changes.

The community reaction has been mixed. Some view this as a betrayal of Meta's open-source commitments; others see it as inevitable market maturation. What's undeniable is that Meta can no longer credibly position itself as the champion of AI democratization—and that the open-source vs. proprietary debate in AI is far more nuanced than partisans on either side admit.

Zhipu AI's GLM-5.1 Sets New Open-Source Benchmark with 754B Parameters

Chinese AI lab Zhipu AI released GLM-5.1, a 754 billion parameter model that establishes new benchmarks for open-source AI capabilities. The model includes a 202,752 token context window—large enough to process substantial codebases or document collections in a single pass.

The benchmark results are striking. GLM-5.1 achieved 95.3 on AIME 2026, a rigorous mathematics assessment, and 68.7 on CyberGym, a cybersecurity evaluation spanning 1,507 tasks. Perhaps most impressively, the model passed what Zhipu calls "Scenario 3"—building a functional Linux-style desktop environment from scratch within an 8-hour timeframe, demonstrating sustained agentic capability over extended task horizons.

For practitioners, the deployment story matters as much as the benchmarks. GLM-5.1 is available for local deployment via vLLM, SGLang, and xLLM frameworks, meaning organizations with sufficient hardware can run frontier-class capabilities entirely on-premises. This addresses data sovereignty and cost concerns that limit enterprise adoption of API-based models.

The release comes as Zhipu AI IPO'd at a $52.83 billion valuation, reflecting investor confidence in Chinese AI development. For Western AI labs, GLM-5.1 represents yet another data point in an uncomfortable trend: the open-source lead they once held has definitively shifted east, with implications for talent flows, regulatory frameworks, and the geopolitics of AI development.

Stalking Victim's Lawsuit Against OpenAI Raises New Questions About AI Safety Guardrails

A lawsuit filed against OpenAI by a stalking victim presents one of the most concrete tests yet of AI company liability when their products facilitate real-world harm. The victim claims ChatGPT fueled her abuser's delusional fixation and that the company ignored her direct warnings about the situation.

The case highlights the gap between AI safety commitments—the red-teaming, the RLHF, the constitutional AI principles—and the actual mechanisms available to prevent harm when someone reports ongoing abuse. What processes exist for a victim to flag that an AI system is being weaponized against them? How do AI companies triage such reports against the millions of support tickets they receive? The lawsuit suggests these systems are either inadequate or non-existent.

From a legal perspective, the case could establish precedent for when AI companies become liable for foreseeable misuse. Section 230 protections that shield platforms from user-generated content may not apply when a company has specific knowledge of harmful use and fails to act. The plaintiff's direct warnings to OpenAI—if documented—could prove pivotal.

For AI companies, this lawsuit should prompt immediate review of their harm reporting mechanisms. The abstract safety research that dominates AI ethics discussions matters less than whether a stalking victim can effectively communicate that your product is being used to terrorize her—and whether anyone at your company is empowered to act on that information.

Agentic Programming Updates

The theoretical foundations of agentic AI are rapidly solidifying into production-ready architectures. A comprehensive arXiv paper now formalizes the evolution toward orchestrated multi-agent systems, proposing a reference architecture that cleanly separates cognitive reasoning, hierarchical memory, typed tool invocation, and embedded governance layers.

Multi-agent coordination patterns have reached standardization maturity. Analysis of frameworks including CAMEL, AutoGen, MetaGPT, LangGraph, Swarm, and MAKER reveals four dominant patterns: chain (sequential), star (hub-and-spoke), mesh (peer-to-peer), and explicit workflow graphs. The 2026 Agentic Coding Trends guide provides implementation details for each, noting that production deployments increasingly favor DAG-based task graphs with content-addressed artifacts for agent collaboration and audit trails.

On the tooling front, AWS Bedrock AgentCore has emerged as the enterprise-grade option, offering managed infrastructure for agent deployment at scale. CrewAI and LangGraph continue gaining traction for teams preferring role-based agent orchestration with more granular control. OpenAI's Agents SDK (available in Python and TypeScript) has evolved to become provider-agnostic, with documented paths for integrating non-OpenAI models—a notable concession to the multi-model reality of production systems.

Research into agentic AI governance frameworks is accelerating, with particular focus on audit mechanisms for autonomous decision chains and liability attribution when agents operate across organizational boundaries.

OpenAI Opens First Permanent London Office Amid UK Expansion Push

OpenAI's decision to establish a permanent London office marks meaningful expansion beyond its San Francisco headquarters and signals serious intent in the European market. The move comes as UK enterprise demand for ChatGPT and API services has grown substantially, driven by financial services, healthcare, and government adoption.

The timing coincides with ongoing regulatory uncertainty in the US market under the Trump administration, making geographic diversification strategically prudent. London offers access to European AI talent—particularly from universities like Imperial, Oxford, and Cambridge—without the regulatory complexity of establishing operations in EU member states post-Brexit.

For UK enterprise customers, a local presence should mean faster sales cycles, easier procurement processes, and the relationship-building that remains essential for high-value B2B deals. It also positions OpenAI for potential UK government contracts that often require local presence or data residency.

The office joins an increasingly competitive London AI scene that includes Google DeepMind's headquarters, Anthropic's growing European team, and numerous well-funded startups. Whether this creates a talent war that benefits workers or simply redistributes the same limited pool of experienced AI engineers remains to be seen.

Anthropic Temporarily Bans OpenClaw Creator from Claude Access

In an incident that underscores ongoing tensions between AI companies and the developer ecosystem building on their platforms, Anthropic temporarily blocked the creator of OpenClaw from accessing Claude. OpenClaw is a tool that programmatically interfaces with Claude's capabilities.

The ban highlights the unclear boundaries of acceptable use for API customers. AI companies want developers building applications on their platforms—it's a significant revenue and ecosystem play—but grow concerned when those applications automate access in ways that stress infrastructure or circumvent rate limits. The challenge is that the line between "creative developer" and "problematic automation" often depends on scale and intent rather than technical implementation.

This follows a broader pattern of AI companies tightening controls on programmatic access and wrapper applications. OpenAI has similarly cracked down on projects it views as competitive or abusive, creating uncertainty for developers investing in AI-dependent products.

For the developer community, these incidents raise legitimate concerns about platform risk. Building a business on AI APIs means accepting that your access can be revoked with limited recourse or explanation. The OpenClaw creator's ban was temporary, but the precedent matters—and suggests developers should maintain fallback options across multiple providers wherever possible.

What to Watch

The Intel-Google partnership will face its first real test when benchmark results for AI-optimized CPU inference emerge—expect performance comparisons against NVIDIA's latest within the quarter. The nuclear power agreements signal a 3-5 year buildout cycle that will determine whether AI scaling continues or hits hard physical limits. And Meta's proprietary pivot suggests the next Llama release may be significantly more restrictive, potentially fragmenting the open-source AI community that coalesced around previous versions.

Sources

- OpenAI for Developers in 2025

Enjoyed this briefing? Follow this series for a fresh AI update every week, written for engineers who want to stay ahead.

Follow this publication on Dev.to to get notified of every new article.

Have a story tip or correction? Drop a comment below.

NVIDIA-Accelerated LangGraph — Parallel and Speculative Execution for Production Agents

Richard Dillon — Mon, 06 Apr 2026 12:03:13 +0000

NVIDIA-Accelerated LangGraph — Parallel and Speculative Execution for Production Agents

Your multi-step research agent takes 12 seconds to respond. Users are bouncing. You've optimized prompts, cached embeddings, and upgraded to faster models—yet the fundamental problem remains: sequential LLM calls compound latency in ways that no single-node optimization can fix. The LangChain-NVIDIA enterprise partnership announced in March 2026 addresses this head-on with compile-time execution strategies that analyze your graph structure and automatically parallelize independent operations. This isn't about writing faster code—it's about declaring your intent and letting the compiler find the optimal execution path.

The Latency Problem in Multi-Step Agent Workflows

Production agent systems rarely accomplish meaningful work with a single LLM call. A typical research agent might search the web, retrieve relevant documents, synthesize findings, evaluate completeness, and either iterate or produce a final answer. Each node in this workflow adds 500ms to 2 seconds of latency, depending on model size, context length, and inference provider. A five-node graph with one conditional loop easily hits 8-15 seconds—an eternity for interactive applications.

The frustrating reality is that many of these operations could run simultaneously. Your web search doesn't depend on your document retrieval. Your conditional branches represent alternative futures that could both be computed before you know which path is correct. Yet traditional LangGraph execution respects the topological ordering of your graph, running nodes one after another even when the dependency structure allows parallelism.

You might reach for asyncio.gather() to manually parallelize, but this creates its own problems. State management becomes your responsibility. Reducer conflicts when parallel nodes write to the same state key need explicit handling. Rollback semantics for failed branches require careful coordination. The evolution of agentic AI architectures has highlighted that these orchestration concerns consume significant engineering effort that should instead go toward domain logic.

The langchain-nvidia package addresses this systematically. Rather than requiring you to restructure your graph or manually manage concurrency, it analyzes your StateGraph at compile time and produces an optimized execution plan. The promise: 40-60% latency reduction on complex graphs without touching your node logic or edge definitions.

How the NVIDIA Execution Strategies Work Under the Hood

When you compile a StateGraph with NVIDIA execution strategies enabled, the compiler performs a static analysis pass that builds a dependency DAG from your node and edge definitions. This analysis identifies which nodes read which state keys, which nodes write to which keys, and which edges create hard sequencing requirements.

Parallel execution batches nodes that have no data dependencies between them. If your search_web node only reads query and writes search_results, while your retrieve_documents node reads query and writes retrieved_docs, these can execute concurrently—they touch disjoint portions of state. The compiler emits an execution plan that groups such nodes into parallel batches, using either asyncio coroutines or thread pools depending on your nodes' implementation.

Speculative execution goes further by running both branches of conditional edges before the routing function resolves. Consider a conditional edge that routes to either continue_research or generate_answer based on a quality check. Traditionally, you'd wait for the quality check, then invoke the selected branch. With speculation, both branches begin executing immediately. Once the routing function returns, the "wrong" branch is terminated and its state changes discarded.

This differs fundamentally from naive asyncio.gather() parallelization. The NVIDIA optimizer handles state merging automatically, applying reducers in dependency order even when writes arrive out of sequence. For speculative branches, it maintains state snapshots that can be rolled back without corrupting your primary state. Failed branches don't leave partial state mutations behind.

Memory overhead is the primary trade-off. Speculative branches duplicate the entire state snapshot at branch entry. For graphs with large state objects—say, a messages list containing hundreds of conversation turns—this duplication can be expensive. The compiler provides heuristics, but you may need to annotate branches where speculation isn't worth the memory cost.

For full GPU acceleration, the optimizer integrates with NVIDIA NIM microservices to batch inference requests from parallel nodes. If you're running Nemotron models through NIM, multiple parallel LLM calls can be batched into a single GPU kernel launch, further reducing overhead. This is where the really dramatic speedups come from—not just concurrent execution, but fused inference at the hardware level.

Enabling NVIDIA Optimizations in Your Existing LangGraph

Getting started requires installing the langchain-nvidia package alongside your existing LangGraph setup:

pip install langchain-nvidia>=0.2.0 langgraph>=0.3.0

If you're targeting full GPU acceleration (not just CPU-based parallelism), you'll also need CUDA 12.x and the NIM client libraries. For CPU-only environments, the optimizer falls back to thread pool parallelism—slower than GPU batching but still significantly faster than sequential execution.

The integration surfaces through new keyword arguments on the compile() method:

from langgraph.graph import StateGraph
from langchain_nvidia import NVIDIAExecutionStrategy

# Your existing graph definition
graph = StateGraph(AgentState)
graph.add_node("search", search_node)
graph.add_node("retrieve", retrieve_node)
graph.add_node("synthesize", synthesize_node)
graph.add_conditional_edges("synthesize", should_continue, {...})

# Compile with NVIDIA optimizations
compiled = graph.compile(
    execution_strategy=NVIDIAExecutionStrategy.PARALLEL,
    speculative_branches=True,
    speculation_depth=2  # Max nested speculation levels
)

The compiler's auto-detection works well for most graphs, but sometimes state dependencies are implicit or dynamic. You can hint parallelizability with the @independent decorator:

from langchain_nvidia import independent

@independent(reads=["query"], writes=["search_results"])
async def search_node(state: AgentState) -> dict:
    # Explicitly declares state access pattern
    results = await search_api(state["query"])
    return {"search_results": results}

For conditional edges where one branch has side effects—database writes, external API calls with rate limits, or any non-idempotent operation—you can opt out of speculation per-edge:

graph.add_conditional_edges(
    "quality_check",
    route_function,
    {
        "continue": "research_more",
        "complete": "write_to_database"  # Has side effects
    },
    speculative={"continue": True, "complete": False}
)

Debugging the execution plan is crucial for understanding what the optimizer actually produces. The explain_execution_plan() method prints a human-readable DAG with timing estimates:

plan = compiled.explain_execution_plan()
print(plan)
# Output:
# Batch 1 (parallel): [search_node, retrieve_node] ~800ms
# Batch 2 (sequential): [synthesize_node] ~1200ms
# Conditional (speculative): [research_more | final_answer] ~600ms (one discarded)
# Estimated total: 2600ms (vs 4800ms sequential)

One critical gotcha: speculative execution and LangGraph's interrupt() mechanism don't mix. If a node might raise an interrupt to request human input, that node and all nodes depending on its output must execute sequentially. The compiler enforces this, emitting a warning when it detects potential conflicts.

Hands-On: Code Walkthrough

Let's build a multi-tool research agent that demonstrates both parallel and speculative execution. This agent searches the web, retrieves documents from a vector store, synthesizes findings, and conditionally loops back for more research or produces a final answer.

"""
Research Agent with NVIDIA-Optimized Execution
Demonstrates parallel node batching and speculative conditional execution
"""

from typing import TypedDict, Literal, Annotated
from operator import add
import asyncio
import time

from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.memory import MemorySaver
from langchain_nvidia import NVIDIAExecutionStrategy, independent
from langchain_anthropic import ChatAnthropic
from langchain_community.tools import TavilySearchResults
from langchain_core.documents import Document


# Define agent state with explicit reducers for parallel safety
class ResearchState(TypedDict):
    query: str
    search_results: Annotated[list[str], add]  # Reducer handles parallel writes
    retrieved_docs: Annotated[list[Document], add]
    synthesis: str
    iteration_count: int
    final_answer: str


# Initialize components
llm = ChatAnthropic(model="claude-sonnet-4-20250514", temperature=0)
search_tool = TavilySearchResults(max_results=5)


# Node 1: Web Search (parallelizable with document retrieval)
@independent(reads=["query"], writes=["search_results"])
async def search_web(state: ResearchState) -> dict:
    """
    Searches the web for relevant information.
    Marked @independent because it only reads 'query' and writes 'search_results',
    allowing parallel execution with other nodes that don't touch these keys.
    """
    results = await search_tool.ainvoke(state["query"])
    # Extract content strings from search results
    content = [r["content"] for r in results if "content" in r]
    return {"search_results": content}


# Node 2: Document Retrieval (parallelizable with web search)
@independent(reads=["query"], writes=["retrieved_docs"])
async def retrieve_documents(state: ResearchState) -> dict:
    """
    Retrieves relevant documents from vector store.
    Runs in parallel with search_web since they access disjoint state keys.
    In production, this would query Pinecone/Chroma/etc.
    """
    # Simulated retrieval - replace with actual vector store call
    await asyncio.sleep(0.5)  # Simulate retrieval latency
    docs = [
        Document(page_content=f"Retrieved context for: {state['query']}", 
                 metadata={"source": "vector_store"})
    ]
    return {"retrieved_docs": docs}


# Node 3: Synthesis (depends on search_results and retrieved_docs)
async def synthesize_findings(state: ResearchState) -> dict:
    """
    Synthesizes all gathered information into a coherent summary.
    Must run after parallel nodes complete since it reads their outputs.
    """
    # Combine all sources
    all_context = "\n".join(state["search_results"])
    doc_context = "\n".join([d.page_content for d in state["retrieved_docs"]])

    prompt = f"""Based on the following research for query "{state['query']}":

Web Search Results:
{all_context}

Retrieved Documents:
{doc_context}

Provide a synthesis of the key findings. Note any gaps that require further research."""

    response = await llm.ainvoke(prompt)
    return {
        "synthesis": response.content,
        "iteration_count": state.get("iteration_count", 0) + 1
    }


# Node 4: Continue Research (speculative branch - may be discarded)
async def continue_research(state: ResearchState) -> dict:
    """
    Generates a refined query for additional research.
    This node runs speculatively alongside generate_answer.
    If routing selects generate_answer, this branch is discarded.
    """
    prompt = f"""The current synthesis has gaps: {state['synthesis']}

Generate a refined search query to fill these gaps."""

    response = await llm.ainvoke(prompt)
    return {"query": response.content}  # Updates query for next iteration


# Node 5: Generate Final Answer (speculative branch - may be discarded)
async def generate_answer(state: ResearchState) -> dict:
    """
    Produces the final answer from synthesized research.
    Runs speculatively - discarded if routing continues research instead.
    """
    prompt = f"""Based on this research synthesis:
{state['synthesis']}

Provide a comprehensive final answer to: {state['query']}"""

    response = await llm.ainvoke(prompt)
    return {"final_answer": response.content}


# Routing function for conditional edge
def should_continue(state: ResearchState) -> Literal["continue", "complete"]:
    """
    Determines whether research is sufficient or needs another iteration.
    Both branches execute speculatively before this function returns.
    """
    # Simple heuristic: max 3 iterations, or check synthesis quality
    if state["iteration_count"] >= 3:
        return "complete"

    # In production, use LLM to evaluate synthesis completeness
    if "further research" in state["synthesis"].lower():
        return "continue"
    return "complete"


# Build the graph
def build_research_graph():
    graph = StateGraph(ResearchState)

    # Add nodes
    graph.add_node("search_web", search_web)
    graph.add_node("retrieve_docs", retrieve_documents)
    graph.add_node("synthesize", synthesize_findings)
    graph.add_node("continue_research", continue_research)
    graph.add_node("generate_answer", generate_answer)

    # Add edges - search and retrieve can run in parallel
    graph.add_edge(START, "search_web")
    graph.add_edge(START, "retrieve_docs")  # Both start from START = parallel

    # Both must complete before synthesis
    graph.add_edge("search_web", "synthesize")
    graph.add_edge("retrieve_docs", "synthesize")

    # Conditional edge with speculative execution
    graph.add_conditional_edges(
        "synthesize",
        should_continue,
        {
            "continue": "continue_research",
            "complete": "generate_answer"
        }
    )

    # Loop back or end
    graph.add_edge("continue_research", "search_web")
    graph.add_edge("generate_answer", END)

    return graph


# Compile with NVIDIA optimizations
graph = build_research_graph()

# Baseline compilation (sequential execution)
baseline_compiled = graph.compile(checkpointer=MemorySaver())

# Optimized compilation with parallel + speculative execution
optimized_compiled = graph.compile(
    checkpointer=MemorySaver(),
    execution_strategy=NVIDIAExecutionStrategy.PARALLEL,
    speculative_branches=True,
    speculation_depth=2
)


# Benchmarking harness
async def benchmark(compiled_graph, label: str, runs: int = 50):
    """Measures end-to-end latency across multiple runs."""
    latencies = []

    for i in range(runs):
        start = time.perf_counter()
        config = {"configurable": {"thread_id": f"{label}-{i}"}}

        result = await compiled_graph.ainvoke(
            {"query": "What are the latest advances in quantum computing?",
             "search_results": [],
             "retrieved_docs": [],
             "iteration_count": 0},
            config
        )

        elapsed = time.perf_counter() - start
        latencies.append(elapsed)

    avg = sum(latencies) / len(latencies)
    p50 = sorted(latencies)[len(latencies) // 2]
    p95 = sorted(latencies)[int(len(latencies) * 0.95)]

    print(f"{label}: avg={avg:.2f}s, p50={p50:.2f}s, p95={p95:.2f}s")
    return latencies


# Run comparison
async def main():
    # Print execution plan for optimized graph
    print("=== Optimized Execution Plan ===")
    print(optimized_compiled.explain_execution_plan())
    print()

    # Run benchmarks
    print("=== Benchmark Results (50 runs each) ===")
    baseline_latencies = await benchmark(baseline_compiled, "Baseline")
    optimized_latencies = await benchmark(optimized_compiled, "Optimized")

    # Calculate improvement
    baseline_avg = sum(baseline_latencies) / len(baseline_latencies)
    optimized_avg = sum(optimized_latencies) / len(optimized_latencies)
    improvement = (baseline_avg - optimized_avg) / baseline_avg * 100

    print(f"\nLatency reduction: {improvement:.1f}%")


if __name__ == "__main__":
    asyncio.run(main())

When you run this benchmark, you'll see the execution plan clearly showing how search_web and retrieve_docs batch together in a parallel group, followed by synthesize, then the speculative conditional where both continue_research and generate_answer start simultaneously. In LangSmith traces, the parallel batch appears as overlapping spans rather than sequential blocks—a visual confirmation that optimization is working.

Expected results on this 4-node graph with one conditional branch: approximately 45% latency reduction compared to baseline sequential execution. The exact improvement depends on your inference provider's concurrency support and network conditions.

When to Use (and When to Avoid) Speculative Execution

Speculative execution is powerful but not free. Every speculative branch consumes compute resources—tokens, GPU cycles, API calls—for work that may be discarded. Understanding when speculation pays off is critical for production deployments.

Ideal scenarios for speculation:

Read-only branches perform well because discarding them has no lasting effects. A branch that only runs inference and updates local state can be safely abandoned mid-execution. Similarly, idempotent operations—where running twice produces the same result as running once—are safe to speculate because even if partial work persists, it doesn't corrupt your system.

Low-cost nodes are obvious candidates. If both branches of a conditional complete in under 500ms, speculating costs you at most 500ms of parallel compute. When routing takes 200ms to resolve, you've paid a small premium for potentially significant latency reduction.

Cached or pre-computed results make speculation nearly free. If one branch just reads from a cache while the other runs full inference, speculating on the cached branch adds negligible overhead.

Scenarios where speculation hurts:

External writes are the biggest red flag. A branch that writes to a database, sends an email, or calls a billing API should never run speculatively. Even if you "discard" the branch result, the side effect has already occurred. The framework can't undo your Stripe charge.

API rate limits compound the problem. If you're calling a third-party API with per-minute quotas, speculative branches double your request rate on conditional paths. During the agentic AI architecture evolution, practitioners have learned that rate limit exhaustion often manifests as cascading failures rather than graceful degradation.

Vastly asymmetric branch costs make speculation inefficient. If one branch takes 200ms and the other takes 5 seconds, speculating on the expensive branch when the cheap branch would have been selected wastes 5 seconds of compute. The framework can't predict routing outcomes, so it speculates on both.

Cost analysis template:

# ROI calculation for speculative execution on a conditional edge
cheap_branch_cost_tokens = 500
expensive_branch_cost_tokens = 3000
routing_probability_cheap = 0.7  # 70% of traffic takes cheap branch
routing_probability_expensive = 0.3

# Without speculation: expected tokens per request
baseline_expected_tokens = (
    cheap_branch_cost_tokens * routing_probability_cheap +
    expensive_branch_cost_tokens * routing_probability_expensive
)
# = 500 * 0.7 + 3000 * 0.3 = 350 + 900 = 1250 tokens

# With speculation: always pay for both branches
speculative_tokens = cheap_branch_cost_tokens + expensive_branch_cost_tokens
# = 500 + 3000 = 3500 tokens

# Speculation costs 2.8x more tokens
# Only worth it if latency reduction value exceeds 2.8x token cost increase

Hybrid approaches work best. Mark expensive or side-effect-producing branches as non-speculative while allowing cheap, read-only branches to speculate freely. The per-edge speculative parameter gives you this granularity.

One subtle interaction: LangGraph's checkpointing mechanism doesn't persist speculative branch state until routing resolves. This is usually what you want—failed speculation shouldn't pollute your checkpoint history. However, it means you can't resume from a mid-speculation checkpoint if the process crashes. For long-running agents where crash recovery matters, consider whether speculation's latency benefits outweigh the recovery complexity.

What This Means for Your Stack

The NVIDIA execution optimization represents a philosophical shift in how we build agent systems. Instead of meticulously hand-tuning async boundaries and managing concurrent state, you declare your node dependencies and let the compiler find parallelism. This is the same trajectory that took SQL from procedural cursor loops to declarative queries optimized by the database engine.

Immediate wins for existing deployments:

If you have production LangGraph agents today, you can often get meaningful speedups without any refactoring. Install langchain-nvidia, add the execution strategy flags to your compile() call, and run explain_execution_plan() to see what the optimizer finds. Many real-world graphs have latent parallelism—nodes that happen to be defined sequentially but don't actually depend on each other's outputs.

Kensho's multi-agent framework is a good case study here. Their financial research agents had multiple data-gathering nodes that were functionally independent but executed sequentially due to how the graph was originally authored. Adding parallel execution dropped their median latency by 38% with zero changes to node implementations.

Deployment considerations:

Full GPU acceleration requires NVIDIA NIM microservices running somewhere your agents can reach them—either self-hosted on GPU instances or via NVIDIA's cloud offerings. This adds infrastructure complexity but enables inference batching that further compounds the parallel execution benefits.

For teams not ready to operate NIM infrastructure, CPU-only fallback still provides parallel execution via thread pools. You lose the GPU batching speedups but retain the concurrent node execution benefits. This is a reasonable starting point for evaluation.

Cost-benefit for cloud deployments:

Parallel execution increases your instantaneous compute footprint. Instead of one inference call at a time, you might have three or four. On cloud GPU instances priced by the hour, this doesn't increase cost—you're already paying for the GPU. On API-based providers priced per token, parallel execution is cost-neutral (same tokens, just concurrent). Speculative execution, however, genuinely increases token spend on conditional paths.

Run the numbers for your specific traffic patterns. A 45% latency reduction might justify a 20% increase in token costs for latency-sensitive applications. For batch processing where latency doesn't matter, speculation may not make sense.

Migration path:

Start with parallel execution only (speculative_branches=False). This is nearly always safe and provides immediate benefits. Monitor your LangSmith traces for the parallel execution patterns, validate that state merging works correctly for your reducers, and measure the actual latency improvement.

Once comfortable, enable speculative execution on specific conditional edges where both branches are cheap and side-effect-free. Use the per-edge speculative parameter rather than the global flag. This incremental approach lets you learn where speculation helps in your specific workloads.

New observability metrics:

LangSmith's integration with the NVIDIA execution strategies surfaces two new metrics worth monitoring:

Speculative waste ratio: Percentage of speculative branch compute that gets discarded. High values (>50%) suggest your speculation targets are poorly chosen.
Parallel efficiency score: Ratio of achieved parallelism to theoretical maximum. Low values indicate state dependencies you might be able to refactor away.

Looking ahead, the LangChain roadmap hints at auto-tuning capabilities that learn optimal speculation targets from production traces. The vision: your agent framework observes which branches win routing decisions, estimates branch costs, and automatically adjusts speculation settings to minimize expected latency given observed traffic patterns.

What to Build This Week

Project: Latency-Optimized Customer Support Agent

Build a customer support agent that handles incoming tickets by: (1) classifying the ticket category, (2) searching knowledge base documentation, (3) retrieving similar past tickets, and (4) either generating a draft response or escalating to a human—with the escalation/response decision made via conditional routing.

Implementation steps:

Define a StateGraph with four main nodes plus the conditional branch
Annotate the knowledge base search and past ticket retrieval nodes as @independent—they read the same input but write to different state keys
Mark the "escalate to human" branch as speculative=False since escalation triggers external notifications
Allow the "draft response" branch to speculate since it's a pure LLM call
Implement explain_execution_plan() logging to verify optimization
Build a test harness that submits 100 tickets and compares baseline vs. optimized latency distributions
Calculate your actual ROI: latency reduction vs. token cost increase from speculation

Target metrics: 35-50% latency reduction on the happy path (response generation), with escalation paths unaffected by speculation. If your support tickets have 80/20 response/escalation ratio, speculation should have positive ROI even with some wasted compute on the 20% that escalates.

This project directly applies to production use cases and gives you hands-on experience with the optimization trade-offs before deploying to real traffic.

Sources

- The Evolution of Agentic AI Software Architecture

This is part of the **Agentic Engineering Weekly* series — a deep-dive every Monday into the frameworks,
patterns, and techniques shaping the next generation of AI systems.*

Follow the Agentic Engineering Weekly series on Dev.to to catch every edition.

Building something agentic? Drop a comment — I'd love to feature reader projects.

Primitive Shifts: The Async Task Primitive

Richard Dillon — Mon, 06 Apr 2026 12:02:23 +0000

Primitive Shifts: The Async Task Primitive

Every few months, the baseline of how AI systems work quietly moves. Engineers who noticed early weren't smarter — they were just paying attention to the right signals. The engineers who saw containerization coming didn't predict Docker's dominance; they noticed deployment friction patterns that VMs couldn't solve. The ones who caught the serverless shift weren't visionaries; they were tired of capacity planning for bursty workloads. Right now, the same kind of quiet shift is happening in agent orchestration — and if you're still building synchronous agent calls, you're about to feel the floor move.

What Is It?

The shift is from synchronous agent invocations — where you call an agent, block, and wait for a response — to task-based asynchronous primitives with first-class status tracking, timeout budgets, and structured resumption. The core pattern: agent calls return a task identifier immediately, the client polls or subscribes for status updates, and the agent can run for minutes to hours without blocking the caller.

This isn't just "background jobs for AI." The design patterns research for deploying AI agents describes protocol-level primitives that are emerging specifically for agent orchestration: task TTLs (typically 15 minutes for orphaned tasks), adaptive timeout budgeting that propagates through multi-agent hierarchies, and structured error semantics that go far beyond HTTP status codes. When a task fails, you don't just get a 500 — you get typed failures like budget_exhausted, upstream_unavailable, or partial_completion with resumable checkpoints.

AWS Bedrock AgentCore already ships this pattern in production. The MCP specification is converging toward what's being called the "tasks pattern" as the standard approach for non-trivial agent interactions. But the key insight is architectural: in multi-agent systems where planner agents invoke specialist agents, synchronous blocking is guaranteed to fail against planner timeout budgets. The planner has 10 minutes to coordinate five specialists. If any specialist blocks for 8 minutes, the planner can't aggregate results before its own deadline. The math doesn't work.

The agentic AI architecture research frames this as moving from "orchestration through blocking calls" to "orchestration through task lifecycle management." It's the difference between a conductor waiting for each musician to finish before cueing the next, versus a conductor who starts all sections and monitors their progress in parallel.

Why It's Flying Under the Radar

Most agent tutorials and demos still show synchronous patterns that work perfectly for 30-second completions. The canonical example — "build an agent that searches the web and summarizes results" — completes in under a minute. The tutorials work. The YouTube videos work. The blog posts work. And engineers reasonably conclude that their production systems should look like the tutorials.

But Anthropic's data on agent autonomy shows that Claude Code's 99th percentile turn durations have nearly doubled — from around 25 minutes to over 45 minutes — as the system handles increasingly complex tasks. The 2026 Agentic Coding Trends Report confirms this trajectory: as agents take on more autonomous work, session lengths stretch. The ceiling you're building against isn't the 45-second median; it's the 45-minute tail that's growing faster than most architectures can accommodate.

Engineers familiar with background job patterns — Celery, Sidekiq, Bull — assume they can retrofit existing infrastructure. But agent tasks need identity propagation (who initiated this multi-hop request?), context-scoped routing (which agent instance has the conversation state?), and structured continuation (how do we resume from a checkpoint with partial results?). Traditional job queues give you "run this function later." Agent tasks need "run this function later, as this user, with this context, reporting status to this callback, resuming from this state if interrupted, and inheriting this timeout budget."

The research on separation of execution power in AI systems describes this as a fundamental architectural distinction: agent tasks aren't background jobs with extra metadata — they're a different primitive with different lifecycle guarantees.

Hands-On: Try It Today

The simplest starting point is implementing the MCP tasks pattern in your existing agent infrastructure. Here's a minimal Python implementation showing the core primitives — task creation, status polling, timeout budgeting, and structured errors:

# task_primitives.py
# A minimal implementation of async task primitives for agent orchestration
# Requires: pip install pydantic>=2.0 fastapi uvicorn

from dataclasses import dataclass, field
from datetime import datetime, timedelta
from enum import Enum
from typing import Any, Optional
from uuid import uuid4
import asyncio
import time

class TaskStatus(Enum):
    PENDING = "pending"           # Created, not yet started
    RUNNING = "running"           # Currently executing
    COMPLETED = "completed"       # Finished successfully
    FAILED = "failed"            # Finished with error
    TIMEOUT = "timeout"          # Budget exhausted
    PARTIAL = "partial"          # Partial completion with checkpoint

class ErrorType(Enum):
    """Structured error types beyond generic failures"""
    BUDGET_EXHAUSTED = "budget_exhausted"      # Timeout budget depleted
    UPSTREAM_UNAVAILABLE = "upstream_unavailable"  # Dependency failed
    PARTIAL_COMPLETION = "partial_completion"  # Can resume from checkpoint
    CONTEXT_LOST = "context_lost"             # State invalidated

@dataclass
class TaskCheckpoint:
    """Resumable state for partial completions"""
    step_completed: int
    intermediate_results: dict[str, Any]
    remaining_work: list[str]
    created_at: datetime = field(default_factory=datetime.utcnow)

@dataclass 
class AgentTask:
    """Core task primitive with timeout budgeting"""
    task_id: str
    status: TaskStatus
    created_at: datetime
    timeout_budget_seconds: float  # Time remaining for this task
    parent_task_id: Optional[str] = None  # For hierarchical tracking
    checkpoint: Optional[TaskCheckpoint] = None
    result: Optional[Any] = None
    error_type: Optional[ErrorType] = None
    error_message: Optional[str] = None

    # TTL for orphaned task cleanup (default 15 minutes per MCP pattern)
    ttl_seconds: float = 900.0

    def remaining_budget(self) -> float:
        """Calculate remaining timeout budget"""
        elapsed = (datetime.utcnow() - self.created_at).total_seconds()
        return max(0, self.timeout_budget_seconds - elapsed)

    def child_budget(self, reserve_seconds: float = 30.0) -> float:
        """Budget to allocate to child tasks, reserving time for aggregation"""
        return max(0, self.remaining_budget() - reserve_seconds)

class TaskRegistry:
    """In-memory task store (use Redis/Postgres in production)"""

    def __init__(self):
        self._tasks: dict[str, AgentTask] = {}
        self._cleanup_task: Optional[asyncio.Task] = None

    def create_task(
        self, 
        timeout_budget_seconds: float,
        parent_task_id: Optional[str] = None
    ) -> AgentTask:
        """Create a new task and return immediately (fire-and-forget pattern)"""
        task = AgentTask(
            task_id=str(uuid4()),
            status=TaskStatus.PENDING,
            created_at=datetime.utcnow(),
            timeout_budget_seconds=timeout_budget_seconds,
            parent_task_id=parent_task_id
        )
        self._tasks[task.task_id] = task
        return task

    def get_task(self, task_id: str) -> Optional[AgentTask]:
        return self._tasks.get(task_id)

    def update_status(
        self, 
        task_id: str, 
        status: TaskStatus,
        result: Any = None,
        error_type: ErrorType = None,
        error_message: str = None,
        checkpoint: TaskCheckpoint = None
    ):
        """Update task status with structured error semantics"""
        if task := self._tasks.get(task_id):
            task.status = status
            task.result = result
            task.error_type = error_type
            task.error_message = error_message
            task.checkpoint = checkpoint

    async def cleanup_expired(self):
        """Remove orphaned tasks past TTL"""
        now = datetime.utcnow()
        expired = [
            tid for tid, task in self._tasks.items()
            if (now - task.created_at).total_seconds() > task.ttl_seconds
            and task.status in (TaskStatus.PENDING, TaskStatus.RUNNING)
        ]
        for tid in expired:
            # In production: log, emit metric, notify observers
            del self._tasks[tid]

# Example: Multi-agent orchestration with budget propagation
async def orchestrator_agent(
    registry: TaskRegistry,
    user_request: str,
    total_budget_seconds: float = 600.0  # 10 minutes
) -> str:
    """
    Orchestrator that spawns specialist agents with propagated budgets.
    Demonstrates the 'fire, track, resume' pattern.
    """
    # Create parent task immediately (fire)
    parent_task = registry.create_task(total_budget_seconds)
    registry.update_status(parent_task.task_id, TaskStatus.RUNNING)

    # Spawn child tasks with reduced budgets (propagate)
    child_budget = parent_task.child_budget(reserve_seconds=60.0)
    child_tasks = []

    for specialist in ["research", "analysis", "synthesis"]:
        child = registry.create_task(
            timeout_budget_seconds=child_budget / 3,  # Split among specialists
            parent_task_id=parent_task.task_id
        )
        child_tasks.append((specialist, child))
        # In production: dispatch to actual agent workers
        asyncio.create_task(
            simulate_specialist_work(registry, child, specialist)
        )

    # Poll for completion (track)
    while parent_task.remaining_budget() > 60.0:  # Reserve aggregation time
        all_done = all(
            registry.get_task(c.task_id).status 
            in (TaskStatus.COMPLETED, TaskStatus.FAILED, TaskStatus.PARTIAL)
            for _, c in child_tasks
        )
        if all_done:
            break
        await asyncio.sleep(1.0)  # Poll interval

    # Aggregate results or handle partial completion (resume)
    results = {}
    for specialist, child in child_tasks:
        child_state = registry.get_task(child.task_id)
        if child_state.status == TaskStatus.COMPLETED:
            results[specialist] = child_state.result
        elif child_state.status == TaskStatus.PARTIAL:
            # Use checkpoint for partial results
            results[specialist] = child_state.checkpoint.intermediate_results

    if len(results) == len(child_tasks):
        registry.update_status(
            parent_task.task_id, 
            TaskStatus.COMPLETED,
            result=f"Aggregated: {results}"
        )
    else:
        # Partial completion - save checkpoint for resumption
        registry.update_status(
            parent_task.task_id,
            TaskStatus.PARTIAL,
            error_type=ErrorType.PARTIAL_COMPLETION,
            checkpoint=TaskCheckpoint(
                step_completed=len(results),
                intermediate_results=results,
                remaining_work=[s for s, _ in child_tasks if s not in results]
            )
        )

    return parent_task.task_id

async def simulate_specialist_work(
    registry: TaskRegistry, 
    task: AgentTask, 
    specialist_type: str
):
    """Simulate specialist agent work with timeout awareness"""
    registry.update_status(task.task_id, TaskStatus.RUNNING)

    # Check budget before starting work
    if task.remaining_budget() < 5.0:
        registry.update_status(
            task.task_id,
            TaskStatus.FAILED,
            error_type=ErrorType.BUDGET_EXHAUSTED,
            error_message="Insufficient budget to start work"
        )
        return

    # Simulate work with periodic budget checks
    work_duration = min(task.remaining_budget() * 0.8, 30.0)
    start = time.time()

    while time.time() - start < work_duration:
        if task.remaining_budget() < 2.0:
            # Save checkpoint before timeout
            registry.update_status(
                task.task_id,
                TaskStatus.PARTIAL,
                error_type=ErrorType.PARTIAL_COMPLETION,
                checkpoint=TaskCheckpoint(
                    step_completed=1,
                    intermediate_results={"partial": f"{specialist_type} interim"},
                    remaining_work=["finalize"]
                )
            )
            return
        await asyncio.sleep(0.5)

    registry.update_status(
        task.task_id,
        TaskStatus.COMPLETED,
        result=f"{specialist_type} completed successfully"
    )

This implementation shows the three key shifts from synchronous patterns: immediate task ID return instead of blocking, explicit budget propagation to child tasks, and structured checkpoints for partial completions. The Context-Aware Broker Pattern described in deployment research extends this further with identity propagation and six-stage routing — but this foundation gets you 80% of the architectural benefit.

What This Means for Your Stack

Synchronous agent wrappers become technical debt. Every await agent.complete(prompt) in your codebase is a blocking call that assumes sub-minute responses. The empirical study of AI coding agents documents failure modes that emerge specifically when synchronous assumptions break — cascading timeouts, lost context, and silent failures that only surface in logs hours later. The investment in task primitives pays off immediately for any agent interaction that might exceed your HTTP timeout.

Observability requires task-native tracing. Traditional request traces end when the HTTP connection closes. The research on architecture documentation for AI systems emphasizes that agent observability must span the full task lifecycle — creation, status transitions, checkpoint saves, and eventual completion or resumption. Your existing Datadog or Jaeger setup will show a request that returned quickly with a task ID, then nothing until the client polls. The actual work happens in a tracing blind spot.

Multi-agent orchestration needs explicit budget propagation. Without passing remaining TTL to child agents, you get the scenario from our code example: a child agent consumes the entire timeout budget, and the parent fails to aggregate results before its own deadline. The multi-agent AI systems research shows this is the primary failure mode in hierarchical agent architectures — not model errors, but coordination timeouts.

Error handling shifts from "retry or fail" to "resume from checkpoint." The structured error semantics in the code — partial_completion with checkpoint state — reflect a fundamental change in how failures work. The growing burden of AI-assisted development notes that engineers spend increasing time recovering from partial completions rather than handling clean success/failure binaries.

The Infrastructure Signal

AWS Bedrock AgentCore shipping task patterns in production suggests AWS sees this as required infrastructure, not experimental nicety. When a major cloud provider builds timeout budgeting and structured resumption into their agent platform, they're responding to customer pain that's already widespread enough to justify platform investment.

The schema-guided dialogue systems research describes enterprise deployments requiring what they call "CABP-style identity propagation" — context-aware broker patterns that synchronous architectures simply cannot support. The identity of who initiated a request must flow through every task hop; orphaned tasks with sensitive context need explicit cleanup policies. This is table-stakes for enterprise compliance, and it requires task primitives.

The AI agents ecosystem shows a clear pattern: agent frameworks are increasingly separating "tooling and infrastructure" from core agent logic. Task lifecycle is becoming a layer — like logging or metrics — that you import rather than build. The institutional knowledge primitives research frames this as inevitable: as agent capabilities grow, the operational complexity concentrates in lifecycle management rather than inference.

Perhaps most telling: Anthropic's data shows the 99.9th percentile turn durations continue to climb as agents handle more complex autonomous work. Architectures built for minutes will hit hours. The question isn't whether you'll need task primitives — it's whether you'll adopt them proactively or reactively after a production incident.

Shift Rating

🟢 Adopt Now — Teams building multi-agent systems or expecting agent turn durations beyond 2-3 minutes should implement task primitives immediately. The synchronous patterns that work today will fail silently as capabilities expand — not with clean errors, but with timeout cascades that surface as missing data and confused users.

The refactoring cost grows with codebase size. Early adopters implement the pattern once in their agent abstraction layer. Late adopters retrofit dozens of call sites after production incidents reveal the architectural gap. The practical guide to agentic AI transition explicitly recommends treating task primitives as foundational infrastructure rather than optimization — not because current workloads require it, but because the ceiling is rising faster than codebases can reactively adapt.

If you're still synchronously awaiting agent completions, start with the highest-duration calls. Wrap them in task primitives this month. When the floor moves — and the data suggests it's moving soon — you'll already be standing on solid ground.

Sources

- Awesome AI Agents for 2026

This is part of **Primitive Shifts* — a monthly series tracking when new AI building blocks
move from novel experiments to infrastructure you'll be expected to know.*

Follow the Next MCP Watch series on Dev.to to catch every edition.

Spotted a shift happening in your stack? Drop it in the comments.

AI Weekly Roundup: Microsoft's Price War, Google's Open Model Push, and the Reliability Question Looming Over Enterprise AI

Richard Dillon — Mon, 06 Apr 2026 12:02:21 +0000

AI Weekly Roundup: Microsoft's Price War, Google's Open Model Push, and the Reliability Question Looming Over Enterprise AI

This week marks a pivotal moment in the AI landscape as the two largest cloud providers made aggressive moves to capture developer mindshare—Microsoft through aggressive pricing and Google by releasing its most capable open-weight models yet. But beneath the product announcements lies a more fundamental question gaining traction: can AI systems actually achieve the reliability that justifies the hundreds of billions being wagered on enterprise adoption?

Microsoft Unveils MAI Foundry Models to Challenge OpenAI and Google on Price

Microsoft's MAI Superintelligence team, led by Mustafa Suleyman, released three new foundational models this week designed to undercut competitors on inference costs while maintaining competitive performance. The models—MAI-1, MAI-2, and MAI-3—span a range of parameter counts optimized for different use cases, from lightweight edge deployment to full-scale reasoning tasks.

The release represents Microsoft's first major in-house foundation model push since acquiring Inflection AI talent in 2024. Suleyman's team developed the models under what they're calling a "Humanist AI" philosophy, emphasizing practical human-centered communication over raw benchmark performance. In practice, this translates to models that prioritize coherent multi-turn dialogue and task completion over flashy single-shot capabilities.

The key selling point is price: Microsoft claims MAI-2 delivers comparable performance to GPT-4-class models at roughly 40% lower inference costs, while MAI-3 targets the premium reasoning tier at prices significantly below OpenAI's o1 and Google's Gemini Ultra. The models are available immediately through Microsoft Foundry and will be integrated across Microsoft 365 Copilot, Azure AI services, and GitHub Copilot in coming weeks.

Whether these cost savings hold up under production workloads remains to be seen, but the pricing pressure on OpenAI—Microsoft's own portfolio company—signals just how fragmented the foundation model market has become.

Google Releases Gemma 4 as Most Capable Open Model Family

Google DeepMind announced Gemma 4, its first major update to the Gemma open model family in over a year, shipping four distinct model sizes targeting different deployment scenarios. The lineup includes E2B and E4B efficient variants for edge and mobile applications, a 26B Mixture-of-Experts model for cost-effective inference, and a 31B dense model positioned as the flagship for maximum capability.

All models ship under the Apache 2.0 license, making them fully permissive for commercial use—a notable contrast to Meta's Llama licensing restrictions. The 31B dense model in particular targets complex logic and agentic workflows, with Google claiming competitive performance against closed-source alternatives on multi-step reasoning benchmarks.

Perhaps most significant is the 1M token context window available across the model family, enabling document-scale processing without chunking. Early reports from the Hugging Face community, documented in their Spring 2026 State of Open Source report, suggest the 26B MoE variant delivers particularly strong results on agentic coding tasks while requiring substantially less compute than the dense model.

The timing positions Gemma 4 as a direct response to both Meta's Llama 4 release and the growing ecosystem of fine-tuned open models. For teams building production AI systems without deep pockets for API costs, this release significantly raises the bar for what's achievable with self-hosted inference.

Agentic Programming Updates

The multi-agent orchestration landscape continues to mature, with LangChain, AutoGen, and CrewAI maintaining their positions as the dominant frameworks for building complex agent systems. However, the past quarter has seen significant movement in the tooling layer as teams push agents from demos into production environments.

Several new frameworks have emerged addressing specific pain points: VoltAgent brings a TypeScript-first approach with self-improving context management, while PraisonAI focuses on production multi-agent deployments with native Model Context Protocol (MCP) integration. The MCP standard, now approaching its first anniversary, has become the de facto protocol for tool integration across the ecosystem.

Smolagents from Hugging Face continues gaining traction with its code-first philosophy where agents write and execute Python directly rather than emitting JSON tool calls. This approach trades some safety guarantees for dramatically improved flexibility in complex workflows.

On the MLOps side, ZenML's integration of "LangGraph swarms" into standard ML pipelines represents the ongoing convergence between traditional machine learning infrastructure and agentic systems. The industry is clearly shifting toward formalized inter-agent protocols and supervisor agent patterns, moving away from the ad-hoc agent chains that characterized early implementations.

Research from this quarter emphasizes that production-ready agent architectures require explicit failure handling, state persistence, and human-in-the-loop checkpoints—capabilities that separate serious frameworks from toy implementations.

Take-Two Shutters Internal AI Team as Gaming Industry Resets AI Strategy

Luke Dicken, Take-Two Interactive's head of AI, announced the dissolution of the company's internal AI team via LinkedIn this week, marking a notable retreat from the publisher's previous AI ambitions. Dicken previously served as senior director of applied AI at Zynga, the mobile gaming giant Take-Two acquired in 2022 for $12.7 billion.

The move signals a potential industry-wide recalibration in how major gaming companies approach AI development. Rather than maintaining dedicated AI research teams, publishers may be shifting toward licensing external AI services or integrating AI capabilities through middleware providers. This approach trades potential competitive advantages for reduced overhead and access to rapidly evolving third-party capabilities.

The dissolution contrasts sharply with continued heavy AI investment announcements from other sectors. While enterprise software companies race to embed AI into every product, gaming companies appear more cautious about where AI delivers genuine value versus hype-driven experimentation. NPCs powered by language models, procedural content generation, and AI-assisted development tools have all shown promise in demos but struggle to justify dedicated team costs at current capability levels.

German Publisher Sues OpenAI Over ChatGPT's Reproduction of Children's Book Series

A German publisher filed suit against OpenAI in Munich this week, alleging that ChatGPT violated copyright by generating content "virtually indistinguishable from the original" Coconut the Dragon children's book series. The case represents one of the most detailed copyright claims yet filed against a major AI provider in European courts.

According to the filing, ChatGPT not only reproduced narrative text closely matching the original books but also generated cover art, back cover marketing blurbs, and even instructions for self-publishing the generated content—essentially providing a turnkey system for producing unauthorized derivative works. The publisher's legal team documented dozens of prompts that reliably triggered near-verbatim reproduction of copyrighted material.

The lawsuit tests the boundaries of fair use doctrine under European copyright law, which generally provides narrower exceptions than U.S. law. OpenAI has previously argued that training on copyrighted material constitutes transformative use, but cases involving near-exact reproduction of specific works present a harder legal challenge than claims about training data in general.

The outcome could have significant implications for how AI companies handle clearly copyrighted creative works in training data and whether post-training mitigations against reproduction are legally sufficient.

Musk Reportedly Requiring SpaceX IPO Advisers to Purchase Grok Subscriptions

Banks, law firms, and auditors working on SpaceX's anticipated initial public offering have allegedly been told to purchase subscriptions to Grok, xAI's chatbot product, according to reporting from The New York Times. The requirement follows recent corporate restructuring that placed xAI's Grok product technically under SpaceX's corporate umbrella.

The arrangement raises immediate questions about conflicts of interest in major financial transactions. Advisory firms typically maintain strict independence from clients to preserve the integrity of their guidance, but mandatory product purchases create financial entanglement however small the individual subscription costs.

Beyond the ethics questions, the move underscores Musk's continued efforts to drive Grok adoption through unconventional channels. The chatbot has struggled to gain market share against ChatGPT and Claude despite significant infrastructure investment in xAI's Memphis supercomputer cluster. Requiring professional services firms to use the product at least ensures some enterprise exposure, even if adoption is coerced rather than organic.

SpaceX's IPO, if it proceeds, would be one of the largest technology offerings in years, making the advisory relationships particularly high-stakes for all parties involved.

Suno Faces Mounting Copyright Concerns as AI Music Generation Enables Streaming Fraud

Suno, the AI music generation platform, faces growing scrutiny as its technology enables increasingly sophisticated streaming fraud schemes. The platform's ability to generate music that closely mimics popular artists' styles has made it trivially easy to flood streaming services with AI-generated ripoffs designed to capture listener searches for established acts.

The problem extends beyond simple copyright infringement. Fraudsters use AI-generated tracks to execute streaming manipulation schemes, uploading thousands of songs that algorithmically target popular search terms and playlist categories. When listeners search for well-known artists or genres, AI-generated content increasingly appears alongside legitimate recordings, siphoning royalty payments from actual creators.

Streaming platforms have struggled to implement effective detection systems for AI-generated content. Unlike deepfakes of specific recordings, stylistic imitations exist in a legal gray zone—mimicking a musical style isn't clearly illegal, but doing so at industrial scale to deceive consumers raises different concerns.

The situation highlights regulatory gaps in AI-generated content authentication and growing calls for platform accountability. Some industry groups are pushing for mandatory labeling of AI-generated audio, while others advocate for streaming services to implement more aggressive content moderation. Neither approach has gained sufficient traction to address the problem at its current scale.

AI Business Model Reliability Under Scrutiny as Billions Ride on Enterprise Adoption

A Reuters analysis published this week poses an uncomfortable question for the AI industry: can these systems actually achieve the reliability needed for high-stakes enterprise work? With hundreds of billions of dollars in investment predicated on the assumption that AI will handle critical business processes, the gap between demo-quality performance and production-grade consistency represents an existential risk for the current investment thesis.

The analysis highlights a fundamental tension in AI deployment. Language models excel at generating plausible outputs but struggle with the kind of deterministic reliability that enterprise software typically requires. A system that's correct 95% of the time sounds impressive until you consider that a 5% error rate in financial transactions, medical records, or legal documents would be catastrophic.

Current mitigation strategies—human review, confidence thresholds, restricted use cases—all work but dramatically limit the efficiency gains that justify AI investments. If every AI output requires human verification, the productivity benefits shrink considerably. Enterprise adoption ultimately hinges on solving reliability, not just demonstrating capability on cherry-picked benchmarks.

The question looms particularly large as AI companies push toward agentic systems that take autonomous actions. A chatbot that occasionally hallucinates is annoying; an agent that occasionally executes the wrong transaction is dangerous.

What to Watch

The next few weeks will likely see competitive responses to both Microsoft's pricing moves and Google's Gemma 4 release, potentially forcing further price cuts across the inference market. The German copyright case bears watching as a potential template for European regulatory approaches to AI training data. And as enterprise reliability concerns gain mainstream attention, expect increased focus on evaluation frameworks and production monitoring tools designed to quantify—and hopefully improve—real-world AI system dependability.

Sources

- Does the AI business model have a fatal flaw?

Enjoyed this briefing? Follow this series for a fresh AI update every week, written for engineers who want to stay ahead.

Follow this publication on Dev.to to get notified of every new article.

Have a story tip or correction? Drop a comment below.

AI Weekly Digest: OpenAI Pivots Away from Sora, Agentic Frameworks Mature, and Open-Weight Models Gain Ground

Richard Dillon — Tue, 31 Mar 2026 13:18:01 +0000

AI Weekly Digest: OpenAI Pivots Away from Sora, Agentic Frameworks Mature, and Open-Weight Models Gain Ground

This week marked a strategic inflection point as OpenAI made the surprising decision to sunset its standalone Sora video application, signaling that even the most hyped consumer AI products face ruthless prioritization when compute resources run thin. Meanwhile, the agentic programming landscape continued its rapid maturation, with LangGraph cementing its position as the production-grade framework of choice while enterprises scramble to measure actual ROI from their AI agent deployments. The tension between building impressive demos and delivering reliable, cost-effective systems has never been more apparent.

OpenAI Discontinues Sora Video App to Refocus on Core AI Infrastructure

In a move that caught many observers off guard, OpenAI has discontinued its standalone Sora video generation application despite the tool's initial popularity following its public launch. The company cited the substantial compute demands of high-fidelity video generation as the primary driver behind the decision, with internal metrics reportedly showing declining active usage after the initial novelty wore off.

The resources previously dedicated to Sora consumer operations are being redirected toward foundational model scaling, infrastructure improvements, and enterprise products—areas where OpenAI sees clearer paths to sustainable revenue. However, the company emphasized that video and world simulation research continues internally, with applications targeted toward future robotics systems rather than consumer content creation.

This pivot reflects a broader industry reckoning with the economics of generative media. Video models require orders of magnitude more compute than text or image generation, and monetization has proven challenging when users expect free or near-free access. For developers who built workflows around Sora's API, the shutdown underscores the platform risk inherent in depending on consumer-facing AI services from companies still searching for product-market fit.

Revenium Launches AI Outcomes for Workflow-Level ROI Measurement

As enterprises push deeper into agentic AI deployments, the question of actual return on investment has become increasingly urgent. Revenium's newly launched AI Outcomes tool addresses this challenge by measuring ROI at the granular workflow level for individual AI agent executions—a capability that's been notably absent from the market.

The tool provides detailed cost attribution across multi-step agent workflows, tracking not just API spend but also infrastructure costs, human oversight time, and downstream business impact. For organizations running hundreds of distinct agent configurations, this visibility helps identify which deployments are generating value versus which are burning compute cycles without meaningful output.

The timing is particularly relevant as companies move from experimental pilots to production-scale agent deployments. Enterprises are increasingly focused on demonstrating concrete business value from their AI investments, and CFOs want more than anecdotal productivity gains. Revenium's approach of measuring outcomes at the workflow rather than model level acknowledges that AI value creation happens in the orchestration—how agents are chained, what tools they access, and how errors are handled—not just in raw model capability.

Lucid Software Expands MCP Server with New Process Agent for Team Collaboration

Lucid Software has rolled out significant enhancements to its Model Context Protocol server integration alongside a new Process Agent designed to streamline complex diagram and documentation workflows. The updates extend Lucid's existing AI capabilities with tighter integration into the MCP ecosystem that's become the de facto standard for tool connectivity in agentic systems.

The Process Agent specifically targets the labor-intensive work of translating meeting notes, requirements documents, and scattered communications into structured visual artifacts like flowcharts, architecture diagrams, and project timelines. Early users report substantial time savings on the kind of documentation work that often falls through the cracks in fast-moving engineering teams.

This release reflects a broader trend toward AI-assisted collaborative tooling where AI agents operate as persistent team members rather than on-demand utilities. By integrating through MCP, Lucid's agents can be invoked from other AI tools and workflows, fitting into the increasingly complex orchestration layers that enterprises are building. The approach suggests that specialized domain agents—rather than general-purpose assistants—may be the path to production-ready AI augmentation.

Claude Code Tool Suffers from "Amnesia" Bug in Extended Sessions

Reports have surfaced of a frustrating bug in Anthropic's Claude Code tool where the assistant forgets previous instructions during extended coding sessions, forcing users to repeatedly re-explain project context and coding conventions. The issue appears most pronounced in sessions exceeding several hours, with the AI seeming to "reset" its understanding of the codebase and prior decisions.

Developers describe scenarios where Claude Code begins suggesting changes that directly contradict earlier agreed-upon patterns, or requests information that was provided earlier in the same session. The bug leads to significant productivity losses on complex, multi-day refactoring efforts where maintaining continuity is essential.

The "amnesia" problem highlights ongoing reliability challenges in AI coding assistants when applied to substantial projects. While these tools excel at bounded tasks—writing a single function, explaining a code snippet, or generating boilerplate—maintaining coherent understanding across extended workflows remains technically difficult. The issue raises fundamental questions about memory management in agentic systems: how should context be persisted, summarized, and retrieved to enable the kind of sustained collaboration that mirrors human pair programming?

Agentic Programming Updates

The agentic programming landscape has crystallized significantly this quarter, with LangGraph emerging as the framework of choice for teams building production systems that require iterative, self-correcting reasoning loops. Its cyclic graph architecture enables the kind of retry logic and conditional branching that real-world agent deployments demand—agents can reconsider decisions, request human approval at key junctures, and gracefully handle the failures that inevitably occur when AI interfaces with external systems.

CrewAI continues gaining traction for rapid multi-agent prototyping, particularly among teams exploring agent concepts before committing to production architecture. However, we're seeing a consistent migration pattern: teams that start with CrewAI's simpler abstractions often move to LangGraph when they need production-grade state management, persistence, and observability. The tradeoff between developer velocity and operational robustness remains a defining tension in framework selection.

AutoGen has continued its evolution past v0.4, now offering a layered architecture with the event-driven Core runtime, Studio for no-code prototyping, and AgentChat as the primary Python API surface. This stratification aims to serve both researchers exploring novel agent architectures and enterprise teams deploying standardized patterns. Meanwhile, Google's Agent Development Kit (ADK) and Claude's Agent SDK are expanding enterprise multi-agent options, though adoption remains concentrated among customers already invested in those respective ecosystems.

The emerging industry consensus is clear: orchestration architecture now matters more than individual agent intelligence. Teams are finding that how agents communicate, maintain state, handle errors, and coordinate tool usage often determines system success more than the underlying model's raw capabilities. This realization is driving increased investment in observability tools, agent tracing systems, and standardized evaluation frameworks for multi-agent workflows.

Gemini 3.1 Flash Live Rolls Out Globally with Real-Time Audio and Camera Integration

Google has expanded its Gemini 3.1 Flash Live capabilities globally, bringing real-time audio conversations and visual context integration to users worldwide. The system allows continuous voice conversations with the AI while optionally sharing phone camera input, enabling scenarios where users can ask questions about what they're seeing in real-time.

The technical implementation represents a significant advancement in multimodal streaming—the system processes audio and visual inputs simultaneously while maintaining conversational context and generating low-latency responses. Early demonstrations show the system identifying objects, reading text, providing navigation assistance, and answering questions about physical environments with reasonable accuracy.

The global rollout has intensified discussions about distinguishing human from machine interactions as ambient AI assistants become more prevalent. The naturalness of real-time audio conversations—without the perceptible pauses of earlier systems—raises questions about disclosure and authenticity in communication. More broadly, the release signals a shift toward AI that observes and participates in the physical world rather than being confined to text boxes and chat interfaces.

Anthropic Secures Legal Victory Against Trump Administration Restrictions

Anthropic has won an injunction against federal restrictions that had threatened to constrain its AI operations, providing the company with crucial operational clarity amid ongoing regulatory uncertainty. The legal victory addresses restrictions that would have impacted aspects of the company's enterprise AI services, though specific details of the contested regulations remain partially sealed.

The ruling comes as Anthropic continues an aggressive enterprise push, expanding its Claude model family and enterprise API offerings. The company has positioned itself as a safety-focused alternative to OpenAI and Google, and any operational restrictions would have significantly impacted that competitive positioning.

The case signals ongoing tension between AI companies and government oversight efforts. While regulatory frameworks for AI remain unsettled, companies are increasingly turning to litigation to challenge restrictions they view as overreaching or technically uninformed. For enterprise customers evaluating AI partnerships, the regulatory environment has become a meaningful factor in vendor selection—platform stability depends not just on technical excellence but also on a company's ability to navigate the political landscape.

Kimi K2.5 and Qwen 3 Coder Join Growing Open-Weight Model Ecosystem

The open-weight model ecosystem continues expanding, with Kimi K2.5 and Qwen 3 Coder representing the latest entries that provide developers with alternatives to closed API dependencies. These releases reflect an accelerating trend toward efficient mixture-of-experts architectures and edge-capable reasoning models that can run on more modest infrastructure.

Kimi K2.5 offers a partially open-source approach with self-hosting capabilities, targeting developers who need model control without full weight access. Meanwhile, Qwen 3 Coder provides full Apache 2.0 licensing, enabling enterprise deployment without licensing friction—an increasingly important consideration as legal teams scrutinize AI model dependencies.

The practical impact is meaningful: organizations can now build AI stacks that rival or exceed paid tools in specific domains while maintaining full control over deployment, fine-tuning, and data handling. The expansion of open-source AI model API providers means teams can leverage these models without managing inference infrastructure, getting the benefits of open weights with managed deployment convenience.

What to Watch

The OpenAI Sora shutdown and Anthropic's legal battle both point to an industry maturing past pure capability growth into harder questions of sustainability, economics, and governance. Watch for more companies to make similarly tough prioritization decisions as compute economics force focus. The agentic framework space is also approaching a consolidation phase—expect clearer winners and losers by midyear as production deployments reveal which architectures actually scale.

Sources

- Best AI Coding Tools for Developers in 2026 - Builder.io

Enjoyed this briefing? Follow this series for a fresh AI update every day, written for engineers who want to stay ahead.

Follow this publication on Dev.to to get notified of every new article.

Have a story tip or correction? Drop a comment below.

AI Weekly: Gemini 3.1 Pro Leads a Week Where Open Source Closes In

Richard Dillon — Mon, 30 Mar 2026 12:01:51 +0000

AI Weekly: Gemini 3.1 Pro Leads a Week Where Open Source Closes In

The gap between frontier and open-source models is shrinking faster than anyone predicted. This week, Google DeepMind dropped Gemini 3.1 Pro with benchmark numbers that would have seemed impossible two years ago, but the real story is what's happening in the open-weights space—MiMo-V2-Flash and DeepSeek V3.2 are now within striking distance of proprietary systems at a fraction of the cost. Meanwhile, the infrastructure for agentic AI is maturing rapidly, robotics funding is surging, and Wikipedia is drawing a hard line against AI-generated content.

Gemini 3.1 Pro Arrives with 1M-Token Context and 77% ARC-AGI-2 Score

Google DeepMind has released Gemini 3.1 Pro, positioning it as the most capable Pro-tier model in their lineup. The headline numbers are impressive: a 1 million token context window and a 77.1% score on the ARC-AGI-2 benchmark, which specifically tests abstract reasoning capabilities that have historically challenged language models.

The multimodal reasoning extends across text, images, audio, video, and code in a unified architecture—no separate models stitched together. In practice, this means developers can pass in a two-hour video alongside a codebase and ask questions that require understanding both. Google claims latency improvements over 2.0 Pro despite the expanded capabilities, though independent benchmarks are still pending.

Availability is broad: the model is accessible through the Gemini API, Vertex AI for enterprise deployments, and Google's Antigravity platform. Pricing sits at the expected Pro tier, making it competitive with Claude 4.1 Sonnet and GPT-5.1 for most production use cases.

The ARC-AGI-2 score deserves attention. This benchmark specifically targets the kind of novel pattern recognition that pure next-token prediction struggles with—think IQ test problems rather than memorized facts. Breaking 77% suggests meaningful progress on generalization, though the gap to human performance (mid-80s for average adults) remains real.

Open-Source Models Close the Gap: MiMo-V2-Flash and DeepSeek V3.2 Challenge Frontier Systems

The open-source revolution in LLMs just hit an inflection point. MiMo-V2-Flash from Xiaomi's AI lab achieved a 66 QI (Quality Index) score with a stunning 96% on AIME—that's the American Invitational Mathematics Examination, not some synthetic benchmark. This represents the best mathematical reasoning performance ever recorded in an open-weights model.

DeepSeek V3.2, released the same week, matches that 66 QI while offering inference at $0.30 per million tokens through deepinfra. For comparison, GPT-5.1 runs $3.50/M tokens—more than 10x the cost for roughly equivalent capability on most tasks.

A detailed Reddit analysis examining 94 LLM API endpoints found the proprietary advantage has compressed to approximately 4 QI points. Two years ago, that gap was 15-20 points. The practical implication: for most production workloads that don't require the absolute bleeding edge, open-source models now offer better cost-performance ratios.

This isn't just academic. Companies running inference at scale are doing the math: a 10x cost reduction with a <5% capability hit changes build-versus-buy calculations dramatically. We're seeing migration patterns accelerate, particularly for classification, summarization, and code generation tasks where the gap is smallest. The remaining proprietary advantages cluster around complex multi-step reasoning and highly specialized domains—exactly the capabilities that justify premium pricing.

Agentic Programming Updates

Anthropic's 2026 Agentic Coding Trends Report, published last Tuesday, makes a bold prediction: multi-agent systems will largely replace single-agent workflows for complex coding tasks by year's end. The report cites internal data showing 3-4x throughput improvements when decomposing tasks across specialized agents versus monolithic prompting. This aligns with what we're seeing in production deployments—the single-agent pattern is hitting scaling walls.

Microsoft's Agent Framework, now in public preview, takes an explicitly enterprise-first approach. The emphasis is on durable orchestration (agents that survive process restarts) and human-in-the-loop scenarios where approval gates are non-negotiable. This matters for regulated industries where "the AI just did it" isn't an acceptable answer to auditors.

AutoGen v0.4+ represents a significant architectural pivot to event-driven execution with full async support. The previous version's synchronous patterns created bottlenecks in large-scale multi-agent coordination; the new architecture allows hundreds of agents to operate concurrently without blocking. Migration guides are available, but expect some friction—the programming model changed substantially.

The dominant architectural pattern emerging across all frameworks is role archetypes: Planner, Researcher, Coder, Reviewer. These constrained personas improve explainability (you can trace which "role" made which decision) and reduce the unbounded exploration that makes agents unreliable. Framework selection now increasingly hinges on state management philosophy—durable execution platforms like Temporal versus stateless serverless approaches determine whether your agents survive infrastructure failures.

Wikipedia Cracks Down on AI-Generated Articles Amid Misinformation Concerns

Wikipedia editors have implemented significantly stricter detection and removal protocols for AI-generated content, marking an escalation in the platform's ongoing struggle with synthetic text. The trigger: a wave of articles containing hallucinated citations—papers that don't exist, quotes that were never said, statistics fabricated wholesale.

The detection methods combine automated classifiers with human review, focusing on synthetic writing patterns (the telltale hedging phrases, the suspiciously comprehensive coverage, the lack of idiosyncratic human perspective) and citation verification. Editors report finding articles where every single source was either non-existent or misrepresented.

This raises uncomfortable questions for the AI ecosystem. Wikipedia has been a cornerstone training data source for language models; if AI-generated content infiltrates Wikipedia at scale, we get a feedback loop where models train on their own hallucinations. The platform is essentially defending the integrity of one of the most important knowledge repositories on the internet.

The response is part of a broader platform governance trend. Stack Overflow's AI content restrictions, academic publishers requiring AI disclosure, and social media platforms labeling synthetic content all reflect the same tension: AI-generated text is now good enough to pass casual inspection but not reliable enough to trust without verification. Wikipedia's hard line may influence how other knowledge platforms approach the problem.

ByteDance Launches Dreamina Seedance 2.0 with Built-In Misuse Protections

ByteDance entered the AI video generation race this week with Dreamina Seedance 2.0, notable less for its generation quality (competitive with Runway Gen-3 and Pika 2.0) than for its deployment model. The tool is integrated directly into CapCut, ByteDance's video editing platform with over 200 million monthly users.

The built-in safeguards are the more interesting story. Seedance 2.0 includes detection systems that refuse to generate content matching known individuals without explicit consent mechanisms, won't produce photorealistic violence or explicit content, and watermarks all outputs with invisible fingerprints. These aren't post-hoc additions—they're architectural decisions baked into the model.

This "responsible-by-design" approach contrasts with the "release-then-patch" pattern we've seen from other players. ByteDance clearly learned from the deepfake controversies that plagued earlier tools; TikTok's content moderation challenges presumably informed the decision to build guardrails before launch rather than after the damage is done.

For developers, CapCut integration means API access is coming—ByteDance typically follows consumer launches with developer tools within 3-6 months. The misuse protections will likely carry over, meaning anyone building on this platform inherits the guardrails. Whether that's a feature or a limitation depends on your use case.

Cohere Ships Open-Source Voice Model Supporting 14 Languages on Consumer GPUs

Cohere released an open-source speech transcription model this week designed to run on consumer-grade hardware—think RTX 4070-class GPUs, not datacenter A100s. The model supports 14 languages out of the box: English, Spanish, Mandarin, Hindi, Arabic, Portuguese, French, German, Japanese, Korean, Russian, Italian, Dutch, and Turkish.

The performance numbers are solid if not groundbreaking: word error rates within 10% of Whisper large-v3 while running 3x faster on equivalent hardware. The real value proposition is architectural—this is a single model handling all 14 languages, not 14 separate models, which simplifies deployment significantly.

For developers building voice-enabled applications, the implications are meaningful. No API dependencies means no per-minute costs, no network latency, and no privacy concerns about audio leaving local infrastructure. A small business building a voice assistant can now do so without ongoing API costs that scale with usage.

This continues the edge deployment trend we've tracked throughout 2025-2026: capable models are migrating from cloud-only to local-first. Voice is particularly suited to this pattern because audio data is sensitive and latency-critical. Cohere's licensing (Apache 2.0) removes commercial use restrictions, making this viable for production deployments without negotiating enterprise agreements.

Physical Intelligence Eyes $1B Raise as Robotics AI Funding Accelerates

Physical Intelligence, the robotics AI startup founded by ex-Google and Berkeley researchers, is reportedly in discussions for a $1 billion funding round that would approximately double its valuation to $4.5 billion. The company's π0 foundation model for robot control demonstrated cross-embodiment generalization last year—the same weights controlling arms, hands, and mobile bases.

The timing aligns with a broader thesis gaining momentum: 2026 is the year physical AI and robotics become the new scaling frontier. IBM Research's January predictions explicitly called this out, arguing that pure LLM scaling is hitting diminishing returns and that embodied intelligence represents the next capability unlock.

The capital deployment in this space is accelerating. SoftBank's $40 billion loan announced last week—primarily targeting AI infrastructure—signals that major investors see robotics and physical AI as requiring the same massive capital intensity that drove the LLM buildout. Figure, Sanctuary AI, and 1X are all reportedly raising substantial rounds.

The bulls argue that language models have essentially solved perception and reasoning; applying those capabilities to physical tasks is the obvious next step. The bears counter that sim-to-real transfer, hardware reliability, and safety certification create multi-year deployment timelines that investor patience may not accommodate. Physical Intelligence's ability to close this round will signal which narrative the market believes.

Code Platoon Integrates AI into Veteran Coding Bootcamp Curriculum

Code Platoon, the nonprofit bootcamp focused on transitioning military veterans and their spouses into tech careers, unveiled a substantially modernized curriculum this week. The updated program combines full-stack engineering fundamentals with generative AI skills, reflecting what the organization calls "the new baseline for engineering competency."

The AI integration goes beyond "how to use ChatGPT." Students learn ML fundamentals (enough to understand what's happening inside the models), prompt engineering for production systems, RAG architecture for building knowledge-augmented applications, and evaluation frameworks for AI-assisted code. The capstone projects require building applications with generative AI components.

This matters because workforce training programs are leading indicators. When bootcamps—which optimize aggressively for job placement—embed AI throughout their curricula rather than treating it as an elective, it signals that employers now expect these skills by default. Code Platoon's placement partners reportedly requested the curriculum changes, wanting graduates who can build with AI tooling from day one.

The veteran angle adds another dimension: this population often brings domain expertise (logistics, cybersecurity, operations) that translates well to building AI applications for those verticals. Combining that background with modern engineering skills creates a talent pipeline that enterprise employers are actively seeking.

What to Watch

Next week brings the Anthropic developer conference where Claude 4.2 is expected alongside expanded MCP tooling. The open-source momentum shows no signs of slowing—Llama 4 is rumored for Q2, which could compress the proprietary gap further. Most immediately, keep an eye on how quickly enterprise adoption shifts as the cost-capability curves cross; the migration patterns we're seeing in Q1 data suggest 2026 may be the year open-source becomes the default choice for most production LLM workloads.

Enjoyed this briefing? Follow this series for a fresh AI update every day, written for engineers who want to stay ahead.

Follow this publication on Dev.to to get notified of every new article.

Have a story tip or correction? Drop a comment below.

Primitive Shifts: AI Skills — The Knowledge Primitive Replacing Prompt Engineering

Richard Dillon — Sun, 29 Mar 2026 15:44:24 +0000

Primitive Shifts: AI Skills — The Knowledge Primitive Replacing Prompt Engineering

Every few months, the baseline of how AI systems work quietly moves. Engineers who noticed early weren't smarter — they were just paying attention to the right signals. The shift from "prompt engineering" to "function calling" caught teams off guard in 2023. The rise of MCP for tool integration did the same in late 2024. Now, the same pattern is playing out with AI Skills — and if you're still treating agent context as a prompt engineering problem, you're about to feel that familiar sting of realizing the floor moved while you were standing on it.

What Is It?

AI Skills are portable, structured knowledge packages that teach agents how to perform domain-specific tasks. This is categorically different from tools (which provide access to external systems) and prompts (which provide instructions for a single interaction). A skill encapsulates institutional knowledge: your team's code review standards, your API versioning conventions, the twelve edge cases in your payment processing flow that every new engineer learns the hard way.

The pattern didn't emerge from a single announcement. It crystallized from convergence. Cursor rules, GitHub Copilot custom instructions, Windsurf rules, and the .cursorrules file format all evolved toward the same abstraction independently throughout 2024 and early 2025. Different teams, solving the same underlying problem, arrived at remarkably similar solutions.

Anthropic formalized this in December 2025 with the Agent Skills open standard. OpenAI, Google, and Microsoft tooling adopted compatible interfaces within months. This wasn't vendor lock-in theater — the abstraction was obvious enough that interoperability became the path of least resistance.

Critically, skills are consumed at inference time, not training time. They extend agent capabilities without fine-tuning, sitting in context windows as structured, discoverable knowledge units. The primitive answers a specific architectural question that every production AI team eventually asks: "How do I make my agent understand our codebase conventions, compliance requirements, and domain logic without rebuilding the model?"

The answer used to be "stuff it in the system prompt and hope for the best." Now there's actual infrastructure.

Why It's Flying Under the Radar

Skills suffer from the worst kind of invisibility: they look like something teams already know how to dismiss. Engineers see .md files with instructions and assume it's prompt engineering with extra steps. The structural and discoverability properties — the actual innovation — are invisible at first glance. "We already have a CONTRIBUTING.md," teams say, missing that the format, placement, and tooling integration are what transform documentation into agent-consumable knowledge.

The adoption happened inside IDEs, not through announcement posts. Over 60,000 open-source projects adopted AGENTS.md files before most engineering teams noticed the pattern. The signal was there — you just had to be looking at repository structures rather than press releases.

Skills solve a problem teams don't name correctly. "Context finding" is the number-one developer pain point — 40% cite it in recent surveys. But teams frame this as a documentation problem or a search problem, not a knowledge-packaging problem. They invest in better docs, improved search indexing, more comprehensive onboarding materials. Meanwhile, the actual friction is that their AI agents can't find the knowledge that already exists.

Here's what should concern you: the format war already ended. While internal teams debated custom solutions and enterprise architects drew up plans for proprietary knowledge management systems, the major AI platforms quietly converged on a common interface. The window for "we'll build our own" closed without a memo.

Flask creator Armin Ronacher's observation went viral in niche circles: moving several MCP integrations to skills improved agent performance meaningfully — fewer hallucinations, better adherence to conventions, reduced back-and-forth. But this signal stayed in technical blogs and Hacker News threads. It didn't reach engineering leadership channels. Which means right now, there are teams planning six-month "AI context management" initiatives that could be solved with a well-structured markdown file and thirty minutes of work.

Hands-On: Try It Today

Let's make this concrete. The following Python script demonstrates how to create, validate, and test a skill file that teaches an AI agent your team's database migration conventions. This isn't a toy example — it's the pattern production teams are using.

#!/usr/bin/env python3
"""
skill_builder.py - Create and validate AI Skills for your codebase

This script demonstrates the emerging skill file pattern:
1. Structured markdown with semantic sections
2. Validation against the Agent Skills schema
3. Testing skill discovery with a local agent

Requires: pip install pydantic>=2.0 anthropic>=0.40.0 pyyaml>=6.0
Tested with: Python 3.11+, Anthropic API v0.40.0
"""

import json
import re
from pathlib import Path
from typing import Optional
from pydantic import BaseModel, Field, field_validator
import anthropic


class SkillSection(BaseModel):
    """A single section within a skill file."""
    heading: str = Field(..., description="Section heading (## level)")
    content: str = Field(..., description="Section content")
    priority: int = Field(default=0, ge=0, le=10, description="0-10, higher = more critical")


class AgentSkill(BaseModel):
    """
    Represents a portable AI Skill following the emerging standard.

    Skills differ from prompts in three ways:
    1. They're discoverable (agents find them based on task context)
    2. They're portable (same skill works across Cursor, Claude Code, Copilot)
    3. They're composable (multiple skills can be active simultaneously)
    """
    name: str = Field(..., description="Skill identifier, e.g., 'database-migrations'")
    version: str = Field(default="1.0.0", pattern=r"^\d+\.\d+\.\d+$")
    triggers: list[str] = Field(
        default_factory=list,
        description="Keywords/patterns that should activate this skill"
    )
    sections: list[SkillSection] = Field(default_factory=list)
    max_rules: int = Field(default=15, description="Guardrails should stay under 15 rules")

    @field_validator('sections')
    @classmethod
    def validate_guardrails_count(cls, sections: list[SkillSection]) -> list[SkillSection]:
        """Enforce the 15-rule limit for GUARDRAILS sections."""
        for section in sections:
            if "GUARDRAIL" in section.heading.upper():
                rule_count = len(re.findall(r'^[-*]\s', section.content, re.MULTILINE))
                if rule_count > 15:
                    raise ValueError(
                        f"GUARDRAILS section has {rule_count} rules; max is 15. "
                        "Agents struggle with more — prioritize ruthlessly."
                    )
        return sections

    def to_markdown(self) -> str:
        """Export skill as AGENTS.md compatible markdown."""
        lines = [
            f"# {self.name}",
            f"<!-- skill-version: {self.version} -->",
            f"<!-- triggers: {', '.join(self.triggers)} -->",
            "",
        ]
        for section in sorted(self.sections, key=lambda s: -s.priority):
            lines.extend([
                f"## {section.heading}",
                "",
                section.content,
                "",
            ])
        return "\n".join(lines)


def create_migration_skill() -> AgentSkill:
    """
    Example: A skill teaching database migration conventions.

    This encapsulates knowledge that would otherwise live in:
    - Onboarding docs (rarely read by AI)
    - Code review comments (learned too late)
    - Tribal knowledge (never written down)
    """
    return AgentSkill(
        name="database-migrations",
        version="1.0.0",
        triggers=["migration", "schema change", "alembic", "database", "ALTER TABLE"],
        sections=[
            SkillSection(
                heading="GUARDRAILS",
                priority=10,
                content="""
- NEVER use `DROP COLUMN` without a two-phase migration plan
- ALWAYS add new columns as nullable first, backfill, then add constraints
- NEVER modify migrations that have been applied to production
- ALWAYS include rollback instructions in migration docstring
- Use `op.execute()` for data migrations, not ORM models
- Foreign keys must use `ondelete="CASCADE"` or explicit alternative
- Index names must follow pattern: `ix_{table}_{columns}`
- ALWAYS run `alembic check` before committing migration files
"""
            ),
            SkillSection(
                heading="CONVENTIONS",
                priority=5,
                content="""
Our migrations follow a specific lifecycle:

1. **Development**: Create migration with `alembic revision --autogenerate -m "description"`
2. **Review**: Migration PRs require explicit sign-off from database owner
3. **Staging**: Migrations run automatically on merge to `staging` branch
4. **Production**: Migrations require manual trigger via deployment pipeline

Migration files live in `src/db/migrations/versions/`. The revision ID format
is timestamp-based (YYYYMMDD_HHMM) not random hex.

For large tables (>1M rows), use batch operations:

python

Good: batched update

for batch in op.batch_alter_table('users', batch_size=10000):
batch.update(...)

Bad: full table lock

op.execute("UPDATE users SET ...")

"""
            ),
            SkillSection(
                heading="COMMON MISTAKES",
                priority=7,
                content="""
**The ORM Import Trap**: Never import application models in migrations.
Models change; migrations are immutable history. Use raw SQL or SQLAlchemy core.

**The Default Value Trap**: Adding `server_default` to existing column requires
two migrations — one to add the default, one to backfill NULL values.

**The Index Trap**: Creating indexes on large tables blocks writes. Use 
`CREATE INDEX CONCURRENTLY` via `op.execute()` with `postgresql_concurrently=True`.
"""
            ),
        ],
    )


def test_skill_discovery(skill: AgentSkill, test_query: str) -> dict:
    """
    Test whether an agent correctly discovers and applies a skill.

    This simulates what happens when a developer asks for help with
    a task that should trigger skill activation.
    """
    client = anthropic.Anthropic()  # Uses ANTHROPIC_API_KEY env var

    skill_content = skill.to_markdown()

    # Simulate skill injection (in production, IDEs do this automatically)
    system_prompt = f"""You are a coding assistant with access to project-specific skills.

Active skill:
---
{skill_content}
---

When the user's request relates to a skill's triggers, apply that skill's 
guardrails and conventions. Cite specific rules when relevant."""

    response = client.messages.create(
        model="claude-sonnet-4-20250514",
        max_tokens=1024,
        system=system_prompt,
        messages=[{"role": "user", "content": test_query}]
    )

    response_text = response.content[0].text

    # Check if skill was actually applied
    skill_indicators = [
        "nullable first" in response_text.lower(),
        "guardrail" in response_text.lower(),
        "two-phase" in response_text.lower(),
        "rollback" in response_text.lower(),
    ]

    return {
        "query": test_query,
        "response": response_text,
        "skill_applied": any(skill_indicators),
        "indicators_found": sum(skill_indicators),
    }


if __name__ == "__main__":
    # Create the skill
    skill = create_migration_skill()

    # Write to AGENTS.md (or skill-specific file)
    output_path = Path("AGENTS.md")
    output_path.write_text(skill.to_markdown())
    print(f"✓ Wrote skill to {output_path}")

    # Validate structure
    print(f"✓ Skill '{skill.name}' v{skill.version} validated")
    print(f"  Triggers: {skill.triggers}")
    print(f"  Sections: {[s.heading for s in skill.sections]}")

    # Test discovery (requires ANTHROPIC_API_KEY)
    try:
        result = test_skill_discovery(
            skill, 
            "I need to add a new 'email_verified' boolean column to the users table"
        )
        print(f"\n✓ Discovery test:")
        print(f"  Query: {result['query']}")
        print(f"  Skill applied: {result['skill_applied']}")
        print(f"  Indicators found: {result['indicators_found']}/4")
    except anthropic.AuthenticationError:
        print("\n⚠ Skipping discovery test (set ANTHROPIC_API_KEY to test)")

Start with a single AGENTS.md file at your repository root. Document your team's code review standards, API conventions, and — critically — the things your AI assistant keeps getting wrong. The emerging hierarchy uses MEMORY.md for long-term knowledge, GUARDRAILS.md for hard constraints (keep it under 15 rules; agents struggle with more), and WORKSTATE.md for session continuity.

Test skill discovery by creating a skill for one workflow and verifying your IDE's agent surfaces it unprompted when relevant context appears. Measure the delta: run identical coding tasks with and without skills loaded. Teams report 20-30% reduction in back-and-forth corrections, which compounds significantly over a sprint.

What This Means for Your Stack

If your team has per-developer .cursorrules files, per-repo prompt templates, and scattered system_prompt.txt files across different projects, you're accumulating non-portable knowledge silos. This is technical debt that will become painful when you need to switch tools, onboard new team members, or scale agent usage beyond individual developers.

More immediately relevant: your RAG pipelines may be over-engineered for problems skills solve natively. If you're chunking internal documentation, embedding it into a vector database, and injecting retrieved chunks into prompts at inference time, ask yourself whether a curated 500-line skill file would perform better. For institutional knowledge — conventions, constraints, common mistakes — the answer is usually yes. Lower latency, lower cost, better coherence.

The "context window economy" is real. Atlassian's 2025 developer productivity data shows AI gains are significantly offset by knowledge-finding friction. Skills function as the compression layer that makes institutional knowledge agent-consumable. You're not solving a documentation problem; you're solving a context density problem.

Here's the architectural insight that matters: Skills and MCP form a complete architecture. MCP gives agents access to systems — databases, APIs, services, tools. Skills give agents knowledge about how to use that access correctly. Most teams have built the former without the latter. They have agents that can query their databases and call their APIs, but those agents don't know the team's conventions, constraints, or context. That's why the outputs feel generic even when the capabilities are powerful.

Your evaluation frameworks need updating too. You're not just testing model outputs anymore. You're testing whether the right skills were discovered and applied for the task. Add skill coverage to your agent evaluation suite.

The Infrastructure Signal

When Anthropic, OpenAI, Google, and Microsoft independently adopt the same abstraction within six months, you're watching an interface crystallize into infrastructure. This is the signal that separates "interesting experiment" from "new baseline." Skills crossed that threshold.

Bessemer Venture Partners' 2025 State of AI report identifies skills as the "memory, context, and beyond" layer — what they call the dark matter of production AI systems. It's the factor that explains why two teams using the same model, same tools, and same prompts get meaningfully different results. One team's agents know things. The other team's agents are constantly relearning.

The pattern mirrors function calling's trajectory from 2023. That capability went from prompt hack to first-class API primitive to "why are you still parsing JSON manually?" in under 18 months. Skills are on the same curve, roughly twelve months behind. We're currently in the "early adopters have integrated it; everyone else is about to feel pressure" phase.

IDE vendors are building skill registries and discovery mechanisms into their agent UX. The primitives are becoming platform features, not user configurations. This is the point where opting out starts to cost more than opting in.

The research-to-production gap is closing fast. Academic work on "institutional knowledge primitives" appeared in March 2025 arxiv papers. Those same concepts shipped in production products by Q4 2025. The theory-to-deployment cycle has compressed to months, not years. By the time you read a research paper about emerging AI patterns, the major platforms have often already shipped an implementation.

Shift Rating

🟢 Adopt Now

The standard exists. Major platforms support it. The migration cost is minimal — you're writing structured markdown files, not rebuilding infrastructure. Teams that formalize their institutional knowledge into skills today will compound that advantage as agent capabilities expand. Every skill you write now becomes more valuable as models get better at following them.

Teams that wait will find themselves explaining the same context to every new AI tool, repeatedly, while competitors' agents already know the answers. The compounding effect here is real: a team with well-maintained skills gets better agent outputs, which means less time correcting agents, which means more time building, which means faster iteration on the skills themselves.

Start this week. Pick one workflow where your AI assistant consistently makes mistakes or asks for clarification. Document the implicit knowledge in a skill file. Measure the improvement. Then expand from there. The infrastructure is ready. The question is whether you are.

This is part of **Primitive Shifts* — a monthly series tracking when new AI building blocks
move from novel experiments to infrastructure you'll be expected to know.*

Follow the Next MCP Watch series on Dev.to to catch every edition.

Spotted a shift happening in your stack? Drop it in the comments.

LangGraph 2.0: The Definitive Guide to Building Production-Grade AI Agents in 2026

Richard Dillon — Sun, 29 Mar 2026 14:35:04 +0000

LangGraph 2.0: The Definitive Guide to Building Production-Grade AI Agents in 2026

The agent framework wars are over, and LangGraph won. Not because it's the simplest tool—it isn't—but because production agents have proven to be fundamentally different from the linear pipelines we built in 2024. When your agent needs to retry a failed API call, loop back for clarification, pause for human approval, and recover gracefully from partial failures, you need a graph, not a chain. LangGraph 2.0, released in February 2026, codifies three years of hard-won production patterns into a framework that finally feels mature.

Why LangGraph Matters Now: From Chains to Graphs

The mental model shift from LangChain to LangGraph is the same shift that took web development from CGI scripts to event-driven architectures. In LangChain, you think in sequences: retrieve, augment, generate, done. In LangGraph, you think in states and transitions: what state is my agent in, what conditions determine where it goes next, and what happens when something fails?

This isn't academic. Consider a simple document research agent. In the linear world, you retrieve documents, synthesize findings, and return a response. But production requirements quickly break this model. What if the retrieval returns low-confidence results? You need to loop back and refine the query. What if the synthesized action requires human approval before execution? You need to pause, persist state, and resume potentially hours later. What if the external API you're calling has a 5% failure rate? You need retry logic with backoff.

LangGraph represents these workflows as directed cyclic graphs where nodes are actions and edges are conditional transitions. The graph can loop back on itself, branch into parallel paths, or pause indefinitely waiting for external input. This is the fundamental primitive that production agents require.

The adoption numbers reflect this reality. Gartner's March 2026 report predicts 40% of enterprise applications will embed agentic capabilities by year-end, up from 12% in 2025. Among teams building these systems, LangGraph has emerged as the dominant orchestration layer—not because LangChain failed, but because it solved a different problem.

That said, LangGraph is frequently overkill. If you're building a straightforward RAG pipeline, a Q&A bot without loops, or any single-turn interaction, LangChain remains the right choice. LangGraph introduces complexity—state schemas, checkpoint persistence, graph compilation—that pays dividends for complex workflows but adds friction for simple ones. The decision tree is straightforward: if your agent needs to loop, branch, retry, or pause, use LangGraph. If it doesn't, don't.

What's New in LangGraph 2.0: Breaking Changes and Migration

Version 2.0 represents LangGraph's graduation from "promising framework" to "production foundation." The API surface has been dramatically cleaned up, deprecated patterns removed, and type safety elevated to first-class status. This maturity comes with breaking changes that will require migration effort.

The most significant breaking change is StateGraph initialization. In v0.1.x, you could create a graph with minimal configuration:

# v0.1.x (DEPRECATED)
from langgraph.graph import StateGraph

graph = StateGraph(AgentState)
graph.add_node("research", research_node)
# Checkpointing was optional and configured separately

In v2.0, checkpoint configuration is required at initialization, and the API enforces explicit persistence decisions:

# v2.0 (CURRENT)
from langgraph.graph import StateGraph
from langgraph.checkpoint.postgres import PostgresSaver

checkpointer = PostgresSaver.from_conn_string(
    "postgresql://user:pass@localhost/langgraph",
    pool_size=10,  # New in 2.0: connection pooling configuration
    schema_name="agents"  # New in 2.0: multi-tenant schema support
)

graph = StateGraph(
    AgentState,
    checkpointer=checkpointer,
    interrupt_before=["human_review"],  # Moved from add_node to initialization
)

The second major change is interrupt handling. The previous pattern used exceptions to signal interrupts, which was fragile and made error handling ambiguous:

# v0.1.x (DEPRECATED)
from langgraph.errors import NodeInterrupt

def human_review_node(state):
    if state["needs_approval"]:
        raise NodeInterrupt("Awaiting human approval")
    return state

Version 2.0 introduces a clean interrupt() function that explicitly signals pause points:

# v2.0 (CURRENT)
from langgraph.types import interrupt, Command

def human_review_node(state):
    if state["needs_approval"]:
        approval = interrupt({
            "question": "Approve this action?",
            "proposed_action": state["proposed_action"],
            "context": state["synthesis"]
        })
        return Command(update={"approval_status": approval})
    return state

The new approach makes interrupt payloads explicit, provides better typing for IDE support, and cleanly separates the interrupt signal from error handling.

Guardrail Nodes represent the third major addition. Enterprise deployments have been rolling their own content filtering, rate limiting, and compliance logging for years. Version 2.0 makes these first-class primitives:

from langgraph.guardrails import ContentFilter, RateLimiter, AuditLogger

graph.add_guardrail(
    ContentFilter(
        blocked_patterns=["PII_PATTERN", "PROFANITY"],
        action="redact"  # or "block", "flag"
    ),
    before=["synthesis", "action"]  # Apply before these nodes
)

graph.add_guardrail(
    RateLimiter(
        requests_per_minute=60,
        burst_limit=10,
        scope="per_user"  # or "global", "per_thread"
    )
)

graph.add_guardrail(
    AuditLogger(
        destination="cloudwatch://agents/compliance",
        include_state=True,
        redact_fields=["user_pii", "api_keys"]
    )
)

For teams migrating existing applications, LangChain provides automated migration scripts in the langchain-cli package. Running langchain migrate langgraph will identify deprecated patterns and suggest fixes. However, the scripts can't automatically migrate custom checkpoint implementations or complex interrupt handlers—budget manual effort for those components.

Multi-Agent Protocol Support: A2A and MCP Integration

Before 2026, connecting an agent to external tools meant writing custom integration code for every tool, every database, every API. Connecting agents to other agents—especially across frameworks—was effectively impossible without building custom message-passing infrastructure. Two protocols have emerged to solve this: MCP for agent-tool connections and A2A for agent-agent communication.

The Model Context Protocol (MCP), originally developed by Anthropic and now maintained by the Linux Foundation, has become the "USB port for agents." It provides a standardized way for agents to discover, authenticate with, and invoke external tools. Rather than writing custom code to connect your agent to Slack, you connect to a Slack MCP server that exposes standardized tool definitions.

LangGraph 2.0 treats MCP as a first-class primitive. Tools can be imported directly from MCP servers:

from langgraph.tools.mcp import MCPToolkit

# Connect to MCP servers
toolkit = MCPToolkit(
    servers=[
        "mcp://tools.company.internal/slack",
        "mcp://tools.company.internal/jira",
        "mcp://tools.company.internal/postgres"
    ],
    auth_provider="vault://secrets/mcp-tokens"
)

# Tools are automatically typed and documented
available_tools = toolkit.get_tools()
# Returns: [SlackSendMessage, SlackReadChannel, JiraCreateTicket, ...]

The A2A (Agent-to-Agent) protocol addresses the harder problem: agents communicating with other agents, potentially running on different frameworks. A LangGraph orchestrator might need to delegate a subtask to a CrewAI crew, receive the result, and incorporate it into its own state.

LangGraph 2.0's A2A support works through message queues and shared contracts:

from langgraph.a2a import A2AClient, AgentContract

# Define the contract for the external agent
research_crew_contract = AgentContract(
    agent_id="crewai://research-team.internal",
    input_schema=ResearchRequest,
    output_schema=ResearchReport,
    timeout_seconds=300
)

a2a_client = A2AClient(
    broker_url="nats://a2a-broker.internal:4222",
    contracts=[research_crew_contract]
)

async def delegate_research_node(state):
    """Delegate deep research to specialized CrewAI team."""
    request = ResearchRequest(
        topic=state["research_topic"],
        depth="comprehensive",
        sources=["academic", "news", "internal_docs"]
    )

    # Send request and await response (with timeout and retry)
    report = await a2a_client.invoke(
        agent_id="crewai://research-team.internal",
        request=request,
        correlation_id=state["thread_id"]
    )

    return {"research_report": report, "delegation_complete": True}

The architecture flows like this: your LangGraph orchestrator node sends a message to the A2A broker, which routes it to the CrewAI crew. That crew processes the request, sends its response back through the broker, and your LangGraph node receives it and updates state. From LangGraph's perspective, it's just an async node; the complexity of cross-framework communication is hidden behind the protocol.

One critical gotcha: MCP and A2A are versioned protocols, and version mismatches cause subtle bugs. Always pin your protocol versions in production, and test thoroughly when upgrading. The mcp-version and a2a-version fields in your configuration should be explicit, not latest.

Hands-On: Code Walkthrough

Let's build a complete document research agent that demonstrates LangGraph 2.0's key patterns. This agent searches documents, synthesizes findings, pauses for human approval before taking actions, and can loop back for clarification when needed.

"""
Document Research Agent with Human-in-the-Loop Approval
LangGraph 2.0 | Python 3.12+ | PostgreSQL persistence

Requirements:
    langgraph==2.0.3
    langchain-anthropic==0.3.1
    langchain-postgres==0.2.0
    psycopg[pool]==3.2.0
"""

from typing import Annotated, Literal, TypedDict
from operator import add

from langchain_anthropic import ChatAnthropic
from langchain_core.messages import AIMessage, HumanMessage, SystemMessage
from langchain_core.tools import tool
from langgraph.graph import StateGraph, START, END
from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.types import interrupt, Command
from langgraph.prebuilt import ToolNode


# === State Schema Definition ===
# Annotated fields with reducer functions define how state updates accumulate

class AgentState(TypedDict):
    """Complete state for the research agent.

    Using Annotated with reducers means multiple node updates
    to the same field are combined rather than overwritten.
    """
    messages: Annotated[list, add]  # Messages accumulate across nodes
    research_results: Annotated[list[dict], add]  # Research findings accumulate
    synthesis: str  # Latest synthesis (overwrites)
    proposed_action: dict | None  # Action awaiting approval
    approval_status: Literal["pending", "approved", "rejected", "needs_clarification"] 
    confidence_score: float  # Research confidence (0.0 - 1.0)
    iteration_count: int  # Track loops for circuit-breaker


# === Tool Definitions ===

@tool
def search_documents(query: str, max_results: int = 5) -> list[dict]:
    """Search the document corpus for relevant information.

    Args:
        query: Natural language search query
        max_results: Maximum number of results to return

    Returns:
        List of document excerpts with relevance scores
    """
    # In production, this would call your vector store
    # Simulated response for demonstration
    return [
        {
            "doc_id": "DOC-2024-001",
            "excerpt": "Q4 revenue exceeded projections by 12%...",
            "relevance_score": 0.92,
            "source": "financial_reports"
        },
        {
            "doc_id": "DOC-2024-002", 
            "excerpt": "Customer acquisition cost decreased to $45...",
            "relevance_score": 0.87,
            "source": "metrics_dashboard"
        }
    ]


@tool
def execute_action(action_type: str, parameters: dict) -> dict:
    """Execute an approved action.

    Args:
        action_type: Type of action (e.g., "send_report", "update_dashboard")
        parameters: Action-specific parameters

    Returns:
        Execution result with status and details
    """
    # In production, this would perform real actions
    return {
        "status": "success",
        "action_type": action_type,
        "timestamp": "2026-03-29T10:30:00Z",
        "details": f"Executed {action_type} with {parameters}"
    }


# === Model Configuration ===

model = ChatAnthropic(
    model="claude-sonnet-4-20250514",
    temperature=0.1,  # Low temperature for consistent research
    max_tokens=4096
)

# Bind tools to model for automatic tool calling
model_with_tools = model.bind_tools([search_documents, execute_action])


# === Node Implementations ===

def research_node(state: AgentState) -> dict:
    """Invoke retrieval tools and accumulate research results.

    This node lets the model decide which tools to call based
    on the current conversation context and previous findings.
    """
    system_prompt = SystemMessage(content="""You are a research assistant.
    Analyze the user's request and search for relevant documents.
    If previous research exists, determine if more searching is needed
    or if you have sufficient information to synthesize findings.""")

    messages = [system_prompt] + state["messages"]
    response = model_with_tools.invoke(messages)

    return {
        "messages": [response],
        "iteration_count": state["iteration_count"] + 1
    }


def synthesis_node(state: AgentState) -> dict:
    """Synthesize research findings and propose next action.

    Evaluates accumulated research, generates a synthesis,
    calculates confidence, and proposes an action if warranted.
    """
    system_prompt = SystemMessage(content="""Based on the research results,
    synthesize the findings into a coherent summary. Then:
    1. Assess your confidence (0.0-1.0) in the completeness of research
    2. If confidence > 0.7, propose a specific action to take
    3. If confidence <= 0.7, indicate more research is needed

    Format your response as JSON with keys: synthesis, confidence, proposed_action""")

    # Include research results in context
    research_context = f"Research findings: {state['research_results']}"
    messages = [system_prompt, HumanMessage(content=research_context)]

    response = model.invoke(messages)

    # Parse the structured response (in production, use structured output)
    # Simplified for demonstration
    import json
    try:
        parsed = json.loads(response.content)
    except json.JSONDecodeError:
        parsed = {
            "synthesis": response.content,
            "confidence": 0.5,
            "proposed_action": None
        }

    return {
        "messages": [AIMessage(content=parsed["synthesis"])],
        "synthesis": parsed["synthesis"],
        "confidence_score": parsed.get("confidence", 0.5),
        "proposed_action": parsed.get("proposed_action"),
        "approval_status": "pending" if parsed.get("proposed_action") else "pending"
    }


def human_review_node(state: AgentState) -> Command:
    """Pause for human approval using LangGraph 2.0 interrupt API.

    This node suspends graph execution and awaits external input.
    The interrupt payload is sent to the client and can be displayed
    in a UI for human review.
    """
    # Create interrupt with full context for reviewer
    approval_response = interrupt({
        "type": "approval_request",
        "synthesis": state["synthesis"],
        "proposed_action": state["proposed_action"],
        "confidence_score": state["confidence_score"],
        "research_summary": f"Based on {len(state['research_results'])} documents",
        "options": ["approve", "reject", "needs_clarification"]
    })

    # approval_response comes from the resume call
    # e.g., {"decision": "approved", "notes": "Looks good"}
    return Command(
        update={
            "approval_status": approval_response.get("decision", "rejected"),
            "messages": [HumanMessage(content=f"Reviewer decision: {approval_response}")]
        }
    )


def action_node(state: AgentState) -> dict:
    """Execute the approved action."""
    if state["approval_status"] != "approved":
        return {"messages": [AIMessage(content="Action was not approved.")]}

    result = execute_action.invoke({
        "action_type": state["proposed_action"]["type"],
        "parameters": state["proposed_action"]["parameters"]
    })

    return {
        "messages": [AIMessage(content=f"Action executed: {result}")],
    }


def clarification_node(state: AgentState) -> dict:
    """Handle requests for clarification by refining the research query."""
    return {
        "messages": [AIMessage(content="I'll gather more specific information.")],
        "confidence_score": 0.0  # Reset to trigger more research
    }


# === Conditional Edge Functions ===

def route_after_synthesis(state: AgentState) -> Literal["human_review", "research", "end"]:
    """Determine next step based on confidence and iteration count."""
    # Circuit breaker: max 5 research iterations
    if state["iteration_count"] >= 5:
        return "human_review"

    if state["confidence_score"] > 0.7 and state["proposed_action"]:
        return "human_review"
    else:
        return "research"  # Loop back for more research


def route_after_approval(state: AgentState) -> Literal["action", "clarification", "end"]:
    """Route based on human approval decision."""
    match state["approval_status"]:
        case "approved":
            return "action"
        case "needs_clarification":
            return "clarification"
        case _:  # rejected or other
            return "end"


def route_after_clarification(state: AgentState) -> Literal["research"]:
    """Always loop back to research after clarification."""
    return "research"


# === Graph Construction ===

# Configure PostgreSQL persistence with 2.0 connection pooling
checkpointer = PostgresSaver.from_conn_string(
    "postgresql://langgraph:secure_password@localhost:5432/agents",
    pool_size=20,
    max_overflow=10,
    pool_timeout=30,
    schema_name="research_agent"
)

# Build the graph
graph_builder = StateGraph(AgentState, checkpointer=checkpointer)

# Add nodes
graph_builder.add_node("research", research_node)
graph_builder.add_node("tools", ToolNode([search_documents, execute_action]))
graph_builder.add_node("synthesis", synthesis_node)
graph_builder.add_node("human_review", human_review_node)
graph_builder.add_node("action", action_node)
graph_builder.add_node("clarification", clarification_node)

# Add edges
graph_builder.add_edge(START, "research")
graph_builder.add_edge("research", "tools")  # Always run tools after research node
graph_builder.add_edge("tools", "synthesis")
graph_builder.add_conditional_edges("synthesis", route_after_synthesis)
graph_builder.add_conditional_edges("human_review", route_after_approval)
graph_builder.add_edge("action", END)
graph_builder.add_conditional_edges("clarification", route_after_clarification)

# Compile the graph
graph = graph_builder.compile()


# === Execution Examples ===

def run_research_session():
    """Demonstrate full agent execution with human-in-the-loop."""

    # Initial invocation - will pause at human_review
    thread_config = {"configurable": {"thread_id": "research-session-001"}}

    initial_state = {
        "messages": [HumanMessage(content="Analyze Q4 financial performance")],
        "research_results": [],
        "synthesis": "",
        "proposed_action": None,
        "approval_status": "pending",
        "confidence_score": 0.0,
        "iteration_count": 0
    }

    # First run - executes until interrupt
    print("Starting research session...")
    result = graph.invoke(initial_state, thread_config)
    print(f"Paused for approval. Synthesis: {result['synthesis'][:100]}...")

    # Simulate time passing, human reviews in UI...
    # Resume with approval
    print("\nResuming with approval...")
    final_result = graph.invoke(
        Command(resume={"decision": "approved", "notes": "Analysis looks comprehensive"}),
        thread_config
    )
    print(f"Final result: {final_result['messages'][-1].content}")


def stream_research_session():
    """Stream execution for real-time UI updates."""

    thread_config = {"configurable": {"thread_id": "research-session-002"}}
    initial_state = {
        "messages": [HumanMessage(content="What were our top customer complaints last quarter?")],
        "research_results": [],
        "synthesis": "",
        "proposed_action": None,
        "approval_status": "pending",
        "confidence_score": 0.0,
        "iteration_count": 0
    }

    # Stream mode provides real-time updates
    for event in graph.stream(initial_state, thread_config, stream_mode="updates"):
        node_name = list(event.keys())[0]
        print(f"[{node_name}] State update received")

        # In a real app, send these updates via WebSocket to frontend
        if node_name == "synthesis":
            print(f"  Confidence: {event[node_name].get('confidence_score', 'N/A')}")


if __name__ == "__main__":
    run_research_session()

This implementation demonstrates several LangGraph 2.0 patterns. The state schema uses Annotated fields with reducer functions to accumulate messages and research results across iterations. The interrupt() function cleanly pauses execution with a structured payload that can be rendered in a review UI. Conditional edges route the graph based on confidence scores and approval decisions, enabling both loops (back to research) and branches (to action or clarification). The checkpointer configuration uses 2.0's connection pooling for production database usage.

What This Means for Your Stack

The decision to adopt LangGraph should be based on workflow complexity, not hype. Start with this decision tree: Does your agent need to loop, retry, branch conditionally, or pause for external input? If yes, LangGraph is the right choice. If no—if you're building retrieval pipelines, Q&A bots, or single-turn interactions—stick with LangChain's simpler abstractions.

For teams with existing LangChain applications, migration should be prioritized by value. The highest-priority candidates are applications that currently use hacky workarounds for agent loops, human-in-the-loop approval, or error recovery with retries. These workflows are fighting against LangChain's linear model and will benefit most from LangGraph's cyclic graph primitives. Lower priority are well-functioning RAG pipelines and simple chains—these work fine as-is.

Observability investment is non-negotiable for production LangGraph deployments. LangSmith's trace visualization has matured significantly for graph-based executions, showing cycle counts, interrupt points, and branch decisions in a comprehensible format. Spend time understanding the trace UI before deploying to production—debugging a cyclic graph without proper observability is painful.

Plan for team ramp-up time. Engineers familiar with LangChain will need 2-4 weeks to internalize graph-based design thinking. The concepts aren't harder, but they're different. State schemas, reducers, conditional edges, and interrupt handling require a mental model shift. Budget this time explicitly rather than assuming immediate productivity.

Infrastructure costs increase with LangGraph. Checkpointing requires persistent storage—PostgreSQL, Redis, or cloud equivalents—with associated database costs. State persistence means more data stored longer. Estimate 10-20% infrastructure overhead compared to stateless chains, higher for workflows with frequent interrupts and long-running threads.

For enterprise deployments, version 2.0's guardrail nodes simplify compliance requirements. Content filtering, rate limiting, and audit logging are now declarative configuration rather than custom code. If you're pursuing SOC 2 compliance for AI systems, review LangSmith's data handling policies—trace data may include sensitive information that needs appropriate handling.

What to Build This Week

Build a customer support escalation agent that demonstrates LangGraph's human-in-the-loop capabilities in a realistic context.

The agent should handle incoming support tickets through this workflow: classify the ticket severity, attempt automated resolution for low-severity issues, escalate to human review for high-severity or low-confidence responses, and loop back for additional information gathering when the human reviewer requests clarification.

Specific requirements:

Use the new interrupt() API for escalation pauses
Implement confidence-based routing (auto-resolve if confidence > 0.85, escalate otherwise)
Add a circuit breaker after 3 information-gathering loops
Configure PostgreSQL checkpointing with connection pooling
Add a guardrail node for PII detection before responses are sent

This project will exercise state accumulation (ticket history), conditional routing (severity and confidence), human-in-the-loop (escalation), loops (information gathering), and guardrails (PII filtering)—the core patterns that make LangGraph valuable in production. Aim for a working prototype by end of week, then iterate on the human review UI and observability integration.

This is part of the **Agentic Engineering Weekly* series — a deep-dive every Monday into the frameworks,
patterns, and techniques shaping the next generation of AI systems.*

Follow the Agentic Engineering Weekly series on Dev.to to catch every edition.

Building something agentic? Drop a comment — I'd love to feature reader projects.

AI Weekly: Musk Merges SpaceX with xAI, LeCun's AMI Labs Raises Record $1B Seed, and the Infrastructure Race Intensifies

Richard Dillon — Sun, 29 Mar 2026 13:59:27 +0000

AI Weekly: Musk Merges SpaceX with xAI, LeCun's AMI Labs Raises Record $1B Seed, and the Infrastructure Race Intensifies

This week marks a pivotal inflection point in AI's evolution from software phenomenon to physical-world force. Elon Musk's merger of SpaceX and xAI signals that the race to embed intelligence into hardware has officially begun, while Yann LeCun's billion-dollar bet on world models challenges the entire foundation of how we've been building AI systems. Meanwhile, the infrastructure war is heating up as NVIDIA and Amazon pour tens of billions into OpenAI, and cracks are showing in one of open-source AI's most important teams.

Elon Musk Merges SpaceX and xAI to Build Autonomous Spacecraft and Robotic Mars Colonies

Elon Musk announced the formal merger of SpaceX and xAI this week, creating what analysts are calling a potential "technological powerhouse" that combines world-leading aerospace engineering with advanced generative AI capabilities. The strategic rationale centers on embedding Grok models directly into SpaceX operations—from mission planning to real-time spacecraft decision-making.

The technical ambitions are substantial. SpaceX engineers are reportedly working to integrate Grok-3's reasoning capabilities into autonomous trajectory optimization for deep-space missions, where communication latency with Earth makes human-in-the-loop control impractical. For Mars colonization efforts, the merged entity aims to deploy AI-driven robotics capable of habitat construction, resource extraction, and maintenance operations with minimal human oversight.

Industry observers note that xAI's simulation and synthetic data generation capabilities could accelerate SpaceX's already aggressive development timeline. Training autonomous systems for Martian conditions is notoriously difficult given the lack of real-world data, but Grok's world-modeling capabilities could generate high-fidelity training environments.

The merger also consolidates Musk's AI compute resources—xAI's Memphis data center reportedly houses over 100,000 H100 GPUs—with SpaceX's operational needs. Critics point out that this vertical integration raises questions about oversight of autonomous systems making life-critical decisions in space, but Musk has historically favored speed over regulatory caution.

Yann LeCun's AMI Labs Raises $1.03 Billion Seed Round to Build World Models

Advanced Machine Intelligence (AMI Labs), the startup founded by Meta's Chief AI Scientist Yann LeCun, closed a $1.03 billion seed round this week—likely the largest seed investment ever for a European company and one of the largest globally. The 890 million euro raise signals serious investor confidence in LeCun's long-standing critique of current AI architectures.

LeCun has spent years arguing that autoregressive transformers—the foundation of GPT-4, Claude, and Gemini—are fundamentally limited in their ability to understand and reason about the physical world. AMI Labs is betting on "world models," systems that build internal representations of how reality works rather than simply predicting the next token in a sequence.

The technical approach reportedly combines Joint Embedding Predictive Architectures (JEPA) with hierarchical planning systems capable of reasoning over multiple time scales. Unlike current LLMs that struggle with basic physics intuitions, world models aim to develop the kind of causal understanding that humans acquire through embodied experience.

LeCun remains at Meta in an advisory capacity, but AMI Labs represents his opportunity to test these theories at scale without the constraints of a larger organization's product roadmap. The fundraise includes participation from several European sovereign wealth funds eager to establish a competitive AI presence outside the US-China axis. Whether world models can deliver on their theoretical promise—or whether scale is the real bottleneck after all—should become clearer within the next 18 months.

Agentic Programming Updates

NVIDIA released Nemotron 3 Super this week, featuring a hybrid mixture-of-experts (MoE) architecture specifically optimized for building high-throughput AI agents. The model activates only 17 billion of its 49 billion total parameters per forward pass, dramatically reducing inference costs while maintaining strong performance. Artificial Analysis ranked Nemotron 3 as the most open and efficient model in its class, with leading scores on coding benchmarks (HumanEval: 89.2%), reasoning tasks, and the emerging AgentBench evaluation suite.

Ai2 countered with Olmo Hybrid, a 7B-parameter model that combines traditional transformer attention with linear recurrent layers (specifically, Mamba-2 blocks). The architecture achieves roughly 2× data efficiency compared to pure transformer models of equivalent size—a significant advantage as high-quality training data becomes increasingly scarce. Olmo Hybrid scores competitively with models twice its size on agentic tool-use benchmarks.

On the framework side, Agno has emerged as the high-performance open-source Python framework for multi-agent systems. Its AgentOS runtime handles inter-agent communication, state management, and failure recovery, while the built-in FastAPI app provides immediate REST API access to deployed agents. Early adopters report 40% latency improvements over LangChain-based implementations for complex orchestration workflows.

The broader enterprise trend is unmistakable: AI is shifting from individual productivity tools (Copilot-style code completion) toward team and workflow orchestration systems. Companies are increasingly deploying agent swarms that handle entire business processes—from customer inquiry to resolution—with human oversight at strategic checkpoints rather than individual steps.

Alibaba's Qwen Team Exodus Threatens Open-Source AI Ecosystem

Major departures from Alibaba's Qwen team this week have sent ripples of concern through the open-source AI community. Following the launch of Qwen3.5-small—which achieved impressive efficiency benchmarks—several key researchers began circulating a unified message: "Qwen is nothing without its people." The coordinated messaging echoes the dramatic exodus from OpenAI during its 2023 board crisis.

Reports indicate that Alibaba Cloud leadership removed Qwen's technical lead amid internal disputes over the team's direction and resource allocation. The specifics remain murky, but sources suggest tension between Alibaba's commercial priorities and the team's commitment to open-source releases. Qwen models have been among the most capable freely available options, particularly for Chinese language tasks and efficient small-model deployments.

The open-source community's concern is justified. Qwen has filled a critical niche: high-quality small models (1.8B to 72B parameters) with permissive licenses and strong multilingual capabilities. If the team implodes, that gap won't be easily filled. Meta's Llama team operates under different constraints, Mistral has shifted toward commercial offerings, and Google's Gemma remains limited in scope.

Several departing researchers have reportedly been approached by both US and Chinese AI labs, but any reconstitution of the team's capabilities would take months at minimum. For developers who've built production systems on Qwen models, this week's news is a reminder that open-source sustainability remains fragile even when backed by corporate resources.

NVIDIA and Amazon Pour Billions into OpenAI Amid Infrastructure Race

NVIDIA committed $30 billion to OpenAI this week in what CEO Jensen Huang characterized as potentially his company's "last" major AI investment of this scale. The statement raised eyebrows—NVIDIA's cash position certainly allows for more—but Huang appears to be signaling that the infrastructure buildout phase is nearing completion.

Amazon announced a strategic partnership with OpenAI simultaneously, joining SoftBank and NVIDIA in what's becoming an unprecedented concentration of capital around a single AI company. The move is notable given Amazon's existing 21% stake in Anthropic, meaning the e-commerce giant now holds significant positions in both leading frontier AI labs.

Both OpenAI and Anthropic are reportedly planning IPOs in 2026, which would position Amazon as potentially the best-performing venture investor of the decade. The strategic logic extends beyond financial returns: Amazon Web Services gains preferred access to the most capable models for its enterprise customers, while the AI companies secure long-term compute commitments.

The infrastructure race is intensifying as training runs for next-generation models approach $10 billion in compute costs alone. NVIDIA's investment secures its hardware position in OpenAI's data centers, while Amazon's participation suggests AWS will host significant portions of OpenAI's inference workloads. For competitors without access to this capital, the path to frontier capabilities is narrowing rapidly.

Physical AI and Robotics Gaining Momentum as Scaling Hits Limits

IBM Research published a widely-circulated analysis this week predicting that 2026 marks the definitive shift toward robotics and physical AI as the industry's primary innovation vector. The thesis: pure scaling of language models is hitting diminishing returns, and the next wave of breakthroughs will come from AI systems that can sense, act, and learn in real environments.

The evidence is mounting. GPT-5's capabilities, while impressive, represent incremental improvements over GPT-4 rather than the step-function gains seen in earlier generations. Training data is becoming scarce and expensive. Inference costs, while dropping, remain substantial for reasoning-heavy applications. Meanwhile, robotics costs have declined precipitously—capable manipulation hardware now costs under $20,000—while simulation environments for training embodied agents have matured significantly.

The technical challenges of physical AI remain formidable. Real-world environments are messy, unpredictable, and unforgiving of errors. The sim-to-real gap—where policies learned in simulation fail to transfer to physical systems—hasn't been fully solved. Safety requirements for robots operating around humans add constraints that software agents don't face.

But the investment thesis is compelling: AI that can perform physical labor addresses a larger economic opportunity than AI that can write code or answer questions. Figure, Boston Dynamics, and a wave of well-funded startups are betting that 2026's advances in world models and multimodal learning will finally crack the embodiment problem.

Arkansas Deploys AI-Powered Cameras to Detect Distracted Drivers

Arkansas began deploying AI-powered cameras in highway work zones this week, targeting drivers using handheld cell phones. The system, manufactured by Acusensus, uses computer vision trained on millions of images to identify specific visual indicators of phone use while filtering out legal hands-free Bluetooth devices.

Enforcement under Act 707 begins mid-January 2026, with an initial warning period allowing drivers to receive educational notices rather than citations. The technical implementation processes images locally on edge devices, with human review required before any citation is issued. Penalties start at $250 and escalate for repeat offenses.

The privacy debates were immediate and predictable. Civil liberties advocates argue that the cameras capture far more than phone use—passenger faces, vehicle contents, and driving patterns that could be retained or misused. The legislation authorizing the cameras specified distracted driving detection, but the underlying technology is capable of much more.

Arkansas transportation officials emphasize the safety rationale: work zone fatalities have increased 40% over the past five years, with distracted driving cited as a primary factor. The cameras represent a middle ground between unenforceable bans and more invasive alternatives like phone-disabling technology. Whether other states follow Arkansas's lead will depend largely on how effectively the privacy concerns are addressed in implementation rather than legislation.

AI Costs Approaching Zero Create New Entrepreneurial Opportunities

The cost curve for AI inference continues its dramatic decline, with API pricing for GPT-4-class models now under $0.50 per million input tokens—roughly 100× cheaper than two years ago. For entrepreneurs and small businesses, capabilities that required enterprise budgets in 2024 are now accessible at near-trivial costs.

The implications are reshaping the startup landscape. Several AI-native companies have reached eight-figure annual revenue with teams under 20 people, automating functions that would have required entire departments. Customer service, legal document review, code generation, and content production are increasingly handled by AI systems with minimal human oversight.

The competitive dynamics have inverted. When everyone has access to the same powerful models at the same low prices, the differentiator isn't AI capability—it's understanding how to effectively deploy these systems. Domain expertise, workflow design, and integration with existing business processes matter more than raw model performance.

For freelancers, the calculus is similar. An independent consultant with deep expertise and sophisticated AI tooling can now deliver output that rivals small agencies. The leverage that AI provides to individuals continues to increase, even as the tools themselves become commoditized. The winners in this environment won't be those with the best AI—they'll be those who understand their domains deeply enough to know where AI creates value and where human judgment remains essential.

What to Watch

The next few weeks will be critical for several developing stories. Watch for concrete technical details from the SpaceX-xAI merger—specifically whether Grok integration begins with Starlink operations before moving to more ambitious space applications. The Qwen situation bears monitoring; if key researchers land at a single destination, we may see a spiritual successor emerge quickly. And with both OpenAI and Anthropic reportedly targeting 2026 IPOs, expect increasing financial disclosure that will finally reveal the true economics of frontier AI development.

Enjoyed this briefing? Follow this series for a fresh AI update every day, written for engineers who want to stay ahead.

Follow this publication on Dev.to to get notified of every new article.

Have a story tip or correction? Drop a comment below.