LangChain Development for Systems That Reach Production

Almost always retrieval, not the prompt. If the right passage never reaches the model, no amount of prompt engineering saves the answer. We measure retrieval quality separately from answer quality first — usually the fix is chunking, hybrid search or reranking, and sometimes it's that the source documents genuinely don't contain the answer.

For a single prompt with no retrieval or tools, a direct API call is simpler and we'll tell you to do that. LangChain earns its place when you have retrieval, multiple steps, tool calls or agent state to manage. Using a framework you don't need is its own cost.

Scope tool permissions to the minimum the task needs, keep high-stakes actions behind an explicit human approval step, and put hard limits on iterations and spend. An agent with write access to a production system and no checkpoint is a design mistake, not a tuning problem.

It depends on volume, context size and model choice, and it varies more than people expect — the same feature can differ by an order of magnitude depending on how much context you send per call. We model expected cost per query during the build and use caching, context trimming and model routing to control it, rather than discovering the number on the first invoice.

The pipeline and vector store can. The model is the deciding factor: open-weight models can run entirely in your environment, while frontier hosted models cannot. If data residency is a hard requirement, that constraint shapes the architecture and we'd settle it before anything else.

Usually: an evaluation set so changes can be measured, retrieval tuning against real questions rather than sample ones, failure behaviour for when the system doesn't know, cost and latency control, and tracing. That's typically the larger half of the project, which is why prototypes are quick and production systems aren't.