DEV Community: langchain

Benchmarking Gemini, Claude, and OpenAI for Structured Document Extraction

Austin Vance — Fri, 14 Aug 2026 02:51:34 +0000

A few fellow engineers and I were talking about field extraction the other day. They were both saying Gemini's been surprisingly good at pulling structured data off documents, which surprised me, since that's not really the model I'd have reached for first. So we ran an experiment using LangSmith.

I printed ten copies of a form with the usual set of fields, names, dates, IDs, a checkbox, a signature line, and asked my coworker to help me fill them out by hand. I ran OCR on them too, mostly out of curiosity. It was pretty bad, which wasn't unexpected, especially on checkboxes.

Testing it

I set up a LangGraph graph with one node that does the extraction, and passed in which provider to use as runtime context, so the eval could run the exact same graph once per model:


def _extract(state: ExtractionState, runtime: Runtime[ExtractionContext]) -> dict:
    extractor = EXTRACTORS[runtime.context.provider]
    return {"result": extractor.extract(state["image_path"])}

I hand-labeled ground truth for every form and ran it all through LangSmith so I could score each model against the exact same data.

Scoring took a bit of tuning, mostly because a plain exact string match evaluator will ding a model for writing "Sr" instead of "Sr." or "management" instead of "Management," which isn't actually wrong, it's just formatting. So everything got normalized first (lowercased, trailing punctuation stripped, dates parsed into one format, phone numbers stripped down to digits) and scored three ways: fraction of fields correct for partial credit, whether the whole record was perfect for a stricter all-or-nothing exact match, and field accuracy per dollar.

Model	Field accuracy	Exact match	Perfect records	Field accuracy / cost
Claude (opus-5)	0.934	0.364	4/11	31.8
Claude (haiku-4-5)	0.636	0.091	1/11	207.2
Gemini (3.1-pro-preview)	0.934	0.636	7/11	93.1
Gemini (flash-lite-latest)	0.884	0.455	5/11	1084.8
OpenAI (gpt-5.6-sol)	0.860	0.455	5/11	50.6
OpenAI (gpt-5.4-nano)	0.620	0.091	1/11	814.4

Claude and Gemini ended up tied on average field accuracy, but Gemini still got a lot more whole forms completely right, which is a different thing to be measuring than it sounds like at first. The other thing that jumped out was the cheap tiers. Gemini's Flash Lite scored higher on field accuracy than OpenAI's flagship did, while Claude's Haiku and OpenAI's nano both fell off hard.

Picking a metric

No single model won across the board, and that's kind of the whole point. Field accuracy, exact match, and cost efficiency measure different things, so a model that dominates one of them can easily be the weakest on another. What's nice about having an eval running is that switching which one you care about is just a matter of changing what you sort by.

Optimizing for exact match

A form that's 11 out of 12 fields right still needs someone to go fix that twelfth field, and that costs about the same as fixing a form that's only 6 out of 12 right, since either way a person has to open it back up. That's the case for caring about exact match instead of average field accuracy.

exact match and field accuracy per model with a baseline selected for exact match

Optimizing for field accuracy

Field accuracy gives partial credit for every field that's right, which matters more than exact match when a human is going to check every field anyway. Fewer wrong fields overall beats fewer broken records when the correction happens field by field instead of record by record.

exact match and field accuracy per model with a baseline selected for field accuracy

Optimizing for cost

Cost efficiency matters most at volume, since a cheaper model that's a little less accurate can still get more forms extracted correctly per dollar than a pricier one that's only a little better.

exact match, field accuracy, and accuracy per dollar with a baseline selected for accuracy per dollar

So Chris and Mike were right, though the answer splits three ways. Gemini Pro won exact match and tied Claude Opus on field accuracy, and Gemini Flash Lite won on cost. Flash Lite is the one I didn't see coming, since it beat OpenAI's flagship on field accuracy too, at a tiny fraction of the price.

Technical References:

Benchmarking LLMs for Structured Data Extraction GitHub Repo

Building a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

Caper B — Fri, 14 Aug 2026 02:23:25 +0000

Building a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

LangChain is a powerful framework for building AI agents that can interact with various applications and services. In this tutorial, we'll explore how to create an AI agent that can earn money by automating tasks and providing value to users. We'll cover the practical steps to build and deploy our agent, and discuss the monetization strategies to generate revenue.

Step 1: Setting up the Environment

To start, we need to set up our development environment. We'll use Python as our programming language and install the required libraries. Run the following command in your terminal:

pip install langchain

This will install the LangChain library and its dependencies.

Step 2: Creating the AI Agent

Next, we'll create a simple AI agent using LangChain. Our agent will be able to interact with the Twitter API to post updates and respond to messages. Create a new Python file called agent.py and add the following code:

import langchain
from langchain.agents import Tool

# Define the Twitter API credentials
twitter_api_key = "YOUR_API_KEY"
twitter_api_secret = "YOUR_API_SECRET"

# Create a new LangChain agent
agent = langchain.Agent()

# Define a tool for interacting with the Twitter API
twitter_tool = Tool(
    name="twitter",
    description="Interact with the Twitter API",
    functions=[
        {"name": "post_update", "description": "Post an update to Twitter"},
        {"name": "respond_to_message", "description": "Respond to a message on Twitter"}
    ]
)

# Add the Twitter tool to the agent
agent.add_tool(twitter_tool)

Replace YOUR_API_KEY and YOUR_API_SECRET with your actual Twitter API credentials.

Step 3: Implementing the Twitter Tool

Now, we'll implement the functions for the Twitter tool. Create a new Python file called twitter_tool.py and add the following code:

import tweepy

# Define the Twitter API credentials
twitter_api_key = "YOUR_API_KEY"
twitter_api_secret = "YOUR_API_SECRET"

# Create a new Tweepy API object
api = tweepy.API(tweepy.OAuthHandler(twitter_api_key, twitter_api_secret))

# Define the function to post an update to Twitter
def post_update(update):
    api.update_status(update)

# Define the function to respond to a message on Twitter
def respond_to_message(message, response):
    api.send_direct_message(message.author.screen_name, response)

Again, replace YOUR_API_KEY and YOUR_API_SECRET with your actual Twitter API credentials.

Step 4: Integrating the Twitter Tool with the AI Agent

Now, we'll integrate the Twitter tool with our AI agent. In the agent.py file, add the following code:

# Import the Twitter tool functions
from twitter_tool import post_update, respond_to_message

# Define the function to handle incoming messages
def handle_message(message):
    # Use the AI agent to generate a response
    response = agent.generate_response(message.text)
    # Respond to the message using the Twitter tool
    respond_to_message(message, response)

# Define the function to post updates to Twitter
def post_update(update):
    # Use the Twitter tool to post the update
    post_update(update)

Step 5: Monetizing the AI Agent

To monetize our AI agent, we can use various strategies such as:

Sponsored tweets: Partner with brands to post sponsored tweets to our Twitter account.
Affiliate marketing: Promote products or services and earn a commission for each sale made through our unique referral link.
Native advertising: Use platforms like Taboola or Outbrain to promote content and earn revenue from clicks or conversions.

We can integrate

Building a Multi-Agent AI Pipeline That Ships: LangGraph, RAG, and Evals That Matter

manasviboineypally — Thu, 13 Aug 2026 17:14:25 +0000

I spent 18 days building an AI product that converts research papers into audience-tailored PowerPoint presentations. Not a toy — a real deployed thing at doc2slides on Railway that anyone can use.

The interesting parts weren't the "make it work" moments. They were the tradeoffs I had to make honestly, and the times I resisted the temptation to add a "clever" fix that would have made things worse.

This post is about those decisions.

What I built

Doc2Slides takes a PDF and produces a .pptx file tailored to four audiences:

Kid — fun analogies, simple words
Student — educational, terms defined
Engineer — technical depth, assumes domain knowledge
Executive — business focus, impact-oriented

The magic is that the same paper produces radically different output based on the audience. A compiler theory paper for a kid becomes "compilers are like magic helpers." The same paper for an executive becomes "advancing compiler technology with formal frameworks."

Code: github.com/manasviboineypally/doc2slides

The architecture: 5 agents in LangGraph

I built this as a multi-agent pipeline instead of one giant LLM prompt. Here's the flow:

PDF Upload
    ↓
Parser        → extracts sections + metadata
    ↓
Summarizer    → RAG-based section summarization
    ↓
Planner       → designs slide structure for audience
    ↓
Writer        → generates audience-adaptive slide content
    ↓
Builder       → produces editable .pptx file

Each agent is an independent node in a LangGraph state machine. They share a TypedDict state and read/write specific fields.

Here's what the graph definition actually looks like:

from langgraph.graph import StateGraph, END
from app.agents.state import AgentState
from app.agents.parser import parser_agent
from app.agents.summarizer import summarizer_agent
from app.agents.planner import planner_agent
from app.agents.writer import writer_agent
from app.agents.builder import builder_agent

def build_pipeline():
    graph = StateGraph(AgentState)

    graph.add_node("parser", parser_agent)
    graph.add_node("summarizer", summarizer_agent)
    graph.add_node("planner", planner_agent)
    graph.add_node("writer", writer_agent)
    graph.add_node("builder", builder_agent)

    graph.set_entry_point("parser")
    graph.add_edge("parser", "summarizer")
    graph.add_edge("summarizer", "planner")
    graph.add_edge("planner", "writer")
    graph.add_edge("writer", "builder")
    graph.add_edge("builder", END)

    return graph.compile()

Why LangGraph over a sequential chain? Adding a new agent is a 2-line change to the graph. In a sequential chain, adding a new step often means refactoring the previous ones. State-based multi-agent design scales better.

The interesting tradeoff #1: My RAG top-1 precision is 42%

I built an evaluation harness because I wanted to measure quality, not just claim it. Three eval types:

Parser evals — deterministic ground-truth assertions
RAG evals — top-K precision on hand-labeled query→section pairs
Summarizer evals — LLM-as-judge scoring faithfulness, completeness, clarity

The parser evals scored 100% (34/34 checks). The summarizer evals averaged 4.4/5.

But the RAG top-1 precision came in at 42%. Only 3 of 7 queries returned the correct section as the top result.

My first instinct: hide the number. Report top-3 (57%) instead.

What I did instead: publish both numbers and explain why.

Looking at the failures revealed a real limitation of RAG:

Query: "how does the genetic algorithm work?"
Expected section: Methodology
Actual top result: 3.6 Stopping Criteria (a subsection of methodology)

Genetic algorithms are discussed in 6 subsections (3.1 through 3.6). Vector search returns the highest-scoring chunk, not the highest-scoring section. For queries about broad topics, subsections often outrank the parent section because they mention the specific term more densely.

This is a known problem in RAG. Solutions include:

Hierarchical retrieval (search subsections, bubble to parent)
Query rewriting to be more specific
Retrieve top-K and let an LLM pick the right section

None of these are fixed today. But I know exactly what's broken and why — which is more useful than pretending it works.

Lesson: deterministic metrics beat vibes. Vibes let you convince yourself the AI is smart. Metrics tell you where it's dumb.

The interesting tradeoff #2: I refused to use word count as a proxy for content density

Users can request any number of slides between 3 and 50. When the paper's actual content density doesn't match the requested slide count, the LLM either pads shallow sections or compresses dense ones. This creates mild redundancy at high slide counts.

The obvious fix: allocate slides based on section word count. Long section = more slides. Short section = fewer slides.

I almost built this. Then I realized: word count is not content density.

Consider:

A 100-word section with 3 distinct concepts should get multiple slides
A 2000-word section rambling around one idea should get one slide

Word count would systematically reward verbose sections and penalize concise ones. That's not a fix — it's a bug with math.

What I did instead: documented the tradeoff and shipped without the heuristic. From the project's testing_notes.md:

Rejected quick fix: using section word count as a proxy for content density. Word count is not density — a short section may contain multiple distinct ideas while a long section may ramble around one.

Proper solution deferred: content-aware slide allocation with LLM judgment, verified by an evaluation harness that measures output quality against ground truth. Requires infrastructure work not appropriate for the initial version.

Lesson: the right answer to "should I add this heuristic?" is often "no." Heuristics feel like progress. Sometimes they're anti-progress dressed up as pragmatism.

The interesting tradeoff #3: SQLite dev → PostgreSQL prod is one variable

I built with local SQLite during development but deployed to Railway with PostgreSQL. The migration was one line:

# app/db/session.py
DATABASE_URL = os.getenv("DATABASE_URL")
engine = create_engine(DATABASE_URL, echo=False)

For local dev, .env has:

DATABASE_URL=sqlite:///./doc2slides.db

For Railway, the environment variable is:

DATABASE_URL=postgresql+psycopg2://postgres:xxx@host:5432/railway

Nothing else changes. SQLAlchemy models are backend-agnostic.

This is boring engineering. But boring engineering is what lets you sleep at night. When someone asks "how do you handle database migrations?" the answer isn't a clever hack — it's "environment-driven configuration and a repository pattern."

The stack

Layer	Choice	Why
Language	Python 3.13	AI ecosystem
API	FastAPI	Async support, auto Swagger docs
Orchestration	LangGraph	State-based multi-agent
LLM	OpenAI GPT-4o-mini	Cheap enough for iteration, smart enough for structured output
Vector DB	ChromaDB	Local, no cloud dependency
Structured output	JSON mode + Pydantic	Two-layer validation
Database	SQLAlchemy + PostgreSQL	Env-driven, portable
Frontend	Vanilla HTML/CSS/JS	No build step, portable
Deployment	Railway	GitHub CI/CD, managed Postgres

The frontend is worth calling out. I used no framework — just HTML, CSS, and vanilla JavaScript in ~500 lines. Zero build step. Anyone can clone the repo, open the file, and understand it in 5 minutes.

For an MVP, that's a feature, not a limitation.

What I didn't build (and why that's OK)

Skipped:

User authentication
Multi-tenant workspaces
Custom presentation templates
Streaming responses
Job queue with Celery/Redis

Why: MVP. Every feature has a cost. Shipping the core value (PDF → audience-tailored slides) matters more than shipping every possible feature.

For a portfolio project, "I could have added X but chose not to for these reasons" is a stronger answer than "I added X poorly."

Lessons I'd tell my past self

1. Build evals before optimizing. I built the pipeline first, then evals. If I had built evals first, I would have known earlier that my RAG had issues. Now I have to make eval-driven improvements Week 3.

2. Resist heuristics. Every time I thought "this is a quick fix," it was actually a technical debt I was about to bake in. Word count as density. Silent AI slide count overrides. Boolean status flags instead of proper enums.

3. Deploy early. I deployed on Day 16 of 18. I should have deployed on Day 8. Deployment reveals real bugs — environment variable typos, missing dependencies, hardcoded localhost URLs. The sooner you find them, the cheaper they are.

4. Document tradeoffs, not features. Anyone can read code to know what it does. Almost no one leaves notes on why a design choice was made. My testing_notes.md file is where most of the actual engineering thinking lives.

What's next

The project is live, but not "done." Future work:

Content-aware slide count (with an eval harness measuring output quality)
Multi-language support for input PDFs
Custom presentation templates
Fix RAG for hierarchical sections (subsection → parent bubbling)

If you want to try Doc2Slides yourself:

Live demo: web-production-6eded.up.railway.app
Code: github.com/manasviboineypally/doc2slides
60-second video demo: Loom link

Upload any PDF, pick your audience, get back a deck. Same paper, radically different output depending on who you say you're presenting to.

Author: Manasvi Boineypally — GitHub · LinkedIn

10 Best LangChain Development Companies

Utsav Prajapati — Thu, 13 Aug 2026 09:29:10 +0000

LangChain has become one of the default frameworks for building production LLM applications chaining prompts, connecting retrieval augmented generation (RAG) pipelines, and orchestrating multi-step AI agents instead of hand-rolling API calls. But "LangChain development" isn't really a standalone skill you hire for in isolation it sits on top of broader AI engineering, data infrastructure, and software delivery experience. That's why almost nobody on this list is a pure "LangChain shop." They're software and AI development companies with real generative-AI delivery experience, where LangChain (or a comparable orchestration framework) is one tool in a bigger toolkit.

Here are 10 companies worth shortlisting if you're hiring for a LangChain or LLM-application build, what each one is actually good at, and who should reach for them.

🔎 Want to compare these side-by-side with live pricing, reviews, and alternatives? Check the full LangChain Developers on Find Alternatives it's updated as tools change.

Quick Rundown

Here's the full list at a glance before we dive into details:

1.Aalpha — India based outsourcing shop offering AI-driven web, mobile, and enterprise app development
2.Sigma Software — 20+ year IT partner with a dedicated AI/agentic workflow practice
3.Accenture — Global consulting giant with a large scale enterprise AI practice
4.N-iX — Eastern European engineering firm focused on measurable, production grade AI adoption
5.Lunar Logic — Small, product focused Polish agile software house
6.Turing — AI powered talent cloud for hiring pre-vetted remote AI engineers
7.Savvy Apps — US based, Globant owned mobile and web product design agency
8.InData Labs — Dedicated AI and data science consultancy with 10+ years in ML/NLP
9.Andersen — Large global software company with a formal AI native delivery practice
10.Valor Software — Frontend-focused consultancy (Angular, Vue, React) now building AI powered features

1. Aalpha

Aalpha is an India-based IT consulting and custom software outsourcing company, founded in 2008, with a long track record in web, mobile, and cloud/SaaS development across 5,500+ projects. It has more recently repositioned around "AI-driven IT solutions," building AI-powered web, mobile, and enterprise applications on top of its existing full-stack engineering base.

Best for: Startups and SMEs wanting a cost-effective offshore partner that can bolt AI features onto a broader web/mobile build.

2. Sigma Software

Sigma Software Group is a 20+ year-old IT partner (originally from Ukraine, now headquartered in Sweden) recognized on IAOP's World's Top 100 Outsourcing list. Its newer AI practice focuses specifically on applying AI across the software development lifecycle itself coding, testing, refactoring alongside building AI-powered products and agentic workflows for clients.

Best for: Enterprises that want an established outsourcing partner already running structured, human in the loop AI adoption pilots, not a startup experimenting for the first time.

3. Accenture

Accenture is one of the largest global consulting and technology services firms, with a substantial enterprise AI practice spanning strategy, implementation, and managed services across virtually every industry. For LangChain-based projects, that means access to deep pockets of specialized talent and established governance frameworks at enterprise consulting scale and pricing.

Best for: Large enterprises that need AI development bundled with broader digital-transformation strategy and change management.

4. N-iX

N-iX is a 24 year old Eastern European engineering firm (2,400+ engineers) that positions itself around what it calls "Pragmatic AI Software Engineering" measuring what AI tools actually deliver on a client's codebase before scaling them, rather than adopting AI for its own sake. It holds AWS AI Services Competency and partners with Google Cloud, Palantir, and Snowflake, and publishes concrete before/after metrics from its AI rollouts.

Best for: Enterprises that want AI development decisions backed by measured engineering outcomes, not vendor hype.

5. Lunar Logic

Lunar Logic is a small (roughly 30-person), product-focused agile software house based in Kraków, working in Ruby on Rails, Elixir, React, and mobile. It's built around a flat, transparent operating structure with no fixed management layer, and a strong emphasis on validating product ideas UX research, prototyping, feasibility before committing to a full build.

Best for: Startups that want a small, senior, highly collaborative team for a scoped LLM-powered product rather than a large offshore bench.

6. Turing

Turing isn't a traditional dev shop it's an AI-powered talent cloud that sources, vets, and matches remote engineers (including AI/ML specialists) to companies like OpenAI, Coinbase, and Salesforce, drawing from a database of millions of developers worldwide. For LangChain work specifically, that means you're hiring individually vetted engineers into your own team structure rather than contracting an agency for a fixed-scope project.

Best for: Companies that want to augment an in-house team with individual, pre-vetted AI engineers rather than outsource the whole build.

7. Savvy Apps

Savvy Apps is a US-based mobile and web design/development agency (founded 2009, acquired by Globant in 2020) with a long client list including Levi's, Toyota, and PBS, and design-industry recognition including a Webby Award and an Apple Editor's Choice. It's a product design first shop rather than an AI specialist, but that design discipline matters for LLM-powered apps where the conversational UX is as important as the backend chain logic.

Best for: Teams that want strong product design and UX craftsmanship wrapped around an AI feature, not just backend orchestration.

8. InData Labs

InData Labs is a dedicated AI and data science consultancy (founded 2014, Cyprus-headquartered) with over a decade of focus specifically on machine learning, NLP, computer vision, and more recently generative AI, RAG systems, and AI agents. Unlike most companies on this list, AI is the entire business rather than one service line layered on top of general software development.

Best for: Teams that want a partner whose core expertise is AI/data science itself, not a generalist dev shop offering AI as an add-on.

9. Andersen

Andersen is a large (3,700+ employee) global software development company with development centers across Europe, the US, and the Middle East, and a formal "AI-native" delivery practice that embeds AI tools into its own SDLC requirements analysis, architecture documentation, test generation while also building custom AI solutions for clients. It's completed 120+ AI projects across industries.

Best for: Enterprises wanting a large, established vendor with both AI product delivery and AI-augmented internal processes to speed up the build itself.

10. Valor Software

Valor Software is a frontend-focused development consultancy, well known in the Angular community since 2013 as the creator of the popular ngx-bootstrap library, with growing depth in Vue.js and React as well. Its more recent work includes AI-powered features personalized recommendations, conversational AI components, RAG and vector-search integrations built on top of its existing frontend and product engineering strength.

Best for: Teams building a LangChain-powered feature into an existing Angular, Vue, or React product who want frontend expertise as strong as the AI backend.

A few quick filters to decide faster

Want AI as the core specialty, not an add-on? InData Labs, whose entire practice is AI and data science.
Need enterprise-scale delivery with governance and change management? Accenture or Andersen.
Want measured, metrics-driven AI adoption over hype? N-iX, which publishes concrete before/after engineering results.
Building a small, scoped product and want a lean senior team? Lunar Logic.
Want to hire individual AI engineers into your own team instead of outsourcing the whole build? Turing.
Already have a frontend stack (Angular/Vue/React) and need AI features bolted on? Valor Software.
Need strong product design/UX around the AI feature, not just backend logic? Savvy Apps.

Final Thoughts

"LangChain development company" isn't really its own category it's a specific skill sitting inside a broader spectrum, from dedicated AI/data-science consultancies to large enterprise IT firms to lean, design-focused product studios that happen to build AI features well. The right pick depends less on who name-drops LangChain in their marketing and more on whether their broader engineering, design, or AI-strategy strengths match what your project actually needs around the LLM logic itself.

If you're evaluating partners for your team, start with 1–2 from this list based on the kind of project you're running, trial them on a real (but low-risk) piece of the build, and see how much of the LangChain and RAG complexity they actually take off your plate over the next 30 days.

👉 Browse and compare more tools at Find Alternatives 📩 Got a tool to suggest or a correction to flag? Contact us here

Which of these have you worked with or who else belongs on this list? Drop it in the comments 👇

How to Build a Voice Agent with LangChain?

Ciphernutz — Thu, 13 Aug 2026 08:16:55 +0000

How to Build a Voice Agent with LangChain: Architecture, Streaming, Tools, and Production Patterns

Building a voice agent is not simply a matter of connecting speech-to-text to an LLM and adding text-to-speech.

A production voice agent has to solve a harder problem:

How do you make an AI system listen, reason, use tools, remember context, and respond quickly enough that the conversation still feels natural?

LangChain can handle the agent and tool-orchestration layer, but the realtime experience depends heavily on what happens around it.

A practical architecture looks like this:

User microphone
      ↓
Audio streaming
      ↓
Speech-to-Text (STT)
      ↓
Transcript / turn detection
      ↓
LangChain Agent
      ↓
Tools / APIs / Business Logic
      ↓
Streaming response
      ↓
Text-to-Speech (TTS)
      ↓
User hears response

LangChain's current voice-agent documentation describes this as the "sandwich" architecture: STT → agent → TTS. The advantage is that each layer can be replaced independently, while the agent can continue using the broader LangChain ecosystem.

What You Actually Need to Build

Before writing code, separate the voice agent into five responsibilities:

Audio transport — moves microphone audio to the backend and audio responses back to the client.
Speech recognition — converts audio into text.
Agent reasoning — decides what the user wants and what action to take.
Tool execution — interacts with databases, CRMs, calendars, APIs, or internal systems.
Speech synthesis — converts the response back into audio.

This separation matters because these components have different performance characteristics.

For example, changing your TTS provider should not require rewriting your business logic. Similarly, changing the LLM should not require rebuilding your audio transport.

That modularity is one of the strongest reasons to use a cascaded architecture instead of putting everything into one model.

1. Choose the Voice Architecture First

There are two major ways to build a voice agent.

Architecture A: STT → Agent → TTS

Audio
  ↓
STT
  ↓
Text
  ↓
LangChain Agent
  ↓
Text
  ↓
TTS
  ↓
Audio

This gives you control over every component.

You can choose one STT provider, another LLM, and a completely different TTS provider.

It also makes debugging easier because you can inspect the transcript, agent decision, tool call, and final response independently.

The trade-off is additional infrastructure and potential latency.

Architecture B: Speech-to-Speech

Audio
  ↓
Multimodal Voice Model
  ↓
Audio

This can reduce the number of moving pieces and can preserve more information about how something was spoken, such as tone.

However, it can reduce your control over individual components and introduce provider-specific constraints.

For business applications where tool execution, observability, provider flexibility, and deterministic workflows matter, the cascaded architecture remains highly practical.

2. Use Streaming Instead of Waiting for Complete Responses

This is where many voice-agent implementations go wrong.
A naive implementation waits for the entire chain:

Record entire sentence
       ↓
Transcribe
       ↓
Wait for complete LLM response
       ↓
Generate complete audio
       ↓
Play response

The user experiences one long delay.
A streaming architecture instead looks like:

Audio chunk
   ↓
STT starts immediately
   ↓
Transcript arrives
   ↓
Agent starts generating
   ↓
First response tokens arrive
   ↓
TTS starts
   ↓
Audio starts playing

The system does not wait for every stage to finish before the next stage begins.

LangChain's official voice-agent example uses asynchronous streaming and RunnableGenerator to connect STT, the agent, and TTS. The documentation notes that this pipeline can achieve sub-700 ms latency with suitable STT and TTS providers.

The important lesson is:

Realtime voice is primarily a pipeline-design problem, not just a model-selection problem.

Research on realtime voice agents similarly identifies streaming and pipelining across STT, LLM, and TTS as a central mechanism for reducing perceived latency.

3. Create the LangChain Agent

Once speech has been converted into text, the voice layer can hand the request to a normal LangChain agent.

Current LangChain applications use create_agent as the primary entry point.

A minimal agent can look like this:

from langchain.agents import create_agent

def check_order_status(order_id: str) -> str:
    """Return the current status of an order."""
    return f"Order {order_id} is currently being processed."

agent = create_agent(
    model="openai:gpt-5.4",
    tools=[check_order_status],
    system_prompt="""
    You are a customer support voice agent.

    Keep spoken responses short.
    Ask for missing information instead of guessing.
    Use tools whenever the user asks for account-specific information.
    """
)

The important part is not the five lines of code.

It is the tool boundary.

A voice agent should not directly manipulate your database or business systems through arbitrary model-generated text.

Instead:

User:
"Where is order 4821?"

       ↓

Agent

       ↓

check_order_status("4821")

       ↓

Business system

       ↓

Structured result

       ↓

Agent

       ↓

"Your order is currently being processed."

LangChain agents can reason over available tools and execute them as part of the agent loop. The current agent implementation is built on LangGraph's runtime.

4. Design Tools for Voice, Not Just for Chat

This is an overlooked part of voice-agent engineering.

A tool that works well for a text chatbot may be poorly designed for a voice agent.

For example, avoid giving the agent a tool that returns:

{"customer_id": 1827,
 "subscription_status": "active",
 "plan": "enterprise",
 "billing_cycle": "annual",
 "last_payment": "...",
 "payment_method": "..."}

if the only thing the user asked was:

"Is my subscription active?"

Instead, make the tool return information that the agent can quickly reason over.

def get_subscription_status(customer_id: str) -> str:
    """Check whether a customer's subscription is active."""
    ...

The voice agent can then respond:

"Yes, your subscription is active."

The rule is simple:

Design tools around decisions, not database tables.

This reduces unnecessary reasoning and makes spoken responses easier to control.

5. Keep Spoken Responses Short

A language model optimized for written chat can produce paragraphs.

A voice agent should not.

Compare:

Chatbot response:

"Certainly. I can help you with that. According to the information available in your account, your order has been processed successfully and is currently in transit. You can expect delivery within the next two to three business days..."

Voice response:

"Your order is in transit. It should arrive within two to three business days."

Voice requires a different response policy.

A useful system instruction is:

You are a voice assistant.

Speak naturally and concisely.

Prefer one or two sentences per response.
Do not read JSON, URLs, IDs, tables, or long lists aloud.

Ask one question at a time.
If a tool fails, explain the problem briefly and offer the next action.

Never invent information that is unavailable from a tool.

This is not merely prompt optimization.
It is interface design.

6. Add Conversation Memory Carefully

Voice conversations become awkward if the agent forgets what was said five seconds earlier.

Consider:

User: "I want to book an appointment tomorrow."
Agent: "What time?"
User: "Around 4."

Please ensure the agent understands that "4" refers to the appointment.

LangChain's voice-agent example uses conversation state with a checkpointer and a unique thread ID so the agent can retain context across turns.

Conceptually:

User
 ↓
Voice session ID
 ↓
Conversation state
 ↓
LangChain agent
 ↓
Response

For a production system, distinguish between:

Short-term conversation state

Things said during the current call.

Examples:

user's name
requested appointment time
current order number
selected product

Long-term business memory

Information that should survive the call.

Examples:

customer preferences
previous interactions
account information

Do not put every piece of customer data into the LLM's conversation history.

Retrieve what is needed for the current decision.

7. Handle Interruptions

This is one of the biggest differences between a chatbot and a voice agent.

Imagine the agent is saying:

"Your appointment is scheduled for Thursday at—"

The user interrupts:

"Actually, make that Friday."

A real voice interface should stop speaking.

That means your system needs to support barge-in.

A simplified flow is:

Agent speaking
      ↓
User starts talking
      ↓
Detect interruption
      ↓
Stop TTS playback
      ↓
Cancel/ignore remaining audio
      ↓
Process new user input

Without interruption handling, the system feels less like a conversation and more like an IVR reading a script.

This is why audio transport, turn detection, and cancellation logic are just as important as the LLM.

8. Use WebSockets for Browser-Based Streaming

For a browser-based implementation, WebSockets are a practical transport layer.

The client captures microphone audio:

Browser microphone
       ↓
PCM audio chunks
       ↓
WebSocket
       ↓
Backend

The backend sends synthesized audio back through the same connection:

Backend
   ↓
TTS audio chunks
   ↓
WebSocket
   ↓
Browser
   ↓
Speaker

LangChain's reference voice application uses WebSockets for bidirectional audio streaming and notes that the same general architecture can be adapted to telephony or WebRTC.

The important design decision is to keep the transport layer independent from the agent.

Your agent should not care whether the request came from:

a browser
a mobile application
a phone call
a WebRTC client

It should receive an input event and return agent events.

9. Connect the Pieces with an Async Pipeline

A simplified LangChain pipeline can conceptually look like:

from langchain_core.runnables import RunnableGenerator

pipeline = (
    RunnableGenerator(stt_stream)
    | RunnableGenerator(agent_stream)
    | RunnableGenerator(tts_stream)
)

Each stage consumes and produces a stream.

STT events
    ↓
Agent events
    ↓
TTS events

This is more useful than treating the voice agent as one giant function.

Each stage can be measured independently.

For example:

Audio received
     ↓
STT first transcript       180 ms
     ↓
Agent first token          220 ms
     ↓
TTS first audio            160 ms
     ↓
User hears response       ~560 ms

These measurements tell you where the actual bottleneck is.

10. Measure the Right Latency

Do not measure only total API response time.

For voice systems, track at least:

Time to first transcript

How quickly does the system understand the user's speech?

Time to first token

How quickly does the agent begin responding?

Time to first audio

How quickly does the user hear the response?

Total response duration

How long does the agent take to finish speaking?

Tool latency

How long do external API calls take?

For example:

User finishes speaking
        │
        ├── STT: 210 ms
        │
        ├── Agent starts: 35 ms
        │
        ├── CRM API: 420 ms
        │
        ├── LLM first token: 180 ms
        │
        └── TTS first audio: 140 ms

If your first-audio latency is 1.2 seconds, changing the LLM may not solve the problem if the real bottleneck is a 700 ms CRM API.

11. Make External Tools Fast

Voice agents expose slow backend systems immediately.

Imagine:

Voice input
 ↓
Agent
 ↓
CRM
 ↓
Database
 ↓
Payment API
 ↓
Agent
 ↓
TTS

Even if your LLM is extremely fast, the conversation can feel slow because of downstream services.

Use:

timeouts
retries where safe
caching
parallel API requests where possible
lightweight tool responses
asynchronous execution

For example, if the agent needs customer information and appointment availability, those lookups may not always need to happen sequentially.

But be careful with parallel execution when tools have side effects.

Reading two systems in parallel is very different from creating two appointments simultaneously.

12. Add Failure Handling Before Production

Voice agents fail differently from chatbots.

Potential failures include:

STT misses a word
user speaks over the agent
network drops
TTS fails
tool times out
LLM generates an invalid tool argument
user changes their request halfway through
external API returns incomplete data

The agent should have explicit fallback behavior.

For example:

Tool timeout
     ↓
Retry if operation is safe
     ↓
Still failing?
     ↓
Tell the user
     ↓
Offer alternative action

Never let the model hide a failed transaction by pretending it succeeded.

For actions such as payments, bookings, cancellations, or account changes, the system should verify the actual backend result before confirming completion.

13. Where LangChain Helps — and Where It Doesn't

LangChain is useful for:

agent orchestration
tool calling
model abstraction
conversation state
streaming agent output
integrating business tools
connecting the agent to LangGraph-based workflows

But LangChain is not your complete voice infrastructure.

You still need to solve:

microphone capture
audio encoding
WebSockets/WebRTC
speech recognition
voice synthesis
interruption handling
latency management
telephony integration, if applicable
production monitoring

Think of LangChain as the reasoning and orchestration layer, not the entire voice stack.

14. When LangGraph Becomes Important

A simple voice assistant might only need:

User → Agent → Tool → Response

A business workflow can become more complicated:

Incoming call
      ↓
Identify customer
      ↓
Understand intent
      ↓
Check account
      ↓
Determine eligibility
      ↓
Call external system
      ↓
Human approval?
   ↙       ↘
 Yes        No
 ↓           ↓
Human       Complete
review

This is where graph-based orchestration becomes valuable.

LangChain's current create_agent implementation already uses LangGraph underneath, while direct LangGraph workflows are useful when you need more explicit control over state, branching, persistence, interrupts, or complex workflows.

The important point is:

Do not add LangGraph simply because you are building a voice agent. Add graph-level orchestration when the workflow actually needs it.

15. A Production Voice Agent Architecture

A practical production architecture could look like this:

                    ┌──────────────────┐
                    │   Web / Mobile   │
                    │  / Phone Client  │
                    └────────┬─────────┘
                             │
                       Audio Stream
                             │
                             ▼
                    ┌──────────────────┐
                    │  Audio Gateway   │
                    │ WebSocket/WebRTC │
                    └────────┬─────────┘
                             │
                             ▼
                    ┌──────────────────┐
                    │       STT        │
                    └────────┬─────────┘
                             │
                          Transcript
                             │
                             ▼
                    ┌──────────────────┐
                    │ LangChain Agent  │
                    │                  │
                    │ State + Tools    │
                    └───────┬──────────┘
                            │
                ┌───────────┼───────────┐
                ▼           ▼           ▼
             CRM/API    Database    Calendar
                │           │           │
                └───────────┼───────────┘
                            │
                            ▼
                    Agent Response
                            │
                            ▼
                    ┌──────────────────┐
                    │       TTS        │
                    └────────┬─────────┘
                             │
                             ▼
                       Audio Stream
                             │
                             ▼
                            User

This architecture has an important property:

Every layer can evolve independently.

You can replace the STT provider without rebuilding the agent.
You can replace the LLM without rebuilding the audio gateway.

You can replace the CRM without changing the voice interface.
That is what makes the architecture suitable for production.

Conclusion

Building a voice agent with LangChain is not primarily about writing an LLM prompt.

The difficult engineering work is around the LLM:

streaming audio
reducing time-to-first-audio
managing conversation state
designing voice-specific tools
handling interruptions
controlling external API latency
validating side effects
recovering from failures
monitoring complete conversations

LangChain gives you a strong agent and tool-orchestration layer, while the voice infrastructure handles the real-time UI interface. Its current documentation demonstrates this separation through a streaming STT → LangChain agent → TTS architecture.

If you’re planning to take this architecture beyond a prototype and build a production-ready voice system with custom workflows, backend integrations, multilingual support, monitoring, and low-latency interactions, explore Ciphernutz’s AI Voice Agent Development services.

The goal is not to make an LLM speak. The goal is to make a business workflow conversational without making it unreliable.

Build a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

Caper B — Wed, 12 Aug 2026 18:22:59 +0000

Build a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

LangChain is a powerful framework for building AI agents that can interact with the world in various ways. In this tutorial, we'll explore how to build an AI agent that can earn money by automating tasks and providing value to users. We'll cover the technical aspects of building the agent, as well as the monetization strategies to make it profitable.

Step 1: Setting up LangChain

To get started with LangChain, you'll need to install the langchain library using pip:

pip install langchain

Once installed, you can import the library and create a new LangChain agent:

import langchain

agent = langchain.LLMLAgent()

Step 2: Defining the Agent's Capabilities

Next, you'll need to define the capabilities of your AI agent. This can include tasks such as text generation, language translation, or data analysis. For this example, let's say we want our agent to generate affiliate marketing content:

agent.add_capability("text_generation", langchain.TextGenerationCapability())

Step 3: Integrating with Affiliate Marketing Platforms

To monetize our agent, we'll need to integrate it with an affiliate marketing platform. Let's use the Amazon Associates API as an example:

import amazon_api

amazon_api = amazon_api.AmazonAPI("YOUR_API_KEY", "YOUR_API_SECRET")
agent.add_capability("affiliate_marketing", langchain.AffiliateMarketingCapability(amazon_api))

Step 4: Training the Agent

To train our agent, we'll need to provide it with a dataset of examples. For this example, let's use a dataset of product reviews:

import pandas as pd

reviews = pd.read_csv("product_reviews.csv")
agent.train(reviews, "text_generation")

Step 5: Deploying the Agent

Once our agent is trained, we can deploy it to a cloud platform such as AWS or Google Cloud. Let's use AWS Lambda as an example:

import aws_lambda

aws_lambda = aws_lambda.AWSLambda("YOUR_AWS_KEY", "YOUR_AWS_SECRET")
agent.deploy(aws_lambda)

Monetization Strategies

Now that our agent is deployed, let's discuss some monetization strategies:

Affiliate marketing: Our agent can generate affiliate marketing content and earn commissions for each sale made through its unique referral link.
Sponsored content: Our agent can generate sponsored content for brands and earn revenue for each piece of content created.
Data analysis: Our agent can analyze data for clients and earn revenue for its insights and recommendations.

Example Use Case

Let's say we want our agent to generate affiliate marketing content for a new product launch. We can use the following code:

product = {"name": "New Product", "description": "This is a new product"}
content = agent.generate_text(product, "affiliate_marketing")
print(content)

This would output a piece of affiliate marketing content that our agent can use to promote the product and earn commissions.

Conclusion

In this tutorial, we've built a profitable AI agent using LangChain that can earn money by automating tasks and providing value to users. We've covered the technical aspects of building the agent, as well as the monetization strategies to make it profitable. By following these steps and using the code examples provided, you can build your own AI agent and start earning money today.

Get started with LangChain today and start building your own profitable AI agent! Sign up for a free trial and start exploring the possibilities of AI-powered automation.

LCEL vs. Legacy Chains: From Recipe Confusion to Clear Pipelines 🚀

Charles Uwagbale — Wed, 12 Aug 2026 01:02:56 +0000

TL;DR: Legacy Chains are the old way—rigid, class-heavy, and frustrating. LCEL is the new standard—visual, modular, and future-proof. Always choose LCEL for new projects.

😫 The Frustration (The Legacy Way)

Building a chain in LangChain used to feel like following a recipe where every ingredient was labeled differently in every cookbook.

"Add input_documents"—wait, is that the same as docs? What about context? And why does this chain expect llm but that one expects model?

🧠 You had to memorize specific class names (LLMChain, ConversationChain).
🙏 You prayed your inputs matched the variable names perfectly (input_documents vs. docs).
🐛 Debugging meant printing variables mid-way through.

🏛️ What is the Legacy Chain?

It is the "Old Class Way." You tell the computer how to store memory and how to loop. You create an object, pass parameters to its constructor, and call .run().

⚡ What is LCEL?

It is the "New Pipe Way." You tell the computer what the flow is—LCEL optimizes the how for you. You define a sequence using the | symbol, like an assembly line where each component passes its output to the next.

💡 The "Aha!" Moment

LCEL fixes this by treating your workflow like a plumbing pipe—no more guesswork, just clear connections. You connect sections together using the | (pipe) operator. Data flows in one end and comes out the other. No magic, just plumbing.

⚔️ Side-by-Side Showdown

Legacy (Old):

from langchain.chains import LLMChain
chain = LLMChain(llm=llm, prompt=prompt)
result = chain.run("Hello")

LCEL(New):

from langchain_core.output_parsers import StrOutputParser
chain = prompt | llm | StrOutputParser()
result = chain.invoke({"input": "Hello"})

Notice the difference? No class names to memorize. No guessing about method names. Just a visual pipeline that reads like a recipe.

😱The Composability Nightmare (Legacy)

Imagine you have a chatbot that answers questions from documents. In Legacy, you'd write:

from langchain.chains import RetrievalQA
# One class for retrieval...
retrieval_chain = RetrievalQA.from_chain_type(llm, retriever=retriever)

Now imagine you want to:

📝 Add a summarization step?

📊 Log every prompt to a database?

🧠 Route questions to different models based on complexity?

In Legacy, each change required rewriting the entire class or hunting for a specific subclass.

🧱The Composability Paradise (LCEL)

In LCEL, everything is a LEGO brick. Need to add a summarizer? | it in. Want to log prompts? | a logger between the prompt and the LLM.

# LCEL: Mix, match, and extend
chain = (
    retriever 
    | prompt 
    | logging_middleware   # Your custom step!
    | llm 
    | summarizer           # Another custom step!
    | output_parser
)

The magic: Every component in LCEL uses the same interface. That means:

🔄 You can reuse any chain inside another chain.
🌿 You can branch into parallel chains.
🔧 You can swap components without breaking everything.

Composability is not a feature; it's the architecture.

🏆 The 4 Core Upgrades

👀 Explicit over Implicit: LCEL shows the data flow visually. No more guessing what goes where.
📡 Built-in Streaming: Legacy forces you to wait. LCEL allows chain.stream() out of the box.
🧩 Composability: In LCEL, if you can pipe it, you can chain it. Mix and match components freely.
🎯 Standardized Interface: Everything uses the same methods (.invoke(), .stream(), .batch()). Learn once, use everywhere.

⚠️ Watch Out: The "Too Much Piping" Trap

LCEL is powerful, but don't overdo it. A chain with 10+ pipes becomes hard to debug.

Good:

chain = prompt | llm | parser  # 3 steps

Bad:

chain = retriever | prompt | llm | parser | memory | router | fallback | logger  # 8+ steps

Rule of thumb: If your chain doesn't fit on one screen, split it into smaller sub-chains.

✅ When to use which?

✅ Use LCEL: For new projects, production APIs, and streaming chatbots.
❌ Use Legacy: Only if you are patching a production bug in an old system and cannot refactor.

📚 Watch out for next article

Runnables Explained: From Zero to Hero with .invoke(), .stream(), and .batch()

Feedback: Your opinion matters. Leave a comment with your biggest takeaway or a question you still have.

Build a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

Caper B — Tue, 11 Aug 2026 10:22:33 +0000

Build a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

LangChain is a powerful framework for building AI agents that can interact with the world. In this tutorial, we'll show you how to create an AI agent that can earn money by automating tasks and providing value to users.

Prerequisites

Before we begin, make sure you have the following installed:

Python 3.8+
LangChain library (pip install langchain)
A LangChain-compatible LLM (Large Language Model) such as LLaMA or PaLM

Step 1: Set up Your LangChain Environment

To start, you'll need to set up your LangChain environment. This involves creating a new LangChain project and configuring your LLM.

import langchain

# Create a new LangChain project
project = langchain.Project(name="profitable_agent")

# Configure your LLM
llm = langchain.LLM(
    model_name="llama",
    model_size="7b",
    max_tokens=2048,
    temperature=0.7,
    top_p=0.95,
    frequency_penalty=0.0,
    presence_penalty=0.0,
)

Step 2: Define Your Agent's Goals and Objectives

Next, you'll need to define your agent's goals and objectives. What tasks do you want your agent to automate? What value do you want it to provide to users?

# Define your agent's goals and objectives
agent_goals = [
    "Automate data entry tasks",
    "Provide customer support",
    "Generate high-quality content",
]

Step 3: Train Your Agent

Now it's time to train your agent. You'll need to provide your agent with a dataset of examples that demonstrate the tasks you want it to automate.

# Load your dataset
dataset = langchain.Dataset.from_csv("data.csv")

# Train your agent
agent = langchain.Agent(
    llm=llm,
    dataset=dataset,
    goals=agent_goals,
    max_steps=1000,
    learning_rate=0.001,
)

Step 4: Deploy Your Agent

Once your agent is trained, you can deploy it to a production environment. You can use a cloud platform like AWS or Google Cloud to host your agent.

# Deploy your agent to a cloud platform
agent.deploy(
    platform="aws",
    region="us-west-2",
    instance_type="t2.micro",
)

Step 5: Monetize Your Agent

Now that your agent is deployed, you can start monetizing it. Here are a few ways you can earn money with your agent:

Freemium model: Offer a basic version of your agent for free and charge for premium features.
Subscription model: Charge users a monthly or yearly fee to access your agent.
Advertising model: Display ads to users and earn revenue from clicks or impressions.

For example, you can use a library like stripe to handle payments and subscriptions.

import stripe

# Set up Stripe
stripe.api_key = "your_stripe_api_key"

# Create a payment plan
plan = stripe.Plan.create(
    amount=1000,
    interval="month",
    currency="usd",
    product="your_product_id",
)

Conclusion

In this tutorial, we showed you how to build a profitable AI agent with LangChain. By following these steps, you can create an agent that automates tasks and provides value to users. With the right monetization strategy, you can earn significant revenue with your agent.

Get started today and build your own profitable AI agent with LangChain. Join the LangChain community and start building your agent now. Get started with LangChain.

LangGraph Practical Guide: When to Use It Over LangChain

Amrendra N Mishra — Tue, 11 Aug 2026 03:01:49 +0000

Why Automate Content Creation

Creating content manually for 9 channels would take 8+ hours daily. I have a full-time job as VP at JPMorgan. The math doesnt work.

The Pipeline

Trending Topic CSV
       ↓
  AI Script (Ollama/Gemini)
       ↓
  Google Cloud TTS (Voice)
       ↓
  Pexels Images + MoviePy Video
       ↓
  YouTube API Upload

Scheduling with Mac LaunchAgents

<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.gyaaninfive.youtube</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/python3</string>
    <string>/path/to/upload.py</string>
  </array>
  <key>StartCalendarInterval</key>
  <dict>
    <key>Hour</key><integer>18</integer>
    <key>Minute</key><integer>15</integer>
  </dict>
</dict>
</plist>

One plist per channel. Runs at the exact scheduled time.

Total Monthly Cost

Google Cloud TTS: Free (4M chars/month)
Pexels API: Free
YouTube API: Free
Ollama: Free (local)

Total: ₹0/month

Full code on GitHub

9 channels. Daily uploads. Zero manual work.

Understanding the Deep Agents Interpreter with Programmatic Tool Calling

Syeed Talha — Mon, 10 Aug 2026 08:44:46 +0000

Tool calling is an important part of AI agents. It allows a model to search the web, query a database, call an API, or perform another external action.

Normal tool calling works well for simple tasks. But it becomes less efficient when an agent needs to call the same tool many times, process intermediate results, or run several independent operations in parallel.

This is the problem the Deep Agents interpreter solves.

What is the Deep Agents interpreter?

The interpreter gives a Deep Agent a small, in-memory JavaScript environment powered by QuickJS.

Instead of asking the model to manage every tool call separately, the model can write JavaScript that:

Calls approved tools
Runs loops
Handles conditional logic
Retries failed operations
Runs independent calls in parallel
Filters and combines results

Only the final result of that JavaScript execution is returned to the model.

In simple terms, the model decides what work should be done, while JavaScript handles how the repeated work should be organized.

What happens without an interpreter?

Suppose an agent needs to research three topics:

Retrieval
Memory
Evaluation

Without an interpreter, the workflow may look like this:

Model calls the retrieval search tool
→ Model receives the result

Model calls the memory search tool
→ Model receives the result

Model calls the evaluation search tool
→ Model receives the result

Model combines all results
→ Model writes the answer

Every result returns to the model before the next step can be decided.

This creates several problems:

More model turns

The model may need to repeatedly call a tool, read its output, and decide what to do next.

Larger model context

Every intermediate tool result becomes part of the model’s context, even when the result only needs to be filtered or passed to another step.

Unreliable repeated calls

Asking a model to perform the same operation across many items does not guarantee that every item will be processed consistently.

Limited workflow control

A normal batch of tool calls is fixed when the model creates it. The model cannot loop, retry, branch on a result, or feed one result into another call without an additional model turn.

How the interpreter changes the workflow

With an interpreter, the workflow becomes:

Model creates one JavaScript program
→ JavaScript calls all approved tools
→ JavaScript processes and combines the results
→ Model receives one combined result
→ Model writes the final answer

For our three research topics, JavaScript can run all searches at the same time:

const topics = ["retrieval", "memory", "evaluation"];

const results = await Promise.all(
  topics.map((topic) =>
    tools.webSearch({
      query: `${topic} best practices`,
    }),
  ),
);

results.join("\n\n");

Promise.all() runs the independent searches in parallel. The interpreter then combines the results before returning them to the model.

Complete example

The following agent searches for retrieval, memory, and evaluation best practices in parallel.

import os

from dotenv import load_dotenv
from deepagents import create_deep_agent
from langchain.tools import tool
from langchain_nvidia_ai_endpoints import ChatNVIDIA
from langchain_quickjs import CodeInterpreterMiddleware
from tavily import TavilyClient


load_dotenv()


@tool
def web_search(query: str) -> str:
    """Search the web and return a compact text summary of the results."""

    # Create the Tavily search client.
    client = TavilyClient(
        api_key=os.environ["TAVILY_API_KEY"]
    )

    # Search the web and limit the response to three results.
    response = client.search(
        query=query,
        max_results=3,
    )

    # Convert the search results into compact text.
    return "\n".join(
        f"- {item['title']}: {item['content']} ({item['url']})"
        for item in response["results"]
    )


def build_agent():
    """Create an agent with programmatic access to web_search."""

    # Create the language model used by the agent.
    model = ChatNVIDIA(
        model=os.getenv(
            "NVIDIA_MODEL",
            "nvidia/nemotron-3-super-120b-a12b",
        ),
        api_key=os.environ["NVIDIA_API_KEY"],
        temperature=0.0,
        max_completion_tokens=1024,
    )

    # Create the Deep Agent and enable the interpreter.
    return create_deep_agent(
        model=model,
        tools=[web_search],
        middleware=[
            CodeInterpreterMiddleware(
                # Allow JavaScript to call the web_search tool.
                ptc=["web_search"],

                # Disable dynamic subagents for this example.
                subagents=False,
            )
        ],
        system_prompt="""
You are a research assistant demonstrating programmatic tool calling.

For research questions, make exactly one eval tool call. Inside that one call,
write JavaScript that calls tools.webSearch({query}) rather than calling
web_search directly.

When there are several independent topics, use Promise.all to search them
in parallel. Combine the results in JavaScript and return only the combined
research notes before writing a concise answer for the user.

Never issue separate web_search calls or multiple eval calls for the same
request.
""",
    )


if __name__ == "__main__":
    # Build the configured agent.
    agent = build_agent()

    # Send a research request to the agent.
    result = agent.invoke(
        {
            "messages": [
                (
                    "user",
                    "Compare current best practices for retrieval, memory, "
                    "and evaluation in LLM applications. Search each topic "
                    "in parallel with the interpreter, then summarize the "
                    "three most useful practices and include source URLs.",
                )
            ]
        }
    )

    # Print the final response produced by the agent.
    print(result["messages"][-1].content)

How the code works

1. The search tool

The web_search function is a regular Python tool:

@tool
def web_search(query: str) -> str:

It sends the query to Tavily and returns three compact search results.

By itself, the agent can call this tool through normal tool calling. However, we also want the interpreter’s JavaScript code to be able to use it.

2. The interpreter middleware

The interpreter is added through CodeInterpreterMiddleware:

middleware=[
    CodeInterpreterMiddleware(
        ptc=["web_search"],
        subagents=False,
    )
]

This middleware adds an eval tool to the agent. The model uses that tool to execute JavaScript inside QuickJS.

You do not call eval manually in the Python code. The agent decides when to use it based on the request and system prompt.

3. Programmatic Tool Calling

The following option enables Programmatic Tool Calling, or PTC:

ptc=["web_search"]

This is an explicit allowlist. It means the JavaScript interpreter can call web_search, but it cannot automatically access every Python tool or system capability.

Inside JavaScript, Python tool names are converted to camel case:

web_search → tools.webSearch

The tool can therefore be called like this:

const result = await tools.webSearch({
  query: "retrieval best practices",
});

4. The system prompt

The system prompt tells the model to make one eval call and perform the searches inside it.

It also instructs the model to use:

Promise.all(...)

This is important because retrieval, memory, and evaluation are independent topics. There is no reason to wait for one search to finish before starting the next one.

5. The agent request

The user asks the agent to research three topics:

result = agent.invoke(
    {
        "messages": [
            (
                "user",
                "Compare current best practices for retrieval, memory, "
                "and evaluation in LLM applications.",
            )
        ]
    }
)

The agent can respond by generating JavaScript similar to this:

const topics = ["retrieval", "memory", "evaluation"];

const results = await Promise.all(
  topics.map((topic) =>
    tools.webSearch({
      query: `${topic} best practices`,
    }),
  ),
);

results.join("\n\n");

QuickJS executes the JavaScript, calls the Python search tool three times, and combines the results.

The model receives the combined research notes rather than three separate intermediate tool responses.

What the interpreter cannot do by default

The interpreter is an in-memory JavaScript runtime, not a complete operating-system environment.

By default, it cannot directly:

Access the network
Read or write files
Run shell commands
Install packages
Access system resources

Network access in this example comes only from the allowlisted web_search tool.

If you need shell commands, package installation, testing, or filesystem access, a sandbox is the more appropriate option.

When should you use an interpreter?

Use an interpreter when an agent needs to:

Call a tool for many items
Run independent calls in parallel
Retry failed calls
Branch based on tool results
Filter or aggregate structured data
Keep intermediate results out of the model context

For one or two simple tool calls, normal tool calling is usually enough.

Final takeaway

The Deep Agents interpreter moves repetitive orchestration from the model into JavaScript.

Without it, the model must manage more intermediate tool calls and results. With it, the agent can make one eval call, execute a complete workflow, and receive only the combined result.

The main pattern is:

Model
→ One eval call
→ JavaScript orchestration
→ Approved Python tools
→ Combined result
→ Final answer

This is especially useful for research, batch processing, data transformation, and other workflows that involve many related tool calls.

I Built an AI Agent That Thinks Before It Answers — And Loops Back When It Doesn't Know Enough

Ayush Singh Tomar — Mon, 10 Aug 2026 03:30:04 +0000

Most AI projects look like this:

User Input → LLM → Output

That's not an agent. That's autocomplete with a UI.

AgentLoop is different. Give it a research topic and it:

Checks if it already researched something similar (long-term memory)
Breaks the topic into targeted sub-questions
Decides per sub-question whether to call a live web search tool
Re-reads its own notes and routes itself back into research if it finds gaps
Only then writes a structured, sourced report
Saves the run to memory for next time The loop in the middle — where the agent judges its own output and decides to keep going — that's what makes it genuinely agentic. Not the LLM. The decision-making around it.

Live demo: agentloop.streamlit.app
GitHub: github.com/ayush-s-tomar/agentloop

What It Does

You type a research topic. The agent runs a 6-node pipeline:

[Recall] → [Plan] → [Research] → [Reflect] → [Synthesize] → [Persist]
                                      ↑               |
                                      └───────────────┘
                                    (loops back if gaps found)

Recall — checks SQLite long-term memory for related past research. If it finds something relevant, it loads those notes as context before planning. Avoids re-researching the same ground twice.

Plan — the LLM breaks the topic into 3–5 specific sub-questions. Not "tell me about X" — actual targeted questions like "what companies are deploying X in production?" and "what are the failure modes of X?"

Research — for each sub-question, the LLM decides whether to call the Tavily web search tool. Not every sub-question needs a search — sometimes the answer follows from earlier notes. This is genuine tool-use, not hardcoded search-every-time.

Reflect — the node I'm most proud of. The agent re-reads everything it's gathered and asks: is this complete? Are there gaps? If yes, it routes back into Research for another loop. If no, it moves forward. Bounded at 3 iterations so it can't loop forever.

Synthesize — writes a structured markdown report from all gathered notes and search results. Citations included.

Persist — saves the full run to SQLite: topic, sub-questions, sources, report. Available for recall on future runs.

Architecture

The 6-node graph, including the reflect → research loop-back.

Topic input, live trace, and the generated report — all in one Streamlit view.

Stack: LangGraph · Streamlit · Groq (llama-3.1-8b-instant) · Tavily · SQLite · Streamlit Cloud

How Each Part Works

1. The Reflect Node — Conditional Loop-Back

This is the decision that separates AgentLoop from a linear pipeline.

After Research runs, instead of immediately synthesizing, the agent hits the Reflect node:

def reflect_node(state: AgentState) -> AgentState:
    notes = "\n".join(state["notes"])
    sub_questions = "\n".join(state["sub_questions"])

    prompt = f"""You researched these questions:
{sub_questions}

Here are your notes so far:
{notes}

Are there significant gaps? Answer YES or NO, then explain."""

    response = llm.chat([{"role": "user", "content": prompt}], system="Be critical.")

    has_gaps = response.strip().upper().startswith("YES")
    iterations = state.get("reflect_iterations", 0)

    return {
        **state,
        "needs_more_research": has_gaps and iterations < 3,
        "reflect_iterations": iterations + 1
    }

The LangGraph conditional edge routes based on needs_more_research:

graph.add_conditional_edges(
    "reflect",
    lambda state: "research" if state["needs_more_research"] else "synthesize"
)

The iteration cap (iterations < 3) is non-negotiable. Without it, a loop-happy LLM spins forever on ambiguous topics. With it, the worst case is 3 research passes — still far more thorough than one.

2. Two-Layer Memory

Short-term (within a run): state["notes"] — a list that accumulates across all Research iterations. Each tool call appends its findings. The Reflect and Synthesize nodes see the full accumulated picture, not just the last search.

Long-term (across runs): SQLite with a simple schema — topic, sub-questions, notes, report, timestamp. The Recall node queries this by keyword similarity at the start of every run. Not vector search (that's the next step) — just SQL LIKE matching, which is good enough for a portfolio project and dead simple to reason about.

def recall_node(state: AgentState) -> AgentState:
    topic = state["topic"]
    words = [w for w in topic.lower().split() if len(w) > 4]

    past_runs = []
    for word in words[:3]:  # top 3 keywords
        results = db.search_by_keyword(word)
        past_runs.extend(results)

    context = format_past_runs(past_runs[:2])  # most recent 2 matches
    return {**state, "memory_context": context}

3. Tool-Calling — Decision Per Sub-Question

The LLM doesn't call web search blindly. It receives the tool schema and decides per sub-question:

TOOLS = [{
    "name": "web_search",
    "description": "Search the live web for current information",
    "parameters": {
        "type": "object",
        "properties": {
            "query": {"type": "string", "description": "Search query"}
        },
        "required": ["query"]
    }
}]

For factual sub-questions about current events, it calls the tool. For sub-questions it can reason about from existing notes, it doesn't. That's the distinction between a real agent and a search wrapper.

What Broke (The Honest Part)

1. Render Kept Suspending the Live Demo — So I Moved to Streamlit

The original architecture was FastAPI + React, streaming the live trace to the frontend via Server-Sent Events — each node completion fired an SSE event, the UI updated in real time.

It worked perfectly locally. On Render's free tier, SSE died after 30 seconds — Render closes long-lived HTTP connections on the free plan, and a 6-node agent with multiple web searches takes longer than that. I patched around it with background tasks + polling (the frontend polling /api/research/status/{job_id} every 2 seconds instead of holding a stream open), and that solved the timeout.

But the deeper problem was the platform itself. Render's free web services spin down on inactivity and get suspended monthly, so the live demo link kept going cold between visitors regardless of the polling fix. That's not something you patch — it's the tier's actual model. So I migrated off FastAPI + React entirely onto a single-file Streamlit app, reusing the agent/ and memory/ modules unchanged, deployed to Streamlit Community Cloud. No backend process to suspend, no SSE-vs-polling tradeoff to manage — Streamlit re-runs the script and renders state directly on each interaction.

Lesson: design for the deployment environment, not just localhost — and sometimes the right fix isn't a smarter workaround, it's picking a host whose free-tier model actually matches how the project gets used (an occasional demo click-through, not a service that needs to stay warm).

2. Model Deprecations — Three Times

Groq deprecated models mid-development, more than once:

llama-3.3-70b-versatile → deprecated
llama3-70b-8192 → decommissioned
llama3-groq-70b-8192-tool-use-preview → tool-calling broken Each one failed silently or with a cryptic error. Ended up on llama-3.1-8b-instant — smaller, but stable and actively maintained.

Lesson: never hardcode a model string. It belongs in an environment variable:

MODEL = os.getenv("GROQ_MODEL", "llama-3.1-8b-instant")

One env var change, no redeployment needed when the next deprecation hits.

3. Rate Limits Hit During Demo Recording

Groq's free tier is 100k tokens/day. Between development testing, debugging, and demo runs, I exhausted the quota on the same day I tried to record the LinkedIn screenshot. Two hours lost waiting for reset.

Lesson: keep a separate Groq API key for demos. Never use the dev key for production.

4. Python 3.14 Broke the Old Render Build

Back when this was still FastAPI on Render, pydantic-core had no wheel for Python 3.14 — silent build failure, no clear error, just a broken deploy. The fix was one environment variable (PYTHON_VERSION = 3.11.9) pinning the runtime explicitly instead of trusting the host default.

It's moot now that the app is Streamlit-only with a much smaller dependency surface, but the underlying lesson traveled with the migration: pin your Python version explicitly on any host, don't trust the default.

What I'd Do Differently

Replace SQL LIKE matching with vector search. Right now the Recall node finds past runs by keyword — it misses semantically similar research with different wording. ChromaDB or Supabase pgvector would fix this. It's the most meaningful upgrade this project needs.

Add a second tool. Right now the only tool is web_search. A calculator or structured data lookup would demonstrate the LLM genuinely choosing between tools — not just "search or not." That's a stronger tool-use story.

Instrument the reflect loop. I don't log how often the agent actually loops back vs. goes straight to synthesis. That metric would tell me whether the reflect node is earning its latency or just adding overhead.

Define the LLM interface contract on day one. Half my debugging time came from graph.py and llm.py making different assumptions about function signatures and return types. One typed contract file written before any agent logic would have caught all of it.

Try It

Live demo: agentloop.streamlit.app
GitHub: github.com/ayush-s-tomar/agentloop

(If you bookmarked the old agentloop.onrender.com link, it's retired — the app now lives on Streamlit Cloud, for the reasons above.)

Type any research topic and watch the pipeline run step by step — the trace panel shows every node as it executes, so you can see exactly when the agent decides to loop back.

If you're building something similar or have thoughts on the memory architecture, connect with me on LinkedIn.

Build a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

Caper B — Mon, 10 Aug 2026 02:22:05 +0000

Build a Profitable AI Agent with LangChain: A Step-by-Step Tutorial

===========================================================

As a developer, you're likely no stranger to the vast potential of artificial intelligence (AI) in revolutionizing the way we work and earn a living. One of the most exciting recent developments in the AI space is the emergence of LangChain, a powerful framework for building AI agents that can interact with the world in a more human-like way. In this tutorial, we'll walk through the process of building an AI agent with LangChain that can earn money, and explore the monetization possibilities of this technology.

Step 1: Setting Up LangChain

To get started with LangChain, you'll need to install the framework and its dependencies. You can do this by running the following command in your terminal:

pip install langchain

Once installed, you can import LangChain into your Python script and start building your AI agent.

Step 2: Defining the Agent's Objective

Before we can start building our AI agent, we need to define its objective. For the purposes of this tutorial, let's say our agent's goal is to earn money by completing tasks on a freelance platform. We can define this objective using LangChain's Agent class:

from langchain import Agent

agent = Agent(
    objective="earn money by completing tasks on a freelance platform"
)

Step 3: Choosing a Model

LangChain supports a range of AI models, each with its own strengths and weaknesses. For this tutorial, we'll use the LLaMA model, which is well-suited for natural language processing tasks:

from langchain.models import LLaMA

model = LLaMA()

Step 4: Integrating with a Freelance Platform

To earn money, our AI agent will need to interact with a freelance platform. For this tutorial, we'll use the Upwork API, which provides a range of endpoints for searching and applying for jobs:

import requests

upwork_api_key = "YOUR_API_KEY"
upwork_api_secret = "YOUR_API_SECRET"

def search_for_jobs():
    url = "https://api.upwork.com/api/profiles/v2/search/jobs"
    headers = {
        "Authorization": f"Bearer {upwork_api_key}",
        "Content-Type": "application/json"
    }
    response = requests.get(url, headers=headers)
    return response.json()

def apply_for_job(job_id):
    url = f"https://api.upwork.com/api/profiles/v2/jobs/{job_id}/apply"
    headers = {
        "Authorization": f"Bearer {upwork_api_key}",
        "Content-Type": "application/json"
    }
    response = requests.post(url, headers=headers)
    return response.json()

Step 5: Training the Agent

With our model and freelance platform integration in place, we can start training our AI agent to earn money. We'll use a simple reinforcement learning approach, where the agent is rewarded for successfully completing tasks and penalized for failing:


python
def train_agent():
    # Initialize the agent's reward and penalty
    reward = 0
    penalty = 0

    # Loop through a range of tasks
    for task in search_for_jobs():
        # Apply for the task
        application_response = apply_for_job(task["id"])

        # Check if the application was successful
        if application_response["status"] == "accepted":
            # Reward the agent
            reward += 1
        else:
            # Penalize the agent
            penalty += 1

    # Update the agent's objective based on the reward and penalty
    agent.objective = f"earn money by completing tasks on a freelance platform (reward: {reward}, penalty: {penalty})"

# Train the agent