Senior LangChain Engineer – Debug Complex Production AI Agent

We have a production AI Agent built with LangChain (Python)​ that is live and handling real user queries. Recently, we’ve encountered a set of non-trivial runtime issues​ that only appear under realistic load and multi-step reasoning scenarios. This is not​ a “build an agent from scratch” job. I’m looking for an engineer who has shipped LangChain-based agents to production​ and can quickly diagnose and fix subtle issues that don’t show up in simple scripts or playgrounds. The Scenario (Please Read Carefully) Our agent runs as an async FastAPI service and performs multi-step reasoning using AgentExecutor with a ConversationBufferMemory. The agent has access to several tools (APIs + vector search). Under normal conditions, it works well. However, under the following conditions, we see inconsistent behavior: When the agent executes more than 3 sequential tool calls​ in a single turn And the intermediate tool outputs contain large JSON payloads And the user message triggers both retrieval-augmented context + tool selection We observe: Memory truncation issues:​ The ConversationBufferMemory occasionally drops earlier messages or tool outputs, even though max_token_limit is set. The agent then “forgets” critical context mid-chain. Malformed LLM responses:​ The LLM sometimes emits tool call JSON that is valid JSON but semantically incorrect​ (e.g., hallucinated tool names or mismatched arguments). LangChain does not reliably catch these, leading to silent failures or misleading final answers. Async + runnable concurrency bugs:​ When multiple RunnableSequence steps execute concurrently, we occasionally see: Cross-contaminated memory across requests Race conditions in tool execution order Unexpected AttributeError or ValidationError deep in LangChain internals Error handling gaps:​ Failures in one tool are not surfaced properly to the agent loop, causing it to continue with stale or missing data instead of retrying or aborting gracefully. What I Need From You I’m looking for someone who can: Reproduce and isolate the issue in a minimal, async LangChain setup Explain why​ this happens (not just “it works now”) Propose and implement a robust fix, which may involve: Custom memory classes Safer tool output parsing and validation Proper async Runnable patterns Defensive prompting or output schemas Ensure the solution is production-safe​ (no hacks, no monkey-patching LangChain internals unless justified) How to Stand Out in Your Proposal To filter for real experience, please do not send a generic pitch. Instead, briefly answer one or more​ of the following in your proposal: In LangChain, what is the practical difference between ConversationBufferMemory and ConversationSummaryMemory in high-tool-call scenarios, and why might the former silently drop messages? Have you ever implemented a custom BaseMemory class​ to solve token overflow or context contamination? What was your approach? How would you make AgentExecutor fail fast and safely​ when the LLM returns a tool call with an invalid tool name? What are the common async pitfalls​ when using RunnableSequence or RunnableParallel inside a FastAPI app? If you’ve only used LangChain in notebooks or for simple chatbots, this job is likely not a good fit—and that’s okay. Requirements Strong Python (asyncio, pydantic, FastAPI) Deep, hands-on LangChain experience in production Familiarity with: LangChain Expression Language (LCEL) AgentExecutor internals Tool calling & output parsing Comfortable debugging issues that span LLM behavior + Python runtime Nice to Have Experience with LangSmith for tracing Experience with OpenAI function calling / tool calling APIs Familiarity with vector DBs (e.g., Pinecone, Weaviate, pgvector) Logistics Remote / Async Short-term engagement with potential for ongoing work Access to a minimal repro repo will be provided If this sounds like a match, start your proposal with: “LangChain in production: I’ve seen this before.” Looking forward to hearing from you.