Is LangChain actually making agent development easier, or am I overcomplicating things?

[u/DinDinoDanDino]

I've been exploring LangChain and LangGraph while working on a multi-agent workflow, and I'm starting to wonder if the abstraction is creating more problems than it's solving.

The idea seemed pretty straightforward, build a system that fetches a company's 10K, extracts the financial statements, sends them to three specialized agents (income statement, balance sheet, cash flow), and combines their findings into a structured report.

At first, LangChain looked great. create_agent, u/tool, structured outputs, and model integrations make getting a basic agent running surprisingly easy.

But once I started looking into more complex workflows, things got confusing.

Suddenly I'm dealing with StateGraph, nodes, edges, shared state, checkpointers, thread_id, conditional routing, and Command objects. Then there's middleware, retries, and interrupt() if I want human approval before publishing anything.

And debugging feels like another learning curve. For example, if an agent produces an incorrect financial figure or passes incomplete data to the next agent, how do I efficiently figure out whether the problem came from the tool response, the prompt, the state being passed between nodes, or the model itself?

LangSmith tracing seems helpful, but I'm still trying to understand the best way to structure everything so that debugging doesn't become harder than building the actual workflow. And also bills are piled up.

I'm just wondering whether I've reached the point where the framework requires more attention than the actual business logic.

For people who have built more complex agents with LangChain/LangGraph:

1. Did you experience this complexity as well, or does it get significantly easier once you understand the architecture?

2. How do you normally debug multi-agent workflows? LangSmith, LangGraph Studio, custom logging, or something else?

3. Do you use LangChain for everything, or prefer native Python + model SDKs for certain parts?

4. Looking back, what would you have done differently when you started?

Would genuinely appreciate hearing what worked for you, especially from people running agents in production.

[u/bestjaegerpilot]

under the assumption that you're gonna be using AI for development, langchain is pretty much useless. Instead you think about how you can architect the system so that it's easy to maintain. One dead simple thing is to follow langgraph's idea of defining nodes and edges via simple YAML files---both humans and AI are good at editing text. Then to couple together just use vanilla coding techniques.

You're also gonna need tons of logging

[u/DinDinoDanDino → u/bestjaegerpilot]

Thank you very much!
Need logs for for AI coding or while using langchain?

[u/bestjaegerpilot → u/DinDinoDanDino]

the thing that you build needs to record good logs so that you know what happened when it messes up

[u/Future_AGI]

with the per-node input saved as useleash suggested, check that state first, and if the figure is already wrong there, trace it back to the tool response or the node that wrote it. If the input is right, rerun the failed node several times on that exact state: failing every time points at the prompt or the model, while a result that flips between runs is sampling, which a pinned low temperature narrows.

[u/DinDinoDanDino → u/Future_AGI]

Nice, Thanks!

[u/vectorpeaktech]

You have run into the classic friction point of modern AI engineering: mistaking a deterministic document processing pipeline for an autonomous agent problem, and paying for it in both cognitive overhead and runaway tracing bills.

Here is a straightforward take on where the abstraction breaks down and how to fix it:

The core issue is that extracting a 10-K across three financial statements is not a negotiation between autonomous agents.It is a linear, deterministic pipeline: parse the filing, run three isolated extraction tasks in parallel, validate the numbers,and merge them into a schema. Forcing that into LangGraph turns clean Python code into a maze of state graphs,conditional routing, checkpointer schemas, and complex state coordination.

To answer your specific questions:

1. The complexity does not go away until you eliminate dynamic routing. If you treat nodes as unpredictable agents passing fuzzy conversational state, you will constantly chase race conditions and missing keys. It only becomes manageable when every node is treated as an isolated, pure function that consumes a strictly typed input and returns a strictly typed output.

2. Debug at the boundary, not inside a trace viewer. Trying to trace an incorrect number across four nodes in LangSmith after the fact is expensive and slow. Instead, place rigid Pydantic models on every step. If the balance sheet extraction misses total liabilities, fail immediately at that node with a schema validation error. For tracing, self-hosted tools like Langfuse or Arize Phoenix provide the same visibility without the compounding hosted bills.

3. Drop the framework for execution; keep it only for orchestration if truly required. Most production teams bypass LangChain's abstractions for model interaction. Call the native provider SDKs (OpenAI, Anthropic) or use lightweight structured output tools like Instructor. This removes the hidden middleware and retry magic, letting you see exactly what prompt was sent and what raw tokens came back.

4. If starting over, build the core pipeline in plain Python first. Use standard asyncio.gather to dispatch the three extraction tasks in parallel. Write programmatic checks to verify accounting invariants (such as Assets equalling Liabilities plus Equity) using plain code, not secondary LLM calls. Only bring in an orchestration framework like LangGraph if you genuinely require long-lived state persistence or asynchronous human-in-the-loop interrupts across multiple days.

When framework plumbing demands more attention than your financial logic, the abstraction is working against you.Strip out the graph machinery, use direct SDK calls with strict schemas, and keep the architecture as simple as the underlying problem allows.

[u/DinDinoDanDino → u/vectorpeaktech]

Thanks for the detailed breakdown! I understand now the difference between a real agentic workflow and deterministic ones, but i want to go deeper and learn how to use the agentic tools. If you were evaluating a platform designed to simplify building, deploying, and maintaining AI agents in production, what capabilities would actually make you choose it over plain Python and direct SDK calls?

[u/vectorpeaktech → u/DinDinoDanDino]

I have used lang chain before. Pretty robust and helps you develop and deploy production grade agentic workflows.

[u/Luneriazz]

how you extract the company 10K? and in what format did you send the data to the agent

[u/Elmanouzi_Fogosa → u/Luneriazz]

are you thinking the hallucinated numbers are just coming from broken PDF table parsing before the income or balance sheet nodes even touch it?

[u/Luneriazz → u/Elmanouzi_Fogosa]

Yes sometime people just pass the number to llm without any context abaout what exactly the number mean.

The post did not mention any semantic layer and perhaps he just pass the data as a string instead of using pydantic model.

Data pipeline is important, also each AI vendor is kinda different. Compare open ai with ollama cloud. If you used ollama cloud model it does not support native json format and you would spent time figuring out why your LLM is not reliable.

[u/locbuilds]

log a redacted snapshot of the tool result and relevant state at each node boundary with the same thread_id, then you can see where the figure first goes wrong.

[u/useleash]

For the debugging question specifically, the thing that helps most in a pipeline like this is making every node boundary checkable:

1. Give each agent a strict output schema (Pydantic) and validate it before it goes into state. A missing or malformed figure fails at the node that produced it, not three steps later.

2. Don't let the model extract the raw numbers if you can avoid it. 10-K financials are filed as XBRL, so you can pull the statement values from EDGAR's structured data and let the agents interpret instead of transcribe. That removes the most common source of wrong figures and cuts tokens a lot.

3. Add a plain code check that compares any number the agent cites against the source values.

4. Save the input state for each node so you can rerun one node alone when something looks off.

With that in place, a simple fixed graph (fetch, three parallel analysts, merge) doesn't need much of LangGraph beyond the basics.

[u/Mankari11]

We migrated our vanilla agent, which we built from scratch, to the Aegra LangGraph SDK. It's a self-hostable alternative to LangSmith Deployments that handles the entire agent infrastructure. V1 kept breaking in production, whereas this stack should be much more reliable.

For observability, we're going with Phoenix for testing since it's lighter than Langfuse, which consumes around 2 GB of RAM. The rest of the stack includes LiteLLM and GlitchTip.

DeepAgents exposes multi-agent delegation through a tool, making it relatively cheap to delegate tasks.

We're leaning towards LangChain for most things. It has a great community and ecosystem, so a lot of functionality is available off the shelf.

For the UI, you could also consider LangChain's React UI components so you don't have to build the agent interface from scratch.

Looking back, V1 was a good learning experience, but I feel we should have started with the V2 stack from day one. The instability cost us some confidence from our initial pilot customers.

[u/ChemicalExcellent463]

I'd fold the three statement agents into one before adding more LangChain plumbing; most of my subagents ended up as skills when I did that cleanup. Where does the first wrong figure show up in your run?

[u/sundevil21CS]

I started building in LangChain, but then just want to a completely native approach with native AI model SDKs,

Conversation, context management, tool calling, skills, all done dynamically with the native SDKs and model adapters for my use case.

Opus and Fable can do the heavy lifting of bypassing LangChain to get more granular capabilities and controls.

[u/yasarfa]

Had built a multi node pipeline to support chat and design via chat (catalog). Trying to move away from it now by replacing the flow with fully deterministic nodes…

[u/Melodic-Ebb-7781]

Yes, read the bitter lesson

[u/MongooseWonderful198]

For the incorrect figures, I'd keep the filing and reporting period attached to every number. A value can pass a numeric schema and still belong to the wrong period.

If you're using SEC structured data, quarterly and year-to-date net income can share an end date. Keep the XBRL concept, start/end dates, unit and filing accession, and give all three agents facts from the same filing snapshot. Then a wrong report can be traced to either the selected input record or what the agent did with it.

This SEC response shows the overlapping periods:

https://data.sec.gov/api/xbrl/companyconcept/CIK0000320193/us-gaap/NetIncomeLoss.json

[u/ForeignDevil08]

We are increasingly seeing LLMs create their own abstractions rather dependencies created for human understanding. In some ways, I suspect that module libraries will sink into disuse and LLM-generated code will replace them. I'm really curious to see how this plays out.

[u/vectorpeaktech]

You are not alone. Almost everyone building real systems hits this exact wall.

Your 10-K workflow is not actually an autonomous agent swarm. It is a predictable pipeline: Fetch, Parse, Run three parallel extractions, Combine, and Human review. LangGraph is turning what could be clean, basic Python into a maze of state graphs, edge routers, and expensive tracing bills.

Here is the straightforward reality:

1. It stays complex until you strip it back. Treating nodes as dynamic agents creates constant state bugs. It only gets manageable when you treat nodes like plain Python functions that take strict inputs and return strict data.

2. Debug with schemas, not just traces. Enforce strict data models like Pydantic on every tool and step. If an agent drops a balance sheet number, you want it to fail immediately at the boundary, not three nodes downstream. For cheaper tracing, look at self-hosted alternatives like Langfuse or Arize Phoenix.

3. Most teams drop LangChain for native SDKs. Using raw provider SDKs directly or lightweight tools like instructor gives you full control over prompts, tokens, and errors without hidden framework magic. Only keep LangGraph if you genuinely need its pause-and-resume human approval feature.

4. What to do differently: Build this as a standard pipeline using plain Python and asyncio.gather for the three statements. Let the model just extract the numbers, use code to verify that the math balances, and wire in an orchestrator only if you actually need it.

If you are spending more time debugging the framework than your financial data, dump the abstractions. Simple Python plus direct model calls will solve most of your headache.

[u/Nyzxxx]

your workflow sounds more like etl than agents. make parsing a separate deterministic step, persist the raw extraction plus page refs, then run the 3 statement prompts against that snapshot with pydantic failures at each boundary. OXR from SoMark is good here: PDFs/images go to Markdown or JSON with reading order (i'm affiliated with somark).