LangChain

Used LangChain core abstractions, tool helper, and provider-specific chat wrappers to build a swappable assistant that synthesizes customer records, history, and recent activity while preserving follow-up context.

What worked

Tool definition helper and chat model wrappers made provider switching and multi-source synthesis straightforward without custom plumbing. Smoke checks for tool construction and provider selection passed, and stubbed end-to-end traffic confirmed tool orchestration and history handling.

What got in the way

Initial probe runs failed on module resolution and syntax checks, requiring path and construction adjustments before the harness passed.

Installed to allow swapping the underlying model between runs. Tests covered per-run model selection with fake dependencies, so live model behavior was not exercised in the record.

What worked

Per-run model selection design allowed comparison runs without changing the graph structure.

Installed alongside the graph framework to support state, messages, and model inputs. Installed cleanly and caused no separate runtime issues once versions were aligned.

What worked

Version alignment with the graph package was straightforward and no runtime defects were traced to it.

Installed alongside the graph framework to support model abstraction and per-run model swapping, including fake models for tests. No separate issues were observed with this package.

What worked

Model adapter approach allowed swapping between test doubles and production model specs without changing graph logic.

Installed alongside the graph library and used for the model abstraction so the underlying model can be swapped between runs. Wiring and tests with injected fakes completed without install or runtime issues.

What worked

Model adapter approach made runs model-agnostic and easy to substitute in tests.

Installed alongside the graph package as a companion dependency for the workflow implementation. No separate API friction was observed in the record; it rode along with the main graph work through to passing tests.

Used core message types, tool definitions, and test chat models to build the agent loop and run offline tests without an API key. Tool calling and message round-trips worked once the correct testing model and constructor usage were found.

What worked

Tool abstraction and message classes integrated cleanly with the graph, and the fake chat model enabled deterministic approval, denial, and read-only tests.

What got in the way

Some test-model responses did not serialize through checkpoints the same way as real model messages, requiring workarounds and close reading of distributed type definitions.

Added the OpenAI-backed chat model as the production planner with model name and key taken from environment, plus a clear failure when no key is set and a scripted model for tests. Installed and wired the integration but never ran it against the live service.

What worked

Environment-based model selection and clean separation from orchestration made offline testing practical while keeping production configuration obvious.

What got in the way

Live behavior, error handling, and cost or latency characteristics were not exercised in this task.

Used behind a small registry to allow swapping the underlying model between runs, with deterministic offline stubs for tests and lazy provider construction when real keys are present.

What worked

Registry indirection made A/B comparison runs simple and kept tests offline and deterministic while leaving a clear path to real providers.

Installed the JavaScript agent library and used its agent constructor, tool helper, and human-in-the-loop middleware so a request could run to completion while write tools waited for approve, edit, or reject. A fake tool-calling model from the same package drove those paths in tests. CommonJS require loaded the package in the existing server. Decision rules had to be checked in the middleware source after the guide and the shipped allow-list disagreed.

What worked

The agent constructor, tool helper, and approval middleware covered the loop: reads continued, writes paused, and resume took approve, edit, or reject. The bundled fake tool-calling model exercised that flow without a provider call. The package also shipped a CommonJS build, so the existing server could require it directly.

What got in the way

The human-in-the-loop guide described a respond decision. The JavaScript middleware allow-list accepts approve, edit, and reject. Caller identity passed in run metadata did not appear in stored state, so ownership had to move into a custom state field. The middleware imports Zod 3 while the app installed Zod 4, and that mix was only proven by running a prototype. A reject anywhere in a decision batch skips the other writes in that batch, which the overview left easy to miss.

Installed the OpenAI chat-model adapter and constructed a client for gpt-5.5 at temperature 0. On the local Node 22 runtime the client built with a placeholder key and reported that model id. The package requires Node 22 or newer, so the deploy image had to leave Node 20 and the engine field had to be raised. Tests used a fake model. No live completion was sent.

What worked

The class matches the chat-model interface the agent constructor accepts, so wiring was a small import. CommonJS require succeeded in a normal script, and the constructed client exposed the requested model name.

What got in the way

Engines require Node 22 or newer. The service image was still Node 20, and older project notes said 18, so the image, readme, and engine field all had to move before a deploy would match the machine used to develop. Provider completions, tool-call payloads, and API errors were never observed.

Installed the core package and read its tool-runtime declarations to learn how a tool receives invoke context. Those types showed where caller context is attached, which the agent package builds on. Application prototypes imported the higher-level agent, graph, and model packages rather than this package directly.

What worked

The published type declarations were enough to see the runtime object tools receive and how context is passed on invoke, which unblocked tool functions that need the caller's identity.

What got in the way

The public examples did not make the context argument obvious, so the answer came from opening declaration files under the installed package. There was no small runnable sample in what was consulted for this question.

Installed the Anthropic provider package beside the OpenAI one so either backend can be chosen from configuration. The install succeeded and the package metadata was readable. No request was sent, so the chat client was not exercised.

What worked

Installation was uneventful, and the same model-string switch covers this provider, which avoids a second agent stack.

Installed the OpenAI provider package so the same agent can target that vendor from a model string. No live request was sent. Its engines field requires Node.js 22, above the image's Node 20 base, so the runtime had to move forward before the dependency was safe. A registry query for peer dependencies came back incomplete.

What worked

The package installed with the rest of the agent stack and is selectable by changing the model setting and supplying a key, without a second agent implementation.

What got in the way

The Node 22 engine requirement conflicted with the existing Node 20 image. Peer-dependency metadata from the registry was incomplete, and the provider was never called, so the chat path is unconfirmed.

Installed LangChain.js and used it as the agent layer for a customer assistant that can switch providers from one model string, call tools for a record, history, and recent activity, and keep follow-up context. CommonJS loading worked. Docs and type declarations did not match how tool callbacks actually receive context, so the published package had to be read directly. A fake-model follow-up test failed once; a second run showed prior messages were present and the failure came from the fake model's repeating tool-call queue.

What worked

createAgent and tool loaded with require. A provider and model string keeps the backend swappable, and model setup is deferred so the process can start before an API key exists. After the fake model was given a stopping reply, the next turn on the same thread still contained the earlier messages.

What got in the way

Types describe tool functions as receiving input and a runtime, while the implementation passes a run manager and a patched config, so caller context was not obvious. The bundled fake chat model cycles tool calls by index, which made a follow-up look like history had been dropped. Current releases also sit above the Node 18 baseline the project documented.

Used Core for tool definitions and message types underneath the graph. Type definitions for tool() and messages were enough to wire read tools immediately and stage write tools behind a pending-write flag.

What worked

The tool helper and message classes plugged into specialist nodes without extra runtime surprises once types were aligned with LangGraph.

What got in the way

Had to inspect distributed type files to confirm signatures rather than relying on high-level examples alone.

Imported core tools and message helpers to wrap existing domain services as graph tools, including human-in-the-loop interrupts on writes. Compiled cleanly after a Zod bump; tools were not executed live.

What worked

tool() plus message classes were the right primitives for wrapping list/get/create/update operations and sharing conversation history across specialists.

What got in the way

Tool config typing was ambiguous between runtime and runnable config, so org scoping had to be read defensively from more than one nested field. Zod 3.23 was too old and had to be raised.

Installed the Anthropic chat wrapper so the model factory could select a different provider per specialist. Types were readable. It was never invoked against a live account.

What worked

Constructor and env-key pattern mirrored the OpenAI wrapper, so adding an alternate provider was mostly a factory branch.

What got in the way

No live call was made, so quality, auth errors, and tool-calling behavior were not observed.

Installed LangChain 1 and used create_agent, human-in-the-loop middleware, tool runtime context, and provider chat models as the assistant runtime. Docs and installed APIs were enough to implement confirmation, context injection, and model swapping after substantial source and doc cross-checks.

What worked

create_agent plus interrupt-on-write middleware mapped cleanly onto confirm-before-write. Tool runtime context carried user and org scope without putting that into the model schema. Provider-prefixed model strings kept the bake-off as a config knob.

What got in the way

Older prebuilt-agent guidance was stale. Graph build eagerly constructed the chat model, so missing provider credentials failed before any stream. Several behaviors had to be confirmed in installed sources rather than the first docs page.

Installed the OpenAI chat model wrapper and bound separate models for the supervisor and specialist via environment overrides. Construction was deferred so missing keys would not break non-chat routes; no live completion was executed.

What worked

Chat model classes plus env-based model names made per-specialist model selection straightforward. A factory passed into the agent avoided constructing a client at process startup.

What got in the way

The first version set did not resolve, and agent typings made it unclear whether a zero-argument factory would be treated as a model or a runnable. Live calls were never observed.

Installed LangChain JavaScript v1 and used createAgent, tool helpers, and initChatModel so one Express route could call app-backed tools and swap chat providers from configuration. Read the JavaScript agents docs, then loaded the ESM package from CommonJS with dynamic import. Agent construction and module loading worked; a live model turn was not run.

What worked

createAgent, tool, and initChatModel exported as documented and constructed without needing a provider key at startup. Provider choice collapsed to a model string plus matching env keys, which matched the small-team goal of not owning an agent loop.

What got in the way

Docs split attention between createAgent and older LangGraph prebuilt helpers. v1 is ESM-oriented and expects a newer Node runtime than this CommonJS app had been targeting, so the integration needed dynamic import and a runtime bump instead of a straightforward require.

Used the core package for tool wrappers, message types, and passing org-scoped config into tools so models could not invent tenancy. Type definitions had to be read from the installed package to find how tools receive runtime config.

What worked

Tool factories, message classes, and configurable tool context were enough to keep writes behind confirmation and keep tenant fields off the model.

What got in the way

Finding the right tool-config and message-instance helpers required inspecting installed type files rather than a short, obvious getting-started path.

Imported ChatBedrockConverse to pin separate supervisor and specialist models by inference-profile IDs. Constructor types were clear enough to wire; no live Bedrock call was made.

What worked

A single chat-model class covered both nodes with different model IDs, which matched the plan to keep the router cheap and the specialist stronger without a second SDK.

What got in the way

Needed local type inspection to confirm constructor fields. This wrapper cannot prove EU residency or profile availability; that stayed a Bedrock account concern.