DEV Community: Pratik

How to Build Resilient AI Agents with Search Fallback Loops

Pratik — Tue, 06 Oct 2026 17:36:43 +0000

Building autonomous AI agents is incredibly rewarding until you deploy them to production and real-world data breaks your clean pipelines.
A common bottleneck is the tool execution layer. When your agent invokes a vector DB search or a live web API, it assumes it will receive relevant data. But out in the wild, APIs time out, rate limits get hit, and semantic searches frequently return empty arrays.
If your agent treats tool calls as a linear path (Query -> Result -> Next Step), an empty or broken result causes the entire system to collapse or freeze.
The solution is an Agentic Search Fallback Loop. Let's break down how it works and how to build one safely.
The Problem: The Blind Retry Trap
When developers first encounter tool failures in agents, the knee-jerk reaction is to add a simple while loop or a basic retry decorator.
python

# The Dangerous Way
while retry_count < 3:
    result = call_search_tool(query)
    if result:
        break
    retry_count += 1

Use code with caution.
If call_search_tool returns empty because the query keywords are too specific, running it three times changes absolutely nothing. You are simply burning API tokens and increasing latency for the exact same zero-value result.
The Solution: The Strategic Pivot
An Agentic Search Fallback Loop introduces an evaluation step between the failure and the retry. The agent changes its strategy based on why the tool failed.
Architectural Upgrades: Circuit Breakers and Attribution Verification
While a basic fallback loop improves resilience, true production environments require two critical safety mechanisms to avoid cascading failures and hallucinations:

The Circuit Breaker Pattern: Simply routing to a backup provider during a systemic failure can cause a "thundering herd" problem, instantly hammering and crashing your backup system during a primary outage. A robust loop must open a circuit breaker, halting calls temporarily once a failure threshold is crossed.
Attribution Verification: When you relax semantic constraints—such as lowering a vector similarity threshold—you introduce noise. This is exactly where wrong matches slip through, leading the LLM to generate highly confident hallucinations. To counter this, a post-retrieval verification step must validate that the final answer explicitly aligns with the source text. Here is a full code implementation showing how to orchestrate a fallback loop that changes its internal parameters dynamically while using a circuit breaker and source attribution grading: python

import time
from typing import Dict, Any, List

# Simulating a Circuit Breaker State to prevent cascading failures
class CircuitBreaker:
    def __init__(self, failure_threshold: int = 3):
        self.failure_threshold = failure_threshold
        self.failure_count = 0
        self.is_open = False

    def record_failure(self):
        self.failure_count += 1
        if self.failure_count >= self.failure_threshold:
            self.is_open = True
            print("🚨 [CIRCUIT BREAKER] Tripped! Halting traffic to protect infrastructure.")

    def record_success(self):
        self.failure_count = 0
        self.is_open = False

primary_breaker = CircuitBreaker()

# Simulating an external search tool that fails on hyper-specific queries
def mock_vector_search_tool(query: str, similarity_threshold: float) -> List[Dict[str, Any]]:
    if primary_breaker.is_open:
        raise Exception("Circuit breaker is open. Request blocked.")

    # Simulating an empty state for a highly restrictive query
    if "hyper-specific microservices architecture" in query.lower() and similarity_threshold > 0.75:
        return []
    # Simulating a successful match once constraints relax
    elif "microservices architecture" in query.lower() and similarity_threshold <= 0.75:
        primary_breaker.record_success()
        return [{"title": "Scalable Microservices", "content": "Production deployment strategies for Kubernetes..."}]
    return []

# Simulating an LLM call that simplifies a failing query
def llm_query_rewriter(failed_query: str) -> str:
    print(f"🔄 [LLM] Rewriting and broadening query: '{failed_query}'")
    if "hyper-specific" in failed_query.lower():
        return "microservices architecture"
    return failed_query

# Attribution Grader to prevent hallucinations from relaxed queries
def verify_source_attribution(query: str, retrieved_docs: List[Dict[str, Any]]) -> bool:
    print("🔍 [VERIFIER] Checking if relaxed documents genuinely answer the original query...")
    # Simple deterministic validation strategy (In production, use a strict micro-LLM prompt)
    for doc in retrieved_docs:
        if "microservices" in doc["content"].lower():
            print("✅ [VERIFIER] Source attribution verified.")
            return True
    print("❌ [VERIFIER] Source attribution failed. Context is irrelevant noise.")
    return False

def execute_agentic_search_loop(initial_query: str) -> Dict[str, Any]:
    current_query = initial_query
    similarity_threshold = 0.85  # Strict initial threshold

    max_retries = 3
    retry_count = 0

    print(f"🚀 Starting agentic search for: '{current_query}'")

    while retry_count < max_retries:
        retry_count += 1
        print(f"\n--- Iteration {retry_count} (Threshold: {similarity_threshold}) ---")

        try:
            # Attempt retrieval
            results = mock_vector_search_tool(current_query, similarity_threshold)

            # Check for Semantic Failure (Empty Data)
            if not results:
                print("⚠️ Search returned 0 documents. Initiating fallback logic...")

                # Tactic 1: Lower the vector search similarity threshold
                if similarity_threshold > 0.70:
                    similarity_threshold -= 0.10
                    continue

                # Tactic 2: Leverage LLM to reformulate the text query
                current_query = llm_query_rewriter(current_query)
                continue

            # Verify source attribution before passing data to the generation LLM
            if not verify_source_attribution(initial_query, results):
                print("⚠️ Retrying due to failed attribution verification...")
                similarity_threshold += 0.05  # Tighten threshold back up
                current_query = llm_query_rewriter(current_query)
                continue

            print("✅ Valid data retrieved successfully!")
            return {"status": "success", "data": results, "attempts": retry_count}

        except Exception as e:
            # Catching Systemic Failure (Network timeouts / API errors)
            print(f"💥 Systemic Error encountered: {e}")
            primary_breaker.record_failure()
            print("🔄 Gracefully degrading to static local cache instead of hammering backup...")
            return {"status": "degraded", "data": [{"title": "Cached Docs", "content": "Static fallback context"}]}

    print("\n🛑 Circuit breaker triggered. All fallback strategies exhausted.")
    return {"status": "failed", "data": [], "reason": "Max retries reached without relevant matches."}

if __name__ == "__main__":
    user_query = "Hyper-specific microservices architecture patterns for Kubernetes"
    final_output = execute_agentic_search_loop(user_query)
    print(f"\nFinal Agent Output Summary:\n{final_output}")

Use code with caution.
Breaking Down the Architecture
This implementation works where simple retry counters fail due to two specific engineering design choices:

Separation of Concerns: The code handles semantic issues (if not results) completely differently from infrastructure failures (except Exception). If an API breaks, it prevents cascading backup infrastructure crashes using a circuit breaker. If the tool works but yields nothing, it isolates the problem to search syntax and adjusts parameters.
Dynamic State Shift: Each retry uses unique state modifications. The loop alternates between lowering the similarity threshold and calling the query rewriter, maximizing the chance of a successful lookup on successive runs.
Guardrails Against Hallucination: By running a verification pass on the expanded search space data, the system ensures that looser rules do not result in garbage
context reaching the generation step.
Critical Production Guardrails
To prevent your agentic loops from running amok, you must hardcode deterministic limits directly into your tool-calling framework:
Strict Iteration Limits: Never allow more than 2 or 3 loop cycles.
Token Budgets: Track the cumulative token usage inside the loop instance; abort immediately if it crosses a pre-set threshold.
Deterministic Safe-Fails: If the final fallback attempt yields nothing, bypass the LLM entirely and return a structured fallback message (e.g., {"status": "no_records_found"}). This prevents the agent from hallucinating an answer.
The Interview Angle: System Design Focus
For engineers interviewing for advanced AI positions, understanding failure states is critical. You might face a system design question like this:
Question: "How do you design a search agent to handle zero-document retrieval states without causing infinite loops or exploding costs?"
Key points for your answer:
Explain that you avoid raw looping mechanisms because they do not address semantic text mismatches.
Detail a dynamic strategy: if a query fails, your architecture decreases the vector search similarity threshold (e.g., moving cosine similarity from 0.85 to 0.70) or switches from a dense vector search to a keyword BM25 search.
Emphasize the inclusion of an automated circuit breaker to guarantee predictable runtime costs and system safety.

Building loops that adapt to empty or broken states transforms a fragile AI script into an enterprise-grade agent. How do you handle tool degradation in your production environments? Let's discuss in the comments below.

# 🩺 I Built MediMind AI for Someone I Care About — An Open-Model Health Companion

Pratik — Sun, 04 Oct 2026 17:39:26 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.

What I Built

I built MediMind AI, a personalized health companion designed to make medical information easier to understand.

I built it for a real person close to me who found it difficult to understand medical information and turn reports, symptoms, and medication information into clear next steps.

Instead of creating another generic AI chatbot, I wanted to build something practical: a health-information assistant that combines personalization, retrieval, citations, and safety checks.

MediMind includes:

AI Health Assistant
Medical report analysis
Symptom analysis
Medication information
Medication reminders
RAG-based medical knowledge retrieval
Source and citation support
Emergency/safety triage
Health history and vitals
Personalized care context
Saved reports and health information

The goal is not to diagnose someone. The goal is to make medical information easier to understand and help people prepare better questions for healthcare professionals.

Demo

🌐 Live Demo:
https://meed-mind-ai.vercel.app

The main demo flow is:

Create Care Profile → Ask a health question → Retrieve relevant medical context → Generate an explanation using an open-weight model → Show supporting sources → Apply safety checks

Code

💻 GitHub:

pratikraut8889-max / MeedMind-AI

An AI-powered second opinion and accessibility tool helping patients understand medical reports in any language.

MediMind AI - Production Retrieval-Augmented Generation (RAG) Architecture

MediMind AI implements a production-quality, real clinical retrieval layer designed to ensure every medical answer is grounded in authoritative, peer-reviewed clinical guidelines, and that no sources or citations are ever fabricated.

1. End-to-End RAG Architecture

User Question
      │
      ▼
1. Query Processing
   ├── Text Normalization & PII Sanitization
   ├── Medical Taxonomy & Synonym Expansion (AHA, CDC, NIH terms)
   ├── Intent Classification (emergency, diagnostic, medication, lifestyle)
   └── Dense Embedding Generation (gemini-embedding-2-preview)
      │
      ▼
2. Pluggable Medical Retriever (IMedicalRetriever)
   ├── Semantic Cosine Similarity (Dense Vector Search)
   ├── Lexical & Clinical Tag Overlap Matching
   └── Hybrid Scored Ranking: 0.65 * denseSimilarity + 0.35 * lexicalScore
      │
      ▼
3. Relevant Medical Documents
   └── Scored & Ranked Chunks with Document Identifiers & Metadata
      │
      ▼
4. Context Filtering Layer
   ├── Strict Relevance Thresholding (default minRelevanceScore = 0.58)
   ├── Low-Quality / Irrelevant Query Suppression
   ├── Token-Budget Aware Deduplication

…

View on GitHub

How I Built It

MediMind is built with:

React
TypeScript
Vite
Express
Firebase / Firestore
RAG-based retrieval
Open-weight AI
Open embeddings
Deterministic medical safety and triage logic

The architecture is designed so that the AI model is not tightly coupled to a single vendor.

User
  ↓
React UI
  ↓
Express API
  ↓
Safety / Triage
  ↓
RAG Retrieval
  ↓
Medical Context
  ↓
Open-Weight Model
  ↓
Structured Output Validation
  ↓
Citation Validation
  ↓
Safe Response
  ↓
User

The AI is surrounded by safety and validation layers rather than being treated as an unquestionable medical authority.

Why Open Innovation Matters

This project is especially interesting to me because the AI layer is built around an open-weight model rather than making the entire application dependent on a single closed AI API.

Using an open model gives the project a more flexible architecture.

The model can be changed without rebuilding the whole application. Different inference environments can be evaluated, the AI layer can be adapted for different deployments, and developers have more control over how the model is integrated into the product.

For a health-focused application, this flexibility matters because health information can be sensitive.

MediMind also combines the model with retrieval and citation validation so that the AI is grounded in relevant medical information instead of simply being treated as the source of truth.

The “Build for a Friend” Part

The idea started from a simple problem: medical information is often difficult for non-medical people to understand.

I wanted to turn that problem into something useful for someone close to me rather than building an AI demo without a real user in mind.

The project therefore focuses on making reports, symptoms, medications, and health information easier to understand while keeping medical safety at the center.

The person I built it for:
[Write their real relationship here, e.g. “my cousin”]

The problem they actually have:
[Write their real problem here in one sentence]

I intentionally kept the application focused on explanation and decision support rather than presenting it as a replacement for a doctor.

Safety

MediMind is not a doctor and does not replace professional medical care.

The application includes a dedicated safety/triage layer for potentially urgent situations. High-risk inputs can be handled before the normal conversational response flow.

The system is designed to:

recognize potentially urgent situations
avoid presenting AI output as a diagnosis
ground responses using retrieved information
validate citations
encourage professional medical care when appropriate

This project is a health-information and decision-support tool, not a medical device or substitute for a licensed healthcare professional.

What Open AI Made Possible

The biggest architectural benefit of using an open-weight model is that MediMind is not built around one permanent AI vendor.

The application can evolve from one open model to another without rewriting the entire product:

Open Model A
     ↓
Provider Abstraction
     ↓
   MediMind
     ↑
Open Model B

This makes experimentation, model replacement, and future deployment options much easier.

It also makes the AI layer a replaceable component rather than a hard-coded dependency.

My Agent Session

I used AI-assisted development while building the project and focused on keeping the important decisions, safety logic, and application architecture understandable and reproducible.

[Add your DevRelay / agent session link here if you have one.]

Prize Category

Best Use of Gemma

MediMind uses an open-weight model as its core AI layer and combines it with RAG, personalization, and safety validation.

What's Next

The current version focuses on making health information more understandable for a person close to me.

The longer-term goal is to make MediMind a privacy-conscious, customizable health companion where the AI model, retrieval system, and safety layer can continue to evolve independently.

Research Dossier — Vibe-Coding a Case File, Then Teaching It to Hold Its Own Workflow

Pratik — Sat, 03 Oct 2026 17:47:13 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

A note up front: this extends the same codebase as my Path One submission — one project, two angles. Path One is about the agent and the structured content it reasons over. This post is about the other half: how the app itself got built almost entirely through prompting, and what it took to push past a read-only frontend into something with a real Sanity-backed workflow.

What I Built

Research Dossier is a Next.js app, Sanity behind it, built through iterative conversational prompting rather than hand-writing the UI from scratch. The interface is deliberately not a blog-template look: a two-pane "case file" layout — a terminal-style live log on the left showing agent progress, a paper-dossier report on the right with a hand-stamped "CONTESTED" mark when sources disagree, custom ink/paper/gold color tokens, serif body type paired with monospace for the log — none of it from a component library's defaults.

For this path specifically, I pushed further than the Path One version: the system now models its own approval workflow as real Sanity content, not just UI state.

Demo

Live app: https://multi-agent-research-analyst.vercel.app/

Ask a question, watch the agents work in the case log, review the draft, click approve — then visit /cases to see the same investigation listed with a status badge that flips from draft to approved. Open Sanity Studio and you'll find the same document, same transition, visible there too.

Code

https://github.com/pratikdevelop/multi-agent-research-analyst

My Build Process

This was built in long back-and-forth passes rather than one clean generation, and most of the real work was debugging what got generated, not writing it from scratch. A rough timeline of what actually broke and got fixed along the way:

State/node name collision — LangGraph refused to compile because a node was named the same as a state channel (research, analysis). Not obvious from the error message's framing at first; fixed by renaming nodes to research_agent, analysis_agent, etc.
Model availability churn — the first two Groq model names I tried (llama-3.3-70b-versatile, then llama-3.1-8b-instant) weren't actually available on my account's model list, discovered only by hitting /v1/models directly and reading what my key could actually see. Landed on openai/gpt-oss-20b.
A real empty-research bug — the agent's tool-call loop wasn't feeding tool results back to the model, so research came back blank and every downstream agent had nothing to work with. Had to rewrite the loop to actually execute tool calls and continue the conversation.
A Sanity auth error that turned out to be a project-ID/org-ID mixup — "Session does not match project host" traced back to the request URL hitting the org ID instead of the project ID, both of which were sitting right next to each other on the same dashboard screen.
A null-crash in production — contradicts[]->{...} returns null in GROQ when the field was never set, not []. Crashed the Knowledge Base browser page until guarded.
Vercel deploy failures, three different ones in a row — a stray output: 'export' in next.config.js that forced static export and broke every API route; a peer-dependency conflict needing --legacy-peer-deps set via .npmrc AND the Vercel install-command override, since one alone didn't stick; then a stale production deployment pointing at an old build while the working one sat under "Preview."
The MCP swap — once Sanity Context was enabled on my org, swapping the research agent from a direct GROQ query to the real Context MCP endpoint meant discovering the actual tool name it exposes (knowledge_base_read) and that it serves a /initial-context grounding endpoint worth injecting into the system prompt — neither of which is obvious without just connecting and inspecting what comes back. Kept the GROQ version as an automatic fallback rather than a hard cutover.
The Workflow feature, for this path specifically — added a caseReport document type with a status field (draft → approved), a write-scoped Sanity client kept deliberately separate from the read-only one used for research, and two API routes: one that persists the agent's draft the moment it's ready, one that patches the same document to approved when a human closes the case. The /cases page and Sanity Studio both show the same transition, because it's the same document.

How I Used Sanity — Workflow

Three document types: topic, source, claim (the Path One side), plus caseReport for this path — question, draftText, finalText, status, createdAt, approvedAt.

The workflow itself is two writes against one document: the research/writing/review pipeline creates it with status: "draft", and a human approving (or editing, then approving) in the UI patches the same document to status: "approved" with the final text and a timestamp. No separate "approval" document, no external state machine — the content is the workflow state, which is the same philosophy as the contradicts field in the Path One schema: make the thing you care about tracking an explicit field, not something inferred.

I didn't build an App SDK component for this submission — Workflows was the deeper of the two bonuses I had time to do properly, and the challenge notes doing one well beats doing both shallowly.

Sanity Project Details

Project ID: 4kagnnrl

Stop Overpaying for APIs: When to Swap Your Cloud LLM for a Local SLM 🛠️

Pratik — Sat, 03 Oct 2026 07:24:20 +0000

Let's face it: using an enterprise cloud LLM API to parse basic JSON, route support tickets, or clean up markdown is massive overkill. It's slow, expensive, and leaves your app vulnerable to third-party downtime.
If you haven't looked at Small Language Models (SLMs) recently, it's time to check them out.

+-------------------+-------------------------+-------------------------+

| Feature           | Cloud LLM               | Local SLM (<15B)        |
+-------------------+-------------------------+-------------------------+

| Deployment        | Cloud API Only          | Local, Edge, On-Prem    |
| Latency           | High (Network bound)    | Low (Local hardware)    |
| Data Privacy      | Third-party risk        | 100% Secure / Offline   |
| Cost Structure    | Pay-per-token           | Fixed Compute / Free    |
+-------------------+-------------------------+-------------------------+

🧠 The Developer's Playbook: Where to Draw the Line

🟩 When to stay with an LLM:

You need deep, multi-step zero-shot reasoning.
You are generating complex, multi-file code structures.
You need massive, 100k+ token context windows.

🚀 When to drop in an SLM:

You are building specialized AI agents with fixed, repeatable tools.
You need real-time, low-latency performance on edge devices or mobile.
You handle sensitive user text / PII that cannot legally leave your server.

🛠️ Setting It Up Locally: Asynchronous Log Parsing with FastAPI

With ecosystem tools like Ollama, vLLM, and LangChain, spinning up a local SLM (like Llama-3-8B or Phi-3) takes minimal configuration.

Instead of a basic script, let's build a production-ready asynchronous FastAPI endpoint. It consumes raw streaming application log entries, extracts entities using structured Pydantic schemas, and outputs clean JSON entirely offline.

# pip install fastapi uvicorn langchain-ollama langchain-core pydantic
import uvicorn
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel, Field
from langchain_ollama import OllamaLLM
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import JsonOutputParser

app = FastAPI(title="Local SLM Inference Gateway")

*1. Define input contract and expected structured output schema
*

class LogPayload(BaseModel):
    raw_log: str = Field(..., example="[ERROR] auth_service: JWT verification failed - Signature expired")

class LogAnalysis(BaseModel):
    status: str = Field(description="Must be exactly 'SUCCESS', 'WARN', or 'ERROR'")
    anomaly_detected: bool = Field(description="True if unexpected or malicious behavior is found")
    summary: str = Field(description="A concise 1-sentence engineering breakdown of the issue")

2. Initialize local SLM (Requires Ollama running locally with the target model). Setting temperature=0.0 ensures highly deterministic JSON structures

try:
    local_slm = OllamaLLM(model="llama3:8b", temperature=0.0)
except Exception as e:
    print(f"Warning: Ensure Ollama is running locally. Error: {e}")

*3. Formulate strict extraction prompt instructions
*

prompt = ChatPromptTemplate.from_template(
    "You are a specialized security agent. Analyze the following application log snippet. "
    "Extract information matching the structural requirements schema.\n\nLog: {log_entry}"
)

*4. Chain components together using LCEL (LangChain Expression Language)
*

log_chain = prompt | local_slm | JsonOutputParser(pydantic_object=LogAnalysis)

@app.post("/api/v1/analyze-log", response_model=LogAnalysis)
async def analyze_application_log(payload: LogPayload):
  """
    Asynchronously swallows raw streaming logs, routes them to the local 
    SLM core loop, and yields structured JSON insights with near-zero latency.
    """
    try:
        # Await chain execution inside FastAPI's async execution loop
        structured_response = await log_chain.ainvoke({"log_entry": payload.raw_log})
        return structured_response
    except Exception as e:
        raise HTTPException(status_code=500, detail=f"SLM Engine Inference Failure: {str(e)}")

if __name__ == "__main__":
    uvicorn.run(app, host="0.0.0.0", port=8000)

Your network latency drops to the floor, your third-party API billing statement hits exactly zero, and your monitoring microservice runs securely behind air-gapped on-prem environments.

What's your go-to local model right now? Are you team Llama, Mistral, or running something even lighter on the edge? Drop your stack and your token-per-second benchmarks below! 👇

The Rise of AI Coding Agents: From Code Completion to Autonomous Software Engineering

Pratik — Fri, 02 Oct 2026 04:17:38 +0000

Software development is entering a new phase.
For years, AI coding tools were primarily focused on autocomplete, code generation, and answering programming questions. Today, products such as OpenAI Codex, Anthropic's Claude Code, and Google's Antigravity ecosystem are increasingly designed around a different idea: give an AI a software task and let it plan, modify files, use tools, run code, test its work, and iterate.
The interesting shift is not simply that AI can write more code.
It is that AI is becoming an active participant in the software development workflow.
From Copilot to Coding Agent
The traditional AI coding workflow looks something like:

Developer → Prompt → Code Suggestion → Developer Review

Agentic coding changes the loop:

Developer → Goal → Agent → Plan → Code → Run → Test → Iterate → Result

That difference matters.
A coding agent needs to understand the repository, maintain context across multiple steps, interact with development tools, and decide what to do next rather than simply generate a code snippet.
OpenAI's current Codex product, for example, is designed to handle engineering tasks such as features, refactors, migrations, and other repository-level work, including parallel work across environments.

OpenAI Codex: Moving Toward End-to-End Development OpenAI has continued expanding Codex beyond individual coding requests. With GPT-5.3-Codex, OpenAI described Codex as having stronger agentic capabilities across coding, web development, and broader computer-based work. The Codex app also introduced workflows for managing multiple agents and running work in parallel, while later updates added features such as Goal mode, improved browser interactions, and longer-running workflows. The important change is the abstraction level. Instead of asking: "Write this function." Developers can increasingly ask: "Implement this feature, run the tests, fix the failures, and prepare the change." That is much closer to delegating a software task than generating code.
Claude Code: The Terminal Becomes an Agent Workspace

Anthropic has taken a similar approach with Claude Code.
Claude Code is built around working directly with repositories, terminals, development tools, and longer-running tasks. Anthropic has continued expanding its autonomy and development capabilities, including support for longer sessions and autonomous operation.
Anthropic has also introduced Claude Code Security, which can scan codebases for vulnerabilities and suggest targeted patches for human review.
This is an important development because the coding agent is becoming involved not only in writing code, but also in reviewing and improving software quality.

Google: Agent-First Development with Antigravity Google is approaching the same problem through its Antigravity development platform. Google describes Antigravity as an agent-first development environment where agents can plan, execute, and verify complex tasks across the editor, terminal, and browser. Google's 2026 developer updates expanded this approach with Antigravity 2.0 and Antigravity CLI, including support for specialized subagents and built-in controls such as terminal sandboxing, credential masking, and hardened Git policies. Google also released Gemini 3.7 Flash, positioning it specifically for coding and agent workflows, with improvements in debugging, issue resolution, web development, and long-horizon engineering tasks. The direction is clear: the IDE is becoming less of a place where humans manually write every line and more of a workspace where humans supervise AI-driven development workflows.
The Real Innovation Is the Agent Loop

The most important part of these tools isn't raw code generation.
It is the loop around generation:
Understand → Plan → Execute → Observe → Test → Correct → Repeat
A useful coding agent must be able to answer questions such as:
What files are relevant?
What is the existing architecture?
What dependencies are required?
Did the implementation actually work?
Which tests failed?
What should be changed next?

This is why context, tool use, execution environments, testing, and memory are becoming as important as the underlying model.

Software Engineering Is Becoming More Supervisory

This does not necessarily mean developers disappear.
Instead, the developer's role can move higher up the abstraction stack.
Rather than spending all of their time writing individual functions, developers may increasingly spend more time:
Defining requirements → Designing architecture → Setting constraints → Reviewing agent output → Validating behavior
That makes engineering judgment even more important.
The question becomes not only:
"Can the AI write this?"
but also:
"Did it build the right thing, within the right constraints?"

The Production Challenge

As coding agents become more autonomous, new engineering challenges appear.
How do you control what an agent can access?
How do you prevent destructive commands?
How do you track every action?
How do you review changes created by multiple agents?
How do you manage secrets and credentials?
How do you know when an agent is stuck in a loop?
OpenAI's own documentation on running Codex safely highlights the need for technical boundaries, approval requirements, access controls, and telemetry when deploying coding agents in real workflows.
So the future of AI-assisted development isn't only about better models.
It is also about better agent infrastructure.
The Bigger Picture
The evolution looks something like this:

Autocomplete
   ↓
AI Coding Assistant
   ↓
Repository-Aware Coding Agent
   ↓
Multi-Agent Development
   ↓
Autonomous Software Engineering Workflows

This changes the economics and workflow of software development, but it also introduces a new layer of engineering complexity.
The goal isn't simply to build an agent that can write code.
The goal is to build a system that can reliably understand a task, execute it, verify the result, recover from failure, and remain within clearly defined boundaries.
That is where AI coding is heading.
And the next big question isn't:
"Can AI write software?"
It is:
"How much of the software development lifecycle can an AI agent reliably own?"

🚀 OpenAI’s Agent Era: Agents API, Dots, GPT-6 Sol & More

Pratik — Thu, 01 Oct 2026 19:15:44 +0000

AI development is rapidly moving from chat-based assistants to autonomous agent systems.

OpenAI's latest announcements provide a good example of this shift.

At DevDay 2026, OpenAI announced more than 20 updates covering models, ChatGPT, Codex, APIs, and developer tools.

Here are the major developments developers should know about.

Agents API 🤖

The Agents API is now available in public beta.

It allows developers to build and run cloud agents using infrastructure designed for long-running agent workflows.

Key capabilities include:

Tool usage
File handling
Code execution
Context management
Subagents
Long-running execution

OpenAI says the infrastructure is based on the harness used to power Codex.

The interesting part is that developers don't necessarily need to build the entire runtime layer themselves.

Dots: Always-On Agents 🔄

OpenAI introduced Dots, which it describes as always-on agents designed to work continuously on users' behalf.

This introduces a different interaction model:

Traditional AI

User → Prompt → AI → Response

versus:

Agentic AI

User → Goal
          ↓
       Agent
          ↓
   Tools + Context
          ↓
      Actions
          ↓
     Result

The second model is much closer to software automation than traditional conversational AI.

GPT-6 Sol and Luna 🧠

OpenAI has also introduced GPT-6 Sol and Luna, offering different balances of capability and cost.

For developers, model selection increasingly becomes an architecture decision.

The question isn't simply:

Which model is smartest?

It becomes:

Which model provides the right capability, speed, and cost for this task?

Codex + Developer Tooling 💻

OpenAI continues expanding Codex and its developer platform, with DevDay announcements covering improvements across coding workflows, APIs, and agent development.

This points toward AI coding systems that can handle increasingly complete development workflows rather than only generating individual snippets.

What Developers Should Watch 🔍

The emerging AI application stack increasingly looks like:


             AI Models
                 ↓
            Agent Runtime
                 ↓
       Tools + Code Execution
                 ↓
        Context + Memory
                 ↓
       Security + Permissions
                 ↓
       Monitoring + Evaluation
                 ↓
            Production

The difficult part of AI development is increasingly shifting from model access to reliable orchestration.

Conclusion

OpenAI's recent releases show how quickly agent infrastructure is developing.

We're moving from:

“Ask AI a question.”

toward:

“Give AI a goal and let it work.”

That shift could have significant implications for software developers, startups, and enterprise applications.

The key engineering challenge now is not just making agents capable.

It's making them reliable, controllable, secure, and useful in production.

What are you building with AI agents right now?

OpenAI #AIAgents #DevDay2026 #AgentsAPI #GPT6 #Codex #AI #Programming #WebDevelopment

🛠️ LangChain’s Latest Agent Infrastructure: Engine v2, Managed Deep Agents, SmithDB & More

Pratik — Thu, 01 Oct 2026 19:09:27 +0000

Building an AI agent is getting easier.

Running one reliably in production is still the hard part.

At Interrupt 2026, LangChain introduced a major set of updates focused on production agent infrastructure. Since then, the platform has expanded further with LangSmith Engine v2, public beta access for Managed Deep Agents, and additional governance capabilities.

Here’s the current stack developers should know about.

LangSmith Engine v2 🚀

The original LangSmith Engine was introduced at Interrupt 2026 to help teams analyze production traces, identify recurring failures, diagnose root causes, and propose fixes.

Engine v2, released in September 2026, goes further:

🔴 Proactively red-teams agents to identify potential issues before they appear in production.
📉 Detects inefficient agent trajectories and trends in error rate, latency, and cost.
🧪 Automatically tests proposed prompt and code fixes before human review.
🔄 Reproduces failures, tests fixes, evaluates the results, and then surfaces validated changes for review.

That makes the development loop much more automated:

> Production traces
>       ↓
> Issue detection
>       ↓
> Root-cause analysis
>       ↓
> Proposed fix
>       ↓
> Automated validation
>       ↓
> Human review

SmithDB ⚡

Agent traces are becoming much larger and more complex than traditional application logs.

SmithDB is LangChain’s purpose-built database infrastructure for agent observability. It is designed for workloads involving deeply nested spans, long-running operations, full-text search, JSON filtering, and trace reconstruction.

LangChain reports up to 15× faster performance on core LangSmith workloads compared with its previous infrastructure.

Managed Deep Agents 🤖

Running long-lived autonomous agents yourself means managing:

Runtime infrastructure
Persistence
Checkpointing
Memory
Tool execution
Sandboxes
Streaming
Observability

Managed Deep Agents moves much of that operational layer into a hosted LangSmith runtime.

Developers can define agents using the Deep Agents framework and deploy them without building and maintaining their own agent server infrastructure. Managed Deep Agents became available in public beta in August 2026.

Production Sandboxes 🔒

Giving an AI agent the ability to execute code introduces obvious security concerns.

LangSmith Sandboxes, which reached GA at Interrupt 2026, provide isolated execution environments for workloads involving generated code, shell commands, files, dependencies, and data analysis.

The environments use hardware-virtualized microVMs for stronger isolation from your main infrastructure.

Enterprise Governance 📊

Production agents also need controls around cost, data, permissions, and context.

LLM Gateway

LangSmith’s LLM Gateway sits between agents and model providers and provides controls such as:

Spend limits
Rate limits
Model fallbacks
PII and secret redaction
Centralized usage visibility

The Gateway entered public beta in July 2026.

Context Hub

Context Hub provides a centralized way to manage and version the files and information that shape agent behavior, including instructions, policies, examples, and skills.

Messages View

For complex agent workflows, Messages View makes multi-turn traces easier to read and understand, reducing the friction of debugging long agent sessions.

🔍 Why This Matters

The interesting part isn't any single feature.

The bigger story is that agent infrastructure is becoming a full production stack:

   AI Models
            ↓
     Agent Runtime
            ↓
   Tools + Memory + Files
            ↓
      Secure Sandbox
            ↓
 Observability + Evaluation
            ↓
 Governance + Cost Controls
            ↓
      Production Scale

We're moving from “build an agent” to “operate an autonomous system.”

That changes the engineering questions too.

It's no longer only:

Which model should I use?

It's also:

How do I monitor the agent?
How do I test it?
How do I control its cost?
How do I secure tool execution?
How do I recover from failures?
How do I improve it continuously?

That is where the next generation of agent infrastructure is being built.

What’s your take? Are you moving toward managed agent runtimes, or do you prefer to keep the runtime infrastructure self-hosted?

Jev vs LLMs: Why AI Agents May Need a Decision Layer

Pratik — Thu, 24 Sep 2026 02:56:52 +0000

Jev vs LLMs: Why AI Agents May Need a Decision Layer

Here's an uncomfortable pattern in modern AI applications:

User input
   ↓
LLM
   ↓
generated text
   ↓
parser
   ↓
application logic
   ↓
action

We're often using a general-purpose language model to make a tiny decision.

Should we retry?

Should we escalate?

Which tool should we call?

Which model should handle this?

Should this request be blocked?

Those are not necessarily generation problems.

They're decision problems.

That's where Jev, TypeSafe AI's first System One model, gets interesting.

TypeSafe introduced Jev in September 2026 as a model designed around structured decisions rather than open-ended string generation.

The core idea

The simplest mental model is:

Traditional LLM:

state → generated string


System One:

state → typed decision

Jev's developer documentation describes the interface as:

Input:
Text / JSON / text arrays

Output:
Choice / Score / Noul

Control flow:
Your application

That last line matters.

The model doesn't own your application flow.

Your code does.

Jev vs LLM

Let's make the difference concrete.

LLM approach

Suppose an agent receives:

The customer says:

"I was charged twice for the same order.
Please refund the duplicate payment."

You might ask an LLM:

Classify this request and return JSON.

Then receive:

{
  "team": "billing",
  "urgent": true,
  "confidence": 0.96
}

Looks great.

But your application is now depending on:

prompt instructions
generated output
schema adherence
parsing
interpretation
potentially unnecessary text generation

Jev approach

Define the decisions your application actually needs.

Question 1:
Which team should handle this?

Choices:
billing
technical
general

And:

Question 2:
Should this request be considered urgent?

Noul:
yes / no

And perhaps:

Question 3:
How frustrated is the customer?

Score:
0 = low
1 = medium
2 = high

The result can be consumed directly by application code.

Conceptually:

state
  │
  ├── Choice → billing
  │
  ├── Noul   → 0.88
  │
  └── Score  → 1.7

Jev's current developer materials document these three output types and probability/confidence information.

A practical agent architecture

Here's where this becomes more interesting.

Imagine an agent proposes:

{
  "tool": "delete_project",
  "project": "production"
}

Don't let the model directly execute it.

Instead:

                 ┌───────────────┐
                 │   AI Agent    │
                 │   proposes    │
                 │   tool call   │
                 └───────┬───────┘
                         │
                         ▼
                 ┌───────────────┐
                 │     Jev       │
                 │   Decision    │
                 └───────┬───────┘
                         │
             ┌───────────┼───────────┐
             ▼           ▼           ▼
           ALLOW       REVIEW       BLOCK
             │           │           │
             ▼           ▼           ▼
           execute      human        stop

The important architectural rule is:

Jev decides. Code controls.

Your deterministic application layer should still own authorization, thresholds, audit logs, and side effects.

Code example

The exact SDK syntax can change, so treat this as an architectural example rather than a copy-paste contract:

decision = jev.decide(
    state=agent_state,
    questions={
        "tool_policy": {
            "type": "choice",
            "instructions": "Should this tool call execute?",
            "choices": {
                "allow": "Safe and authorized",
                "review": "Human approval required",
                "block": "Do not execute"
            }
        }
    }
)

choice = decision["tool_policy"]["choice"]
confidence = decision["tool_policy"]["confidence"]

if choice == "allow" and confidence >= 0.90:
    execute_tool()

elif choice == "review":
    request_human_approval()

else:
    block_tool()

Notice something important:

The model doesn't get to decide what 0.90 means.

The developer does.

That's the difference between an AI prediction and an application policy.

Why probabilities matter

Suppose Jev returns:

allow  = 0.94
review = 0.04
block  = 0.02

Your application might decide:

if confidence >= 0.90:
    execute()
else:
    human_review()

Another application might require:

if confidence >= 0.995:
    execute()
else:
    human_review()

Same model.

Different risk tolerance.

This makes the model a component inside a larger control system rather than the system itself.

And that's exactly the kind of workflow TypeSafe describes for System One models.

Choice vs Score vs Noul

A useful way to think about Jev's interface is:

Choice

Use when you need:

A / B / C

Example:

Which model should process this request?

fast
deep
human

Score

Use when you need:

How much?

Example:

How urgent is this request?

0 = low
1 = medium
2 = high

Noul

Use when you need:

Yes / No

Example:

Should this request be escalated?

Jev's current documentation describes Noul as a value from 0 to 1 for binary questions.

Where Jev could fit

This architecture opens up some interesting use cases.

1. Agent routing

request
   ↓
Jev
   ↓
simple ──────→ cheap model
complex ─────→ reasoning model
uncertain ───→ human

2. Tool verification

proposed tool call
       ↓
      Jev
       ↓
allow / review / block

3. Retry control

failed request
      ↓
     Jev
      ↓
retry / change strategy / stop

4. Support automation

message
   ↓
Jev
   ├── billing
   ├── technical
   └── general

5. Search ranking

query + result
       ↓
      Jev
       ↓
relevance score

The Jev community is already experimenting with agent routing, browser automation, compaction, MCP tools and other integrations.

But Jev isn't a replacement for an LLM

This is probably the most important point.

Don't think:

Jev > LLM

Think:

Jev + LLM + code

A general-purpose LLM is still the natural component for things like:

writing
conversation
code generation
open-ended reasoning
planning
summarization

A decision model is useful when the application already knows the possible decisions.

So:

LLM:
"Write a response to the customer."

Jev:
"Which queue should handle this?"

Code:
"Actually execute the routing."

Different problems.

Different interfaces.

What makes this technically interesting?

TypeSafe describes Jev as using a different architecture and training approach called Reinforcement Learning for Calibrated Decisions (RLCD). The company says Jev produces probabilities in parallel rather than autoregressively generating a string token by token.

That's a fundamentally different optimization target.

Instead of:

maximize useful generated sequence

the goal becomes closer to:

produce useful + calibrated decisions

The tradeoff is obvious too:

You give up general string generation.

In exchange, the model is specialized for the decision interface.

The performance claim

TypeSafe currently advertises Jev as dramatically faster and cheaper than LLMs for its System One workflows, including a headline comparison of 193.6× faster and 444.6× cheaper on its site.

Those are TypeSafe's reported results, not an independent benchmark.

That's an important distinction.

Before putting Jev in a production workflow, I'd measure:

latency
accuracy
calibration
cost
failure modes
distribution shift
human escalation rate

on your own data.

The Jev developer materials also recommend representative testing and human review for uncertain/high-impact cases.

The bigger idea

We've spent years making AI models increasingly good at producing text.

But production software isn't made entirely of text.

It's made of decisions:

route
retry
approve
reject
escalate
rank
stop
continue

Maybe the next evolution of AI applications isn't:

One giant model that does everything.

Maybe it's:

             ┌────────────┐
             │     LLM    │
             │  Generate  │
             └─────┬──────┘
                   │
                   ▼
             ┌────────────┐
             │    Jev     │
             │   Decide   │
             └─────┬──────┘
                   │
                   ▼
             ┌────────────┐
             │    Code    │
             │   Control  │
             └─────┬──────┘
                   │
                   ▼
                 ACTION

LLMs generate.

Decision models decide.

Code controls.

That's a much more interesting architecture for AI agents than simply throwing a bigger prompt at a bigger model.

And that's why Jev is worth experimenting with.

Try it, benchmark it, break it, and see where the decision primitive actually belongs in your stack.

[Boost]

Pratik — Wed, 23 Sep 2026 17:51:31 +0000

Sanity Challenge Path One Submission

Pratik

Sep 20

Research Dossier: An Agent That Shows Its Disagreements Instead of Hiding Them

#devchallenge #sanitychallenge #sanity #ai

5 min read

Research Dossier: An Agent That Shows Its Disagreements Instead of Hiding Them

Pratik — Sun, 20 Sep 2026 18:09:29 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content

What I Built

Research Dossier is a multi-agent research analyst built with LangGraph.

Instead of asking one model to answer a research question from its own knowledge, the system routes the question through four stages:

Research → Analysis → Writing → Review

The research stage is grounded in a Sanity Knowledge Base, queried directly via GROQ. Sanity Context wasn't yet enabled on my org during the build window, so the research agent's tool talks to Sanity's Content API directly rather than through the managed Context/MCP layer. The tool is isolated behind a single function, so swapping it for the Sanity Context MCP endpoint later is a contained change, not a rewrite of the agent's reasoning logic.

The interesting problem I wanted to solve is not simply finding information. It is handling situations where the sources themselves disagree.

When conflicting claims are found, Research Dossier does not silently merge them into one confident answer. It preserves the disagreement, shows the sources behind the claims, and marks the final report:

CONTESTED

The Problem

My Knowledge Base contains multiple pieces of evidence about LangGraph checkpoint deserialization.

One source is the LangGraph documentation itself, which implies checkpointing "just works" safely out of the box. Another is the official security advisory for CVE-2026-28277, which documents unsafe msgpack deserialization by default and describes strict-mode and allowlist-based hardening. A third source is a second advisory database's framing of the same CVE, which tempers the risk with essential context — it's classified as a defense-in-depth issue requiring an attacker to already have privileged write access, not a standalone remote exploit. A fourth is a community checkpointer implementation, which raises the separate question of whether that hardening even reliably extends to third-party backends.

The system keeps all of these claims and their provenance distinct, rather than flattening them into one answer.

That matters because a normal keyword search can find all of these pieces of information without preserving the relationships between them.

Research Dossier treats disagreement as structured information instead of noise.

Demo

Live app: https://multi-agent-research-analyst.vercel.app/

Try one of the built-in example questions, or ask:

Does LangGraph handle checkpoint deserialization safely by default?

Watch the case log as the system progresses through Research → Analysis → Writing → Review, with each step's output expandable if you want to see the full reasoning. Once a draft is ready, it enters a human-approval step — you can review or edit it before the case is closed and the final dossier is rendered. The report preserves the conflicting evidence and distinguishes stronger sources from lower-trust material instead of flattening everything into one conclusion, and stamps the report CONTESTED when sources disagreed.

You can also browse the raw Knowledge Base directly at /sources — every claim, its source, and what it contradicts, without needing to ask a question first.

Why Keyword Search Isn't Enough

A keyword search can return documentation, security advisories, and community discussions that mention checkpoint serialization.

The problem is that matching text does not tell the agent how those pieces of information relate to each other.

Research Dossier retrieves structured claims together with:

their sources,
source trust information,
and relationships between claims.

That lets the analysis stage reason about disagreement rather than simply presenting a list of matching passages.

The result can be explicitly marked CONTESTED when the evidence remains in conflict.

How I Used Sanity

I modeled the Knowledge Base around three core document types:

topic
source
claim

The key relationship is:
claim
└── contradicts → claim

This makes disagreement machine-readable. Instead of asking an LLM to infer whether two unrelated passages appear to disagree, the content model explicitly represents that relationship.

A claim also references its source, allowing the research pipeline to retain provenance while moving from retrieval to analysis to writing and review.

Retrieval Layer

The research agent's tool queries the Knowledge Base directly via GROQ, expanding topic, source, and contradicts[]->source in a single request:

LangGraph
│
▼
Research Agent
│
▼
GROQ query (@sanity/client)
│
▼
Sanity Knowledge Base

This retrieval layer is deliberately isolated behind a single tool function — swapping it for the Sanity Context MCP endpoint is a contained change, not a rewrite of the agent's reasoning logic.

Architecture

                 User Question

                      │

                      ▼

               ┌──────────────┐

               │   Research   │

               │    Agent     │

               └──────┬───────┘

                      │

                      ▼

            ┌────────────────────┐

            │   GROQ Query Layer │

            └─────────┬──────────┘

                      │

                      ▼

            ┌────────────────────┐

            │ Sanity Knowledge   │

            │       Base         │

            │                    │

            │ claims + sources + │

            │ contradictions     │

            └─────────┬──────────┘

                      │

                      ▼

               ┌──────────────┐

               │   Analysis   │

               └──────┬───────┘

                      ▼

               ┌──────────────┐

               │   Writing    │

               └──────┬───────┘

                      ▼

               ┌──────────────┐

               │    Review    │

               └──────┬───────┘

                      │

             APPROVED / REVISE

                      │

                      ▼

            Human Approval / Edit

                      │

                      ▼

                Final Report

What Each Agent Does

Research
The research agent is responsible for retrieval. It queries the Sanity Knowledge Base directly via GROQ and is explicitly instructed not to rely on general knowledge alone. When contradictory evidence is retrieved, it keeps both sides and their sources.

Analysis
The analysis agent compares the retrieved claims. It considers source provenance, trust level, and recency, and distinguishes well-supported evidence from weaker or single-source claims.

Writing
The writing agent converts the analysis into a source-linked report. It is instructed not to introduce factual claims that were not present in the research findings.

Review
The review agent acts as a hallucination gate. It checks the draft against the original research findings. Unsupported claims trigger a revision pass instead of being silently accepted. The workflow allows bounded revision before producing the final report — which then goes to a human approval step before being marked closed.

Why Sanity?

The project could have been built as a conventional search application. That would miss the important part of the problem.

The Knowledge Base stores claims, sources, and relationships between claims. In particular, the contradicts relationship makes disagreement part of the data model.

That structure changes what the agent can do. It is not simply retrieving text that matches a query. It is retrieving structured knowledge that can be compared, traced back to sources, and carried through a multi-agent reasoning and review pipeline.

Example Sources

The checkpoint-deserialization investigation uses sources with different levels of authority, including:

LangGraph checkpoint documentation
LangGraph security advisory — CVE-2026-28277
A second advisory database's framing of the same CVE, with mitigating context
A community checkpointer implementation, stored in the Knowledge Base

The agent preserves those provenance differences rather than treating every retrieved claim as equally authoritative.

Sanity Project Details

Project ID: 4kagnnrl

Code

https://github.com/pratikdevelop/multi-agent-research-analyst

The repository contains the LangGraph agent, Sanity schemas, and the Next.js interface.

What I Wanted to Demonstrate

The interesting part of this project isn't simply that multiple agents can call a CMS.

It is that structured content can make disagreement explicit.

Instead of forcing conflicting evidence into one confident answer, the Knowledge Base preserves the claims and their relationships, the analysis stage compares them, the review stage checks that the final report remains grounded in the retrieved evidence, and a human gets the final say before the case closes.

Research Dossier doesn't try to make disagreement disappear. It makes disagreement visible.

How to Build a Self-Healing CI/CD Pipeline with AI Agents (2026 Guide)

Pratik — Wed, 09 Sep 2026 07:00:13 +0000

Let’s be real: nothing kills developer flow state quite like a failed CI pipeline. You push your code, context-switch to grab a coffee, and come back to a wall of red text and a cryptic NullPointerException in a module you didn’t even touch.
In 2026, we don't have to do this anymore.
With the maturity of agentic frameworks and local code-generation models, we can now build self-healing pipelines. Instead of just alerting you that a build failed, the pipeline intercepts the failure, spins up an AI agent, generates a fix, verifies it, and opens a PR.
Here is a pragmatic guide to implementing this in your workflow today.
The Architecture
To build this, we need three things:
A webhook listener for our CI provider (GitHub Actions, GitLab, etc.).
An agentic framework (like LangGraph or AutoGen) to handle the reasoning loop.
An ephemeral sandbox to safely test the agent's fix.
Step 1: Catching the Failure Context
The biggest mistake devs make when building AI debuggers is just passing the raw error log to the LLM. Context is king. You need to pass the error log, the specific file that failed, and the recent git diff.

# webhook_handler.py
from fastapi import FastAPI, Request
from agent import DebugAgent

app = FastAPI()

@app.post("/webhook/ci-failure")
async def ci_failure_webhook(request: Request):
    payload = await request.json()

    # Extract the exact context the agent needs
    context = {
        "error_log": payload['logs']['stderr'],
        "failing_file": payload['logs']['failing_file_path'],
        "recent_diff": payload['repository']['last_commit_diff'],
        "test_command": payload['config']['test_script']
    }

    # Hand off to the agent
    agent = DebugAgent()
    result = await agent.heal(context)

    return {"status": result.status, "message": result.message}

Step 2: The Agentic Reasoning Loop
We use a graph-based agent so it can iterate. If the first patch doesn't fix the test, the agent needs to read the new error log and try again.

# agent.py
from langgraph.graph import StateGraph, END
from llm import get_model
from sandbox import run_tests_in_sandbox

class DebugAgent:
    def __init__(self):
        self.llm = get_model("qwen-coder-local") # Keep it local for speed/security!
        self.graph = self._build_graph()

    def _build_graph(self):
        workflow = StateGraph(dict)

        # Nodes
        workflow.add_node("analyze", self.analyze_error)
        workflow.add_node("patch", self.generate_patch)
        workflow.add_node("verify", self.verify_fix)

        # Edges
        workflow.set_entry_point("analyze")
        workflow.add_edge("analyze", "patch")
        workflow.add_edge("patch", "verify")

        # Conditional edge: If tests pass, end. If fail, loop back to analyze (max 3 times)
        workflow.add_conditional_edges(
            "verify",
            self.should_retry,
            {
                "retry": "analyze",
                "success": END,
                "escalate": END
            }
        )
        return workflow.compile()

    async def analyze_error(self, state):
        # Prompt the LLM to understand the root cause based on logs + diff
        pass 

    async def generate_patch(self, state):
        # Generate a unified diff patch
        pass

    async def verify_fix(self, state):
        # Apply patch to ephemeral docker container and run tests
        pass

🚨 Pro-Tips & Gotchas from the Trenches

If you are building this in production, watch out for these three things:
Log Truncation: LLMs will hallucinate if you feed them 50,000 lines of logs. Write a pre-processor that extracts only the fatal error blocks and the surrounding 50 lines of context.
Infinite Loops: Always set a max_iterations limit (I use 3). If the agent can't fix it in 3 tries, it's a complex architectural issue. Escalate to a human.
Security: Never give the agent write access to your main branch. The agent should only ever push to a temporary branch like ai-fix/issue-123. Let human reviewers merge it.

Wrap Up

Building a self-healing pipeline takes a weekend of setup, but it saves hundreds of hours of context-switching over the year. Start small: hook an agent up to your linting failures first, then move to unit test failures.
Have you implemented agentic CI/CD in your stack yet? What framework are you using for the reasoning loop? Drop your setups in the comments below!

What I Learned from Reading the PyCharm PyTorch Tutorial

Pratik — Sat, 01 Aug 2026 02:59:13 +0000

I recently read the "PyTorch Tutorial for Deep Learning" on the PyCharm Blog by JetBrains as part of my AI learning journey.

Although this wasn't a hands-on coding session, it helped me build a stronger understanding of the fundamentals behind PyTorch and modern deep learning.

Highlights from the Tutorial

An introduction to PyTorch and why it's one of the most popular deep learning frameworks.
Understanding tensors and their role in neural networks.
Creating, reshaping, and manipulating tensors.
Basic tensor arithmetic and NumPy interoperability.
Using CUDA for GPU acceleration.
How torch.nn.Module is used to build neural networks.
Understanding the purpose of the forward() method.
Learning how Autograd automatically computes gradients during training.
Setting up a PyTorch development environment in PyCharm.

Why This Article Stood Out

What I appreciated most is that the tutorial focuses on explaining why these concepts matter before jumping into building models. It provides a clear roadmap for beginners who want to understand the building blocks of deep learning.

What's Next?

My next step is to put these concepts into practice by building beginner-friendly PyTorch projects, starting with the MNIST handwritten digit classifier mentioned in the tutorial.

Learning is most valuable when theory is followed by practice, and that's exactly what I plan to do next.

If you're beginning your journey into AI or deep learning, this tutorial is a great place to start.

Original article: https://blog.jetbrains.com/pycharm/2026/07/pytorch-tutorial-for-deep-learning/

Happy learning! 🚀