I have been using langchain since it has been released. We have bunch of adapters {ChatBedrock, ChatGoogleGenerativeAI..} to integrate an LLM for langchain powered AI app development.
However, some firms are using a relay path to call an LLM for instance : AWS Bedrock invoke via lambda to control the AI usage, governance, enforcing company specific guardrails. Therefore, LLM integrations are becoming so tough, sometimes not possible to use DeepAgents or other sdk’s because of adapter params.
ChatBedrock needs boto3 BedrockRuntimeClient and other aws args. It would be great to design this in such a way that we can use lambda client or any other relay clients to form a communication bridge between Langchain and LLM providers.
Thanks for raising this — the constraint makes sense. A lot of enterprise deployments route model calls through internal relays like Lambdas, gateways, or policy-enforcing services for governance, auditability, usage controls, and custom guardrails.
That said, we generally view LangChain’s model interface extensibility as a feature here rather than a bug. You don’t need every possible relay pattern to be built into the provider-specific integrations directly: anyone can subclass BaseChatModel and adapt their organization’s internal model gateway, Lambda relay, or custom transport into the standard LangChain chat model interface.
We also provide standard integration tests for chat models, which are intended to make this kind of custom implementation easier to validate and keep compatible with the broader LangChain ecosystem.
For provider packages like ChatBedrock, we try to keep the built-in adapters focused on the standard/provider-native usage paths. Adding first-class support for many organization-specific relay architectures can add a lot of surface area and maintenance complexity.
That said, this is helpful feedback. If we see more demand for common relay/client patterns — e.g. Bedrock via Lambda or enterprise model gateways — we may be more open to supporting this more directly in the future. In the meantime, implementing a small BaseChatModel subclass around your relay is likely the best path.