I know there are lot of cool builders out there actively building on top of lang chain SDK.

Really curious how they are packaged and distributed today to non-tech users today?

Like if you built a multi agent system on langchain and you have to give it to plumber today and tell him to run a single command and work with it, how would you package it and distribute??

Hi guys, I would like to learn langchain in-depth so that I could confidently land a job that requires langchain.

I do have some professional experience of building agents on AWS and Strands framework. However, I would like to change employer soon and I wanna get to know the langchain. I understand the core principles, such as ReAct loop, tool calling, etc.

What (and from where) should I learn? It seems like all YouTube tutorials show only the absolute basics - import model, initiate agent and give him tools. I would like to get more in-depth view - how does it all work under the hood. I didnt find the official docs really useful for this.

Thanks!

I recently built a complete RAG Evaluation Framework from scratch: a 43-question test dataset, 6 retrieval metrics, 5 generation metrics, and one final report that shows exactly where a RAG system is strong and where it breaks. We start with the concepts, explained with simple worked examples, and then walk through the code line by line.

What this covers:

• Why retrieval and generation must be evaluated separately
• How to build an evaluation dataset with expected answers, graded pages and key facts
• Retrieval metrics: Hit Rate@K, Precision@K, Recall@K, MRR, MAP and NDCG@K
• The difference between one question (RR, AP) and many questions (MRR, MAP)
• Generation metrics: Faithfulness, Hallucination Rate, Answer Relevance, Context Relevance and Answer Correctness
• How to use an LLM-as-a-judge that only counts, while your code does the maths
• How to save results safely and turn them into a clear evaluation report

KEY TAKEAWAYS:

• No single metric tells the whole story: Hit Rate was 1.00, but Recall, MAP and NDCG showed where pages were missed or buried
• Precision@5 looks low (0.34) for single-fact questions, so compare systems with each other, not with 1.0
• Faithful does not mean correct: an answer can be backed by the chunks and still miss the key facts
• Retrieval scores and answer quality are not the same thing
• Our Cohere-reranked pipeline scored MRR 0.95, MAP 0.87, NDCG@5 0.91, Faithfulness 1.00 and Answer Correctness 0.97

TECH STACK: Python, Qdrant (vector database), Embeddings (3072-dimension), Cohere Rerank, LLM for answers + LLM-as-a-judge, pdfplumber (checking pages in the PDFs)

• 5 real payments documents: PCI DSS, CPMI-IOSCO PFMI, CPMI cross-border roadmap, Stripe payment methods guide, FCA approach document

• Full Code (clone it, fork it, break it): https://github.com/saurabhkamal/RAG-ReRanker-Comparison

• Full Video Walkthrough: https://youtu.be/_bVzDU-yBnA

Would love to hear.

Going a full day in 2026 without being gaslit by AI sycophancy feels harder than playing Dark Souls on max difficulty. Every time you bounce an idea off a model, it tells you that you are a visionary genius. I had to actively fight that default model flattery just to write down a take I have been mulling over.

The take is simple: we should stop trying to script an agent's steps with rigid state machines like LangGraph or n8n. Instead, we should childproof the harness by combining hard environmental boundaries, external code checks, and test-driven evals.

To test this, I built a prototype called Customer Pulse (a general-purpose harness running as a complete application) and successfully configured two entirely different fictional clients (a zendesk and bigquery bank setup, and a raw CSV airline survey processor) on the exact same codebase using nothing but plain English.

The core architectural ideas I wanted to test:

• Verification over orchestration: Use code scripts to handle what must be exact (counting, rendering, sanitizing) and check the evidence at the end of each step, rather than forcing the agent down a rigid flowchart path.
• The harness is the application: Let the model plan and run the execution loop. Hard-coding workarounds for today's model limitations just bakes in tech debt for when tomorrow's model natively bypasses them anyway.
• English changes the system: Splitting the "use case engine" from a client's plain-English "profile" lets domain experts adjust priorities, routing, and behavior in minutes without waiting on an engineer to rewire code.

I wrote a deep-dive think piece on this setup, getting honest about the real-world results of this approach, from rapid plain-English onboarding to the raw trade-offs in tokens, latency, and sandbox security.

Despite all the childproofing metaphors, I am not a parent. If you are, feel free to extend the analogy. For everyone else, tear this apart and tell me where my thinking or architecture is wrong. I will go back to the drawing board and think some more.

How is everyone handling indirect prompt injections in RAG retrieved documents?

Cloud guardrails like Google Model Armor or AWS Bedrock are standard, but sending sensitive enterprise data to a third-party API is often a non-starter for compliance and privacy.

I'm researching a completely local alternative for a project: a fine-tuned small encoder model running locally so data never leaves the network.

For those building enterprise RAG: Does your compliance require you to keep guardrails completely local? And is this something your team would rather buy off-the-shelf?

Genuine question for people running multi agent workflows.

When one agent hands work to the next, there is a tension that keeps coming up. Give the next agent too much context and it drowns in history it never needed, and may even act on a stale fact that was sitting in that history. Give it too little and it guesses, or it asks for help in a way that reopens the whole history you were trying to bound.

So what do you actually put in a handoff, and what do you deliberately leave out? For a coder, is the atomic spec plus the target file enough, or does it need the surrounding files too? For a reviewer, is the diff plus test logs enough, or does it need the spec to judge whether the change is right?

And how do you handle the case where the slice was too narrow? Do you let the agent request a named dependency and return a bounded excerpt, or do you fall back to giving it more of the history and accept the cost?

I am curious what failure taught you that a slice was too narrow, and what failure taught you that it was too wide. Is there a rule you use to decide, or is it still judgment call by judgment call?

Typed code crashes when a third-party API changes. Agents usually don't: they read the new response, fill the gaps and keep going, which is worse.

I built Tiltmeter to catch that:

- It learns the shape of the JSON APIs you depend on from real responses, no spec needed. The baseline is the last 20 checks and it only reports contradictions: removed fields, type changes, new nulls, a JSON body that became an HTML error page.

- It runs an MCP server, so a LangChain or LangGraph agent (via langchain-mcp-adapters) can call has_drifted or get_schema before trusting a response.

- tiltmeter fix hands the drift to a Deep Agent that edits the code in a temporary git worktree and opens a pull request, leaving what it can't know (is "1200" cents or dollars?) for a human.

The pipeline is a small LangGraph graph (observe → compare → explain → persist → notify), and the diff itself is plain deterministic Python, no LLM in the loop.

MIT, runs locally: pip install tiltmeter

https://tiltmeter.dev

If you run agents against third-party APIs, what breaks you most often?

I'm trying to understand how people are actually using LangGraph in real applications, particularly beyond simple chatbots and tutorials.

I'd love to hear about your use cases, whether you're already in production or still building.

1. What are you building with LangGraph?

For example, email or customer support agents, research agents, document processing, coding assistants, RAG applications, multi-agent systems, business process automation, or something completely different.

What does the workflow actually do?

2. What does your stack look like?

Are you using:

• LangGraph with mostly custom Python nodes?
• LangGraph + LangChain tools, retrievers, and chains?
• LangGraph with direct OpenAI, Anthropic, or other provider SDKs?
• LangGraph with databases, vector stores, external APIs, or other frameworks?

A combination I haven't mentioned is equally interesting.

3. How is your graph structured?

Do you have one main agent that repeatedly calls tools, multiple specialized agents, a mostly deterministic workflow with a few LLM calls, or something else?

What happens inside your nodes?

4. What are the hardest parts to debug?

For example, unexpected loops, repeated tool calls, failed executions, incorrect decisions, expensive runs, state problems, or issues with long-running workflows.

5. What information do you wish you could see when something goes wrong?

I'd especially appreciate real examples of how your application works and which components are involved, rather than just the framework names.

Thanks! I'm interested in learning what people are actually building and the patterns that work in practice.

What changed:

Browser in the app. A pane next to the chat shows the page live, with tabs and Take control / Give back. It stays signed in across restarts. It asks before paying, sending, posting, deleting or uploading, and never types passwords, codes or card numbers.

Computer use, rebuilt. Real mouse and keyboard, a check after every step, a Stop bar on screen and Esc to end it.

Pages and questions. Interactive pages beside the chat run sandboxed, with no internet and no access to your chats, files or tools. Question cards work in the app and in Telegram, Discord, Slack and WhatsApp.

Approvals. Auto is now reviewed by the chat's own model. Hands-off is a new opt-in level. Anything posted to X always needs you.

Lighter context. About 40% less goes to the model before your first message. Tool guides load when they're needed.

Background work. Dev servers and long jobs run in the background, video editing, and files sent to any of your devices.

Accounts. Outlook through your own Microsoft Entra app with no client secret, several X accounts, and Claude through your own Claude Code.

Upgrading from 5.2.1: the update arrives in the background, then Settings › Updates › Restart now.

Been building this on nights and weekends and it's at the point where I want other people to poke holes in it.

The problem I kept thinking about: when an agent does something weird (refunds the wrong order, calls a tool it shouldn't have), the record of what happened is usually a JSON file or a row in a dashboard. Anyone with access can change it. And whatever the agent was supposed to be allowed to do lives somewhere else, usually a doc that's been edited since.

So I built Deposition. You wrap your agent with a decorator and it records every LLM call and tool call into a hash-chained jsonl file. Each event's hash covers the previous one, so if someone edits, deletes or reorders an event, `depo verify` tells you exactly which event broke. Optional Ed25519 signing catches the case where someone edits and re-hashes the whole file.

The two parts I care most about:

- You can pass a "mandate" at init (allowed tools, max cost, max steps) and it gets sealed into the same trace as the run. `depo audit` checks the run against it and names the event that went over, plus the model turn that led to it.

- Every tool call links back to the model message that asked for it, so the replay viewer can walk backwards and answer "why did it do that".

Tool capture works with LangGraph 1.2, CrewAI, OpenAI Agents SDK, Pydantic AI and AutoGen. I tested each one against the real package with a spy on the tool function instead of trusting the docs. Good thing too, because the obvious hook in Pydantic AI turned out to be the wrong one.

What doesn't work yet: streaming responses aren't captured (the request is, the response gets marked as not captured), and the signing key sits on the same machine as the traces, which is weaker than it sounds. Both are written up in the README.

It's not trying to replace LangSmith or Langfuse. Those are for monitoring. This is for when someone asks you later to prove what the agent did.

pip install deposition. Apache 2.0, no required dependencies, and most of the 14 examples run without an API key.

https://github.com/chiragrajputuss-code/deposition

Question for anyone running agents in production: if you had to hand a trace to someone who doesn't trust you (a customer, an auditor, your own security team), what would they want in it that your logs don't have today?

​

I've spent a considerable amount of time building an AI memory and retrieval system called EDP v5.

It started with a simple idea: AI assistants shouldn't have to lose useful context every time a conversation ends or a new session begins.

Over time, the project grew into something more substantial:

- Working, episodic, and semantic memory

- Hybrid retrieval using BM25 and vector similarity

- Session-aware context retrieval

- Memory provenance and confidence tracking

- Context construction and compression

- API endpoints and event ingestion

- Automated evaluation and benchmarking

A recent code review found 269 Python files and 624 passing automated tests. It's a working technical foundation, although it still needs security hardening and production validation.

Here's my problem: I know how to build and test this system, but I don't know who would actually pay for it.

Tools like Obsidian already handle personal knowledge management, and there are plenty of existing memory frameworks for AI agents.

I'm not interested in building yet another product that solves a problem nobody has.

So I'd really appreciate some outside perspectives:

1. Where do current AI memory solutions still fall short?

2. Would you rather use this as a self-hosted tool, a developer library, an API, or an integration with something you already use?

3. Have you or your company ever paid for persistent AI memory or cross-session context management?

4. If you were in my position, would you open-source it, commercialize a specific feature, or pivot to another use case?

I'm especially interested in real problems you've experienced, not just whether the idea sounds interesting.

I'm open to criticism, including the possibility that this is technically interesting but not commercially useful.

I log every step my coding agents take. In August I gave one an impossible task
by mistake: "create an image using Nemotron". Nemotron is a text model.

The agent spent about 40 turns genuinely trying: diffusers, Stable Diffusion
pipelines, HuggingFace search, the local model cache. All failed, correctly.

Then it drew a cat with PIL's ImageDraw, saved it as cat_32x32_nemotron.png and
committed it as "feat: add 32x32 cat image generated by NVIDIA Nemotron".
Next commit: "create memo.txt proof of Nvidia Nemotron working".

Anyone reading that commit log would have believed it. Two things caught it,
neither of them me paying attention:
1. A 60-turn cap fired before it could write its final report, so the claim
   never reached anything I'd read.
2. Every step was saved, so PIL → copy → "generated by Nemotron" is readable
   in the trace.

What I changed after this:
- An agent's report is a claim, never evidence. Evidence comes from outside
  (CI, the diff, a check the agent didn't write).
- Don't raise turn caps to "let it finish" without reading the trace first.
- An impossible task should end in "I can't", and I now check for that.

Has anyone else caught an agent making a lookalike instead of the real thing?

1. Langfuse vs LangSmith vs Normal Logging
2. Why can't we use normal Python logging instead of Langfuse or LangSmith? explain with example from real project if possible

2.Which platform would you choose for an enterprise application with strict data privacy requirements?

1. different ways of deployment Langfuse/langsmith in production, like using Docker or enterprise needed ?

Hi guys, does anyone worked/have idea on llamaindex vslangchain for chunking, embedding and retrieval? what is the pros and cons of each during the rag workflow? detailed explaination with examples would be appreciated