DEV Community: Pratik

SlowSells: A Gemma-Powered Sales Assistant That Handles the Busywork 🦥

Pratik — Sat, 24 Oct 2026 18:04:27 +0000

The idea: Spend less time figuring out what needs attention in your CRM and more time moving sales forward.

Salespeople often start their day by checking leads, reviewing open deals, scanning overdue activities, and deciding who needs a follow-up. The information exists in the CRM, but turning it into a useful daily plan still takes manual effort.

I built SlowSells, an AI-assisted sales CRM that brings customer and sales management together with a daily sales brief that helps users identify their next useful action.

🔗 Live demo: https://ai-sales-crm.vercel.app

💻 Source code: https://github.com/pratikdevelop/ai-sales-crm

What I Built

SlowSells combines everyday CRM workflows with an AI assistant designed to reduce repetitive sales-planning work.

1. AI Morning Sales Brief

The AI Morning Sales Brief uses a Gemma model to generate a practical summary from relevant CRM information. Instead of starting with a blank page, a salesperson gets a clearer view of what deserves attention.

The brief is designed to turn workspace context into useful next steps rather than another generic chatbot conversation.

2. An Action Center

The dashboard highlights overdue follow-ups, deals approaching their expected closing dates, and a suggested area of focus. These signals help users prioritize their day before navigating through individual CRM sections.

3. A connected sales workspace

SlowSells includes:

Contacts and companies
Leads and deal pipeline tracking
Activities and follow-up management
Product catalogue and order management
Dashboard metrics and recent sales activity
Sales insights and AI-assisted planning

The goal is to keep the daily workflow connected instead of making users jump between disconnected tools.

4. A practical fallback

AI systems can fail or become temporarily unavailable. SlowSells includes a rules-based fallback for the Morning Sales Brief so the workflow can still provide useful recommendations when model generation is unavailable.

The AI is intended to assist with prioritization, not to replace the salesperson's judgment.

How I Built It

The application uses:

Next.js App Router for the application and server-side routes
React and TypeScript for the interface and typed application logic
Prisma for database access
MongoDB Atlas for persistent CRM data
Google OAuth for sign-in
Gemma through Google's GenAI SDK for AI-generated sales briefs
Vercel for deployment

For the Morning Sales Brief, the server retrieves relevant workspace CRM information and passes the context needed for generating recommendations to the model. The application is designed to avoid sending contact email addresses, phone numbers, and private notes in that prompt.

The generated output is presented as practical guidance, including prioritized actions and an editable follow-up draft. The fallback keeps the experience useful even when AI generation does not succeed.

Why Open Innovation Matters

I chose Gemma because I wanted to build around an open-weight model rather than make this workflow depend entirely on a closed-model API.

Open-weight models give developers access to model weights and more flexibility to experiment with model behavior and deployment approaches, subject to the model's applicable terms. That creates room to adapt an AI workflow as requirements change.

There is an important distinction in my current implementation: SlowSells uses hosted Gemma inference; it does not run the model locally or work entirely offline today. Hosting inference makes the deployed demo practical, while the open-weight model choice leaves more options for future experimentation, including compatible self-hosted deployments.

The project also keeps the AI workflow focused on relevant CRM context instead of treating every piece of customer information as necessary input.

For me, open innovation is valuable when it gives builders more choices about how intelligent features are developed, deployed, and improved.

What I Learned

Building this project reinforced that adding an AI model is only one part of building a useful AI application.

The application still needs reliable data access, workspace-aware queries, predictable output, a usable interface, and a fallback when the model is unavailable. The challenge was not just to generate text, but to connect an AI brief to a real sales workflow.

I also deployed the application to Vercel and configured Google OAuth for the production domain, making the demo accessible beyond my local development environment.

I have not measured a formal time-saving benchmark yet, so I won't claim a specific number of minutes saved. The intended benefit is to reduce the manual work required to review sales activity and decide on the next step.

Try SlowSells

Live application: https://ai-sales-crm.vercel.app

Source code: https://github.com/pratikdevelop/ai-sales-crm

I'd welcome feedback on how the daily brief could make sales workflows more useful without adding more noise to the workday.

Prize Categories

Best Use of Gemma
Best Use of MongoDB Atlas

devchallenge #hf26challenge #hacktoberfest #productivity

PHP2Shell: How AI-Assisted Research Is Changing Cybersecurity

Pratik — Fri, 23 Oct 2026 03:09:55 +0000

What every developer should know about AI-assisted vulnerability discovery, secure coding, and responsible disclosure.

Introduction

AI is changing how we build software. Developers use AI tools to generate code, debug errors, write tests, and understand unfamiliar codebases.

But there is another important development: AI can also help security researchers discover software vulnerabilities.

The PHP2Shell security story highlights the growing intersection of artificial intelligence and cybersecurity. It raises important questions about how vulnerabilities are discovered, how findings are verified, and how development teams should respond.

The lesson isn't that AI automatically makes software secure. It's that AI can become a powerful research assistant when combined with technical expertise, rigorous testing, and responsible disclosure.

What is PHP2Shell?

PHP2Shell refers to a critical PHP security issue reported in October 2026.

Remote code execution (RCE) is a category of vulnerability that can potentially allow an attacker to execute code or commands on a vulnerable system remotely. Depending on the vulnerability and the environment, this may lead to unauthorized access, data exposure, or further system compromise.

PHP is widely used for server-side web development, so vulnerabilities in affected PHP components can have implications for applications that depend on them.

However, not every PHP application is necessarily vulnerable. Developers should consult official advisories to confirm affected versions and required fixes.

Official resource: https://www.php.net/archive/2026.php

How can AI help discover vulnerabilities?

Traditional security research involves inspecting source code, investigating program behavior, developing test cases, and determining whether a suspected weakness is exploitable.

AI can assist with several parts of this process.

Code analysis: Help researchers navigate large codebases and identify suspicious patterns.
Hypothesis generation: Suggest potential weaknesses that require investigation.
Test generation: Assist in creating test cases for controlled security testing.
Root-cause analysis: Help explain why a vulnerability occurs and explore possible fixes.
Code review: Identify potentially unsafe patterns that developers may want to investigate further.

These capabilities can make some research tasks more efficient. However, AI can also generate false positives, misunderstand program behavior, or overlook important environmental conditions.

A suspected weakness is not a confirmed vulnerability until it has been properly validated.

Did ChatGPT discover PHP2Shell?

It's important to distinguish between AI-assisted research and a claim that ChatGPT independently discovered a vulnerability.

AI models can support researchers by analyzing code, proposing hypotheses, and helping investigate potential exploits. Researchers still need to validate findings, establish their impact, and follow responsible disclosure practices.

For PHP2Shell, claims about which AI model contributed to the discovery should be checked against the original research announcements. It's more accurate to describe a discovery as AI-assisted when the evidence supports that wording, rather than attributing the entire discovery to ChatGPT without confirmation.

This distinction matters because technical credibility depends on accurate attribution.

Why does AI-assisted security research matter?

AI can reduce the effort required for certain software-analysis tasks. This creates opportunities for defenders, but similar capabilities may also be used by malicious actors.

Opportunities for defenders:

Faster investigation of suspicious code.
Assistance with vulnerability triage.
More efficient security-test generation.
Better understanding of unfamiliar or legacy systems.
Support for identifying insecure coding patterns.

Challenges for security teams:

More findings that need human verification.
False positives and incomplete analysis.
Potential misuse by attackers.
The need for safe testing environments.
Pressure to remediate confirmed vulnerabilities quickly.

AI is not a replacement for security engineering. It is another tool that can extend the capabilities of people doing security work.

What can developers across all technology stacks learn?

Whether you build websites, APIs, mobile apps, desktop software, cloud infrastructure, or embedded systems, the core security principles remain relevant.

Frontend developers

Avoid exposing API keys and secrets in client-side code.
Use appropriate output encoding and follow secure rendering practices.
Understand common web risks, including cross-site scripting (XSS).
Enforce authorization on the server rather than relying on frontend controls.

Backend and API developers

Validate untrusted input at system boundaries.
Use safe database queries and avoid unsafe command execution.
Implement authentication and authorization correctly.
Apply rate limiting and sensible error handling where appropriate.
Keep runtimes, frameworks, and dependencies updated.

Mobile and desktop developers

Store sensitive information using platform-appropriate secure storage.
Validate data received from remote services.
Avoid embedding long-lived secrets in distributed applications.
Keep third-party SDKs and libraries updated.

DevOps, cloud, and infrastructure engineers

Patch operating systems, runtimes, containers, and deployed services.
Apply least-privilege permissions to workloads and service accounts.
Protect secrets and restrict unnecessary network exposure.
Monitor security events and maintain incident-response procedures.

Data, AI, and machine-learning engineers

Protect credentials, datasets, and model endpoints.
Treat user-provided content and retrieved documents as untrusted input.
Apply access controls to tools used by AI agents.
Evaluate risks from prompt injection, unsafe tool execution, and sensitive-data exposure.
Avoid giving AI systems more permissions than their tasks require.

Every developer

Regardless of role or programming language:

Keep software and dependencies supported and patched.
Review security advisories relevant to your stack.
Use code reviews, automated checks, and appropriate security testing.
Verify AI-generated code instead of trusting it blindly.
Investigate suspected vulnerabilities before deciding on severity.
Follow responsible disclosure practices when reporting security issues.

Security is not limited to one programming language or one team. It is a shared engineering responsibility.

Building an AI-assisted security workflow

A practical workflow can combine established security tools with AI assistance.

Discover: Scan dependencies and monitor relevant security advisories.
Analyze: Investigate suspicious code with static analysis, code review, and AI assistance.
Validate: Reproduce suspected issues in a controlled environment.
Remediate: Apply patches or correct unsafe application logic.
Verify: Run regression tests and security checks.
Monitor: Watch for suspicious activity and new vulnerabilities.

AI can help throughout this process, but it should not be the only source of truth. Official advisories, testing, established security tools, and human judgment remain essential.

Conclusion

PHP2Shell highlights a broader shift in cybersecurity: AI-assisted research is becoming an important part of how software weaknesses are investigated.

For developers, the lesson is not simply to adopt more AI tools. It is to combine AI's analytical capabilities with secure coding, careful validation, responsible disclosure, and timely remediation.

AI may help us discover vulnerabilities faster. Our responsibility is to turn those discoveries into safer software.

What role do you think AI should play in application security: a research assistant for specialists or a standard tool in every development team's workflow?

EmotionLens: Exploring AI-Powered Facial Expression Analysis with Open-Source AI

Pratik — Sun, 18 Oct 2026 15:29:22 +0000

This is a submission for the "Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle" (https://dev.to/challenges/hacktoberfest-week2-2026-10-12)

What I Built

I'm exploring how AI-powered facial expression analysis can become a practical tool for independent creators, presentation coaches, and trainers.

My project, AI Emotions Detection, is the starting point for EmotionLens, a product concept focused on helping users explore facial-expression predictions and review patterns in recorded presentations.

🔗 GitHub repository: https://github.com/pratikdevelop/AI-emotions-detection

The problem I'm interested in solving is straightforward: reviewing recordings manually can be time-consuming. An accessible AI-assisted tool could help users organize observations and identify moments they want to review more closely.

The longer-term vision is to develop a user-friendly application with expression timelines, session summaries, and privacy-conscious processing.

I see potential customers among independent creators, coaches, and trainers. Possible future monetization includes paid reporting features or a self-hosted version, although willingness to pay still needs validation.

Facial-expression predictions are imperfect and don't reliably establish someone's actual emotional state. The goal is to support review, not make definitive judgments about people.

Demo

GitHub repository: https://github.com/pratikdevelop/AI-emotions-detection

A deployed demo or video demonstration will be added when available.

Code

Explore the project on GitHub:

https://github.com/pratikdevelop/AI-emotions-detection

I'm using this project as a foundation for exploring how AI applications can evolve into useful, privacy-conscious products.

How I Built It

The project explores AI-based facial emotion detection. My goal is to develop it into a more complete application with a clear user workflow.

My next development priorities include:

Improving the user experience and reliability of expression predictions.
Exploring a timeline for reviewing predictions across a recording.
Investigating optional AI-generated summaries using an appropriate open-weight language model.
Making local processing and data-retention behavior explicit.
Evaluating predictions against representative test cases.

These are development goals, not claims that every feature is already implemented. The repository documents the current starting point.

Why Does Open Innovation Matter?

I believe open innovation gives developers more control over how AI applications are built, deployed, and improved.

For a project that may process personal recordings, local inference with a suitable open model could help keep video data on the user's own device rather than sending it to an external AI provider.

Open models also make experimentation more flexible. Developers can compare models, evaluate performance, and adapt their applications without depending entirely on a single provider's API pricing or availability.

Running models locally isn't automatically free or private: hardware requirements, application architecture, storage, and telemetry still matter. But open-source tools give developers more choices about these trade-offs.

That's the direction I want to explore with this project: accessible AI, greater user control, and a realistic path from experimentation to a useful product.

Prize Categories

Potential category to target: Best Use of Gemma

I plan to investigate whether an appropriate Gemma open-weight model can add value through optional session summaries. I would only claim this category after implementing and demonstrating a meaningful integration.

Potential category to target: Best Use of Render

I would also consider Render for hosting the application once there is a working deployment that meaningfully uses the platform.

These are intended targets, not claims of completed partner integrations.

What's Next?

My next step is to turn this starting point into a more complete application, test it with potential users, and find out which features actually save them time.

I'd love feedback from developers working with open-weight models, computer vision, and privacy-conscious AI applications.

What would make an AI-assisted presentation-review tool useful enough for you to use regularly?

I Tested Whether AI Can Keep Up With a Changing Software Specification

Pratik — Sat, 10 Oct 2026 18:34:53 +0000

This is a submission for the Kaggle Benchmarking Challenge.

What I Benchmarked

Software specifications rarely remain static. A team might replace password authentication with OAuth, tighten permissions, or introduce guest access while keeping guests read-only.

I built SpecDrift, a benchmark designed to test whether an AI model can reconstruct the current specification from a sequence of changing requirements.

My first task, Access & Identity, covers five scenarios:

Replacing email/password authentication with Google OAuth.
Restricting customer-data exports to administrators.
Replacing password authentication with email magic links.
Allowing guests to view public dashboard pages without editing them.
Renaming the owner role to administrator and transferring its permissions.

The task evaluates explicit final-state fields and changed-key identification rather than relying entirely on whether an explanation sounds convincing.

Models Tested

My initial baseline was google/gemini-3.7-flash.

I chose a structured-output evaluation because software teams need machine-readable specifications that downstream systems can use, not only plausible natural-language explanations.

I plan to expand the benchmark to additional available models and more requirement categories.

Findings

In my initial run, Gemini passed 16 of 18 assertions.

The two failures exposed an unexpected issue in the evaluator. The model returned email_magic_link for the final authentication method and read_only for guest permissions, but my regular expressions did not accept underscores.

This matters because an evaluation can incorrectly penalize a correct answer when its matching rules are too restrictive. The benchmark therefore needs testing at two levels: whether the model reconstructed the requirements correctly, and whether the evaluator correctly recognizes valid representations.

I updated the regex patterns to handle underscore-separated values and reran the task. The final reported result should reflect that rerun.

The broader question behind SpecDrift is whether models can reliably distinguish current requirements from obsolete ones, especially when a conversation contains several revisions. My next step is to extend the cases into billing, API integration, operations, and notifications, and compare more models using the same tests.

My Benchmark

https://www.kaggle.com/benchmarks/pratik222/specdrift-can-ai-track-changing-requirements

SpecDrift explores a practical challenge in AI-assisted software development: can a model keep the current truth when the specification changes?

kagglechallenge

TrailMate AI 🌿 — Turn Spare Time Into an Outdoor Adventure

Pratik — Sat, 10 Oct 2026 15:00:19 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

TrailMate AI helps turn the question “What should I do outside?” into a simple, personalized adventure.

We often spend our free time scrolling through our phones, even when we want to get outside, move around, or take a break from our screens. I built TrailMate AI to make taking that first step easier.

Instead of spending time planning an activity, users choose what they want to do, how much time they have, and what kind of mood they are in. TrailMate AI generates a personalized outdoor adventure with a sequence of small, actionable missions.

Users can choose from five activities:

🌿 Nature Walk
🚶 Walking
🏃 Running
🔎 Exploring
🧘 Mindfulness

They can also select a duration of 20, 30, 45, or 60 minutes and choose whether they want a relaxing, curiosity-driven, or challenging experience.

Every generated adventure includes a title, description, difficulty level, and timed missions. Users can mark missions as completed, undo them if needed, and track their progress through an animated progress bar. Completing every mission triggers a celebratory animation.

The goal is simple: make the screen the starting point of an experience, not the experience itself.

TrailMate AI is designed for people who want to spend more time outdoors but need a little inspiration to get started. Its suggestions are starting points, so users should adapt them to safe, accessible places and their surroundings.

Demo

🔗 Live application: https://trail-mate-ai.vercel.app/

The best way to experience TrailMate AI is to generate an adventure, mark a few missions complete, and watch the progress update.

Code

💻 GitHub repository: https://github.com/pratikraut8889-max/TrailMate-AI

The project is built with Next.js, React, TypeScript, and Tailwind CSS. Its API route communicates with Groq to generate structured adventure data, while Zod validates incoming requests and the generated response.

The interface handles loading and error states, displays generated missions, and tracks mission completion interactively.

How I Built It

The main technology stack is:

Next.js and React: Application structure, server-side API route, and interactive UI.
TypeScript: Typed activity options, moods, adventures, and missions.
Tailwind CSS: Responsive layouts and the visual design.
Groq API: Hosted inference for the AI model.
OpenAI gpt-oss-20b: An open-weight model that generates personalized adventure plans.
Zod: Validation of user inputs and generated adventure data.

I started by building the adventure selection interface. Once the basic UI worked, I connected it to a backend API route that sends the user's activity, available time, and mood to the model.

The model is instructed to return a structured JSON response containing an adventure and its missions. The backend validates that response, checks the expected mission count, and assigns mission IDs and durations before returning the result to the frontend.

One important engineering detail was making the AI response reliable enough for the UI to consume. Generative models may return malformed JSON or unexpected fields, so I added validation and error handling instead of trusting every response.

I then focused on the experience after generation: responsive layouts, loading animations, mission completion controls, a live progress bar, and a completion celebration.

The result is not just an AI text generator. It is a small interactive experience that encourages users to take an idea outside and act on it.

Model reference: OpenAI gpt-oss-20b. Inference provider: Groq.

Why Does Open Innovation Matter?

For TrailMate AI, open innovation matters because the model should not have to be permanently tied to one closed model provider.

I chose an open-weight model, gpt-oss-20b, and currently serve it through Groq. That gives me a practical way to build and deploy the application while retaining the option to explore other compatible inference providers or self-host the model in the future.

Open weights also create opportunities to inspect, experiment with, customize, and adapt a model as a project evolves. For a small project, that flexibility matters: I can continue experimenting with the quality of generated missions, output structure, and the balance between creativity and practical instructions without redesigning the entire application.

To be clear, the current deployed version uses Groq's hosted inference API and requires an internet connection. It does not currently run the model locally or work offline. The benefit of the open-weight approach here is flexibility and control over the model choice, along with a path to different deployment options in the future.

I also wanted to use AI for something that encourages people to spend less time using technology. TrailMate AI uses the model to help people make a plan, then gives them a reason to put their phones away and go outside.

To me, open innovation is not only about making technology available. It is also about giving developers more freedom to experiment with what that technology can help people do.

Prize Categories

I'm submitting TrailMate AI for the overall Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

I'm not claiming a partner-specific prize category because the current project uses Groq and Vercel rather than the challenge's listed partner technologies.

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?