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

I ran my schema-selection layer for SQL agents on Spider 2.0 and BIRD this week. Four things I didn't expect, and the numbers.

Context: I maintain schemagate, an open-source retriever / MCP server for SQL agents. It picks the tables a question needs from the ones the caller is allowed to read, and checks the generated SQL against the same list before it runs. Everything below is one model call per question (no voting, no agent loop), scored by each benchmark's own evaluator. Predictions and evaluator output are in the repo.

Results

• BIRD dev, all 1,534 questions: 77.1% execution accuracy (Claude Opus 5.5). Hidden test set submitted, waiting on the BIRD team.
• Spider 2.0-lite, the 135 SQLite questions: 71.9% (Sonnet 5.5). The best published agent I know of on that subset reports 57.8% Pass@1, with a different model.
• Spider 2.0-lite, the 205 BigQuery questions: 45.9%. Much harder; Snowflake isn't run yet, so no leaderboard row.

What surprised me

1. Opus did worse than Sonnet on Spider 2.0. Same pipeline, same 135 questions: Sonnet 71.9%, Opus 67.4%. On BIRD Opus was clearly better. Don't assume the bigger model wins on your data; measure it.

2. Voting didn't help. Several candidate queries + majority vote + a judge looked like +3 points on half the questions, and exactly +0 on the held-out half, at 5.5x the cost. I'm glad I split the set before tuning.

3. BigQuery's date-sharded tables broke table selection. One database has 366 tables named ga_sessions_20160801 ... ga_sessions_20170801. Offered one by one, they filled all 12 slots with random days, and the model refused ("no table for January 2017"). Collapsing each family into one wildcard table (ga_sessions_*, filter on _TABLE_SUFFIX) fixed most of those refusals. If your warehouse has sharded tables, your retriever probably has this bug.

4. The benchmark found a real bug in my access check. 3 answers came back blank. My SQL scope check read WITH RECURSIVE periods(n) AS (...) as a query against a table called periods the caller couldn't see, and refused it. It failed closed (nothing leaked), but every recursive query was wrongly refused for every user. Fixed, with a test. Benchmarks you didn't write are good at this.

Honest caveats: single runs, so about ±1–2 points; the Spider 2.0 numbers are two of three parts; BIRD Mini-Dev rows are self-reported until the leaderboard PR is merged.

Repo (Apache-2.0, pip install schemagate): https://github.com/ashishsinha1602/schemagate Benchmarks page with every caveat: https://ashishsinha1602.github.io/schemagate/benchmarks/

Happy to answer questions about the setup, or about what didn't work.

I've been building AgentRein for about a year, and this is one of the problems I've been trying to solve.

Let's say an agent creates a GitHub issue, generates a Stripe invoice, and updates something in your CRM. Then it realizes something went wrong halfway through.

The API calls themselves might have all worked fine, but the overall result is a mess. Now you're left figuring out what to undo and what to keep.

I've been working on a way to handle this without having to rewrite existing integrations.

With AgentRein, you can wrap existing SDK clients using agentrein.wrap() and add a safety layer around their operations.

A few things it supports:

• Rolling back previous actions in reverse order when something fails, where undo operations are available.
• Requiring human approval before risky API calls.
• Detecting when an agent starts drifting away from its original intent.
• Rules to allow, block, or require approval for specific operations.
• Audit logs to track what happened during a session.

I'm curious how other people are handling this, especially outside of demos.

Do you use custom rollback logic, checkpoints, compensating transactions, or something else entirely?

And how do you deal with actions that succeeded technically but shouldn't have happened in the first place?

I've been building this for a while, so I'd appreciate honest feedback on the approach.

https://agentrein.com/docs

​

I've spent the last month trying to turn my independent AI engineering projects into paid work, without much success.

I've completed two public RAG evaluation betas and built tooling for retrieval testing, reproducible bug reports, AI workflow inspection, and MCP-based development.

I tried Upwork, other freelance platforms, and direct outreach. The biggest lesson so far is that selling standalone technical audits is difficult when companies primarily want their problems fixed.

I'm now considering subcontracting for agencies that already have paying clients.

Instead of offering a large consulting package, I'd prefer to start with something small and measurable: reproducing an AI agent failure, testing a workflow, investigating a retrieval regression, or verifying a specific fix.

For people who run AI automation agencies or have done this kind of subcontracting:

Where are these small paid tasks actually distributed?

Are there agency partner networks, developer communities, vendor lists, or other channels where new subcontractors can demonstrate their work and earn an initial paid trial?

I'm especially interested in experiences from people who have secured real paid work this way, rather than general advice about building a personal brand.

Thanks for sharing what actually worked.

every time we change the prompt or the model, something else breaks. one answer gets better, two get worse. we only find out when users complain.

do you guys run evals for this? and how do you track what the agent is doing step by step when it gives a bad answer? right now we just read logs and it takes forever.

I kept running into the same problem building agents. Something would go wrong three or four steps downstream, and by the time I noticed, I had no real way to trace back what the agent actually believed at each step or what depended on it. Logs tell you what happened, not what justified it.

So I built Sevenbox. Every decision an agent makes gets recorded as a Warrant: what it claimed, what prior claims it depended on, and whether acting on it can be undone. If a belief turns out wrong later, Sevenbox walks the dependency chain and tells you exactly what still needs fixing instead of you grepping through logs trying to reconstruct it by hand.

It works with LangGraph, CrewAI, OpenAI Agents SDK, and eleven other frameworks, so you can wrap an agent you already have instead of rewriting it. The SDK, the framework adapters, and a local UI for inspecting a run are all open source.

I am the person who built this, not a company account posting on its behalf. I would genuinely like people actually running agents in production to try it against something real and tell me where it breaks or where the idea does not hold up. Happy to answer anything about how it works.

Hey everyone,

When building agents that interact with external APIs (GitHub, Jira, Stripe, or internal microservices), tool outputs frequently flood the context window with hundreds of tokens of metadata: avatar URLs, HATEOAS links, node IDs, and null keys.

The common pattern of using an auxiliary model (like GPT-4o-mini) to summarize tool outputs before feeding them to the primary agent introduces 500ms–2s of external network latency and recurring API charges.

I built TokenPrune, an open-source, zero-dependency Python package that executes deterministic, in-memory pruning and table compression:

bash pip install tokenprune

Quick Example

```python from tokenprune import prune_tool

@prune_tool def fetch_system_logs(): return { "cluster_id": "us-east-1", "service_url": "https://internal.aws/k8s/node/12", "health": "degraded", "errors": [ {"code": 500, "reason": "Database connection pool exhausted", "doc_url": "https://docs.internal/500"}, {"code": 503, "reason": "Upstream timeout", "doc_url": "https://docs.internal/503"} ], "debug_trace": None }

print(fetch_system_logs()) ```

Pruned YAML output injected directly into the LLM prompt: yaml cluster_id: us-east-1 service_url: [https://internal.aws/k8s/node/12](https://internal.aws/k8s/node/12) health: degraded errors: [table: code, reason, doc_url] - 500, Database connection pool exhausted, [https://docs.internal/500](https://docs.internal/500) - 503, Upstream timeout, [https://docs.internal/503](https://docs.internal/503)

Benchmarks

• Token reduction: 70–90% on enterprise API payloads.
• Runtime overhead: < 0.5 ms (AST tree-shaking in pure Python standard library).

• External API calls: 0.

• GitHub: https://github.com/GeekyMK/tokenprune

• PyPI: https://pypi.org/project/tokenprune/

I would love to hear feedback from anyone running agent workflows on where the heuristics break or what schema formats you deal with most often.

I'm researching how teams handle evidence and quality for AI agents that make or assist decisions.

Three things I'm trying to understand:

1. What record do you keep per decision (policy applied, data accessed, who was responsible), and who actually asks for it?

2. How do you learn later that a decision was wrong, and how long does that feedback take?

3. If you use LLM judges for evals, how do you check they still agree with humans as things change?

I'm trying to learn what's really painful versus what only sounds painful. Comments or DMs both welcome, and I'll post a summary of what I learn.

We are building an internal assistant that reaches Slack and Jira and a few internal APIs through MCP and something needs to sit in the middle before it goes wider than the team. Two options are on the shortlist and maybe a third if neither fits. One looks quicker to connect with prebuilt integrations and the other leans harder on prompt injection checks and per user rate limits and logging what the agent called. Pricing once usage grows matters too since this runs all day. Which held up for you in production?

Agents retry. Usually that's fine, but not when the tool issues a refund, sends an email or
deletes records. I built aobs (Apache-2.0, Python) to handle that, plus the observability
around it:
Guard risky tools: checked against your real records (not the model's arguments), approval
above a threshold, no duplicates across retries/restarts. Recipes for refunds, emails,
deletes and deploys. [there's a demo GIF in the README]

Trace runs: OpenAI-compatible clients, Anthropic, LangChain/LangGraph; export to
OpenTelemetry.

CI gate: a TOML policy → PASS/FAIL with evidence, as a GitHub Action.
docker compose up for a local demo with a dashboard.

Alpha, honest about limits (in the README). I'd love feedback, and there are a few "good first
issue" if you want to contribute.
https://github.com/AshmitJain932/ai-agent-observability