r/LangChain

Hi everyone,

I work at a large telecom company in the US. When we win a tender, the client sends us a requirements specification, and we write technical deliverables based on it and on our internal technical documentation (100k+ documents). A single tender can involve thousands of deliverables, some of them up to ~600 pages long.

Goal: before delivery, automatically verify each deliverable. That means checking that the facts it contains are accurate against our technical documentation, and detecting anomalies (errors, internal contradictions, inconsistencies between deliverables, duplicates).

Current plan:

1. Fact extraction: process each deliverable in chunks with an LLM and extract atomic facts, with their source location.

2. Classification: group the facts into families (measurements, architecture, calculations, frequencies, standards, quantities).

3. Verification: check each fact against the documentation base using RAG.

4. Anomaly detection: one LLM call per fact category to detect duplicates, contradictions, etc.

My questions:

- Is there a recommended approach for extracting precise facts from very long documents? How do you handle context that spans chunks ?

- How do you make sure extraction is complete (no missed facts) and doesn't produce hallucinated facts?

- For anomaly detection, does one LLM call per category scale when a category can contain thousands of facts? Would you normalize facts into a structured schema (entity / attribute / value / unit) and do part of the comparison deterministically in code rather than with an LLM?

- For RAG verification on highly technical content (part numbers, frequencies, references to standards), did hybrid search (BM25 + embeddings) or reranking make a big difference for you?

- Any experience comparing long-context models (1M tokens) with chunked extraction for this kind of task?

Any feedback, papers, tools or lessons learned would be much appreciated. Happy to share what we learn along the way.

Thanks

A checkpoint can preserve graph state, but generated files have a different lifecycle. Reports, HTML bundles, images, and spreadsheets may be too large for messages, may change independently, and may need a stable review link after the run that created them has ended. Storing only a temporary path or signed URL makes a later resume fragile. Storing the bytes inside graph state makes checkpoints heavy and blurs workflow state with durable output.

One approach is immutable artifact revisions in object storage plus a small manifest in authoritative state. The manifest would carry an artifact ID, revision, checksum, media type, source revisions, producer node, review status, and a stable resolver. Graph state would reference the manifest revision, while messages receive only the summary needed for reasoning. A resumed node would reject a stale expected revision rather than overwrite newer work.

How are LangChain and LangGraph users drawing this boundary? What belongs in messages, checkpoints, the Store, or external object storage, and how do you keep cleanup, permissions, and retries consistent across those layers?

If you follow the agent threads here, you have watched the "do agents need memory or just documentation" argument go in circles. Most of that, we think, is that "memory" covers three separate problems, and each camp is defending a different one.

First is keeping state inside one session. In LangGraph that is the checkpointer, keyed by a thread_id, and it lets a run pause and resume with state intact. The edge that catches people: when a node hits an interrupt and you resume, the whole node runs again from the top. Any tool call or write before the interrupt fires again on every resume, which is why the docs insist anything before an interrupt be idempotent.

Second is remembering across sessions. That is the Store, separate from the checkpointer, namespaced per user, searchable later. It is the piece the "you need a memory layer" people mean, and where the cost hides: as it grows, a naive setup spends tokens reading and refreshing it even on tasks that never needed it, and a fact true three months ago still sits there with nothing marking it stale.

Third is what fits in the context window each call. LangGraph treats this as context management, separate from the two memory types above, though the argument lumps it in. Trim or summarize old turns too hard and the agent re-asks for a detail the user gave two turns back, because the summary dropped it.

Split those three and the argument reads differently. The documentation camp is mostly on the third problem and part of the second. The memory-layer camp is almost always on the second. Same word, three problems, which is why it keeps circling.

So which of the three has you stuck? On the cross-session one, the contested piece, what breaks first: store bloat that makes simple tasks pay for memory they never needed, or stale entries with no clean way to retire them? We're curious what people have landed on.

Hey,

I wanted a faster chunking library for my system without affecting the overall accuracy. Did not find many options. So I've build https://github.com/d1pankarmedhi/chunkr

It has most of the chunking strategies like Character, Recursive, Markdown header, Late chunking, Hierarchical chunking, etc. It also supports native PDF loader, and other additional file types.

Some stats (MBA M4 16GB):

Do check it out and share your feedback. Thanks!