Guide

OpenClaw + LangChain: Keep the Chain in Code, Reach It from Chat

Q: Does OpenClaw replace LangChain?

No. LangChain is a library for composing logic in your own code; OpenClaw is a hosted agent runtime with channels and skills. A LangServe-deployed runnable can be called by the agent as a tool.

Q: What exactly do I connect?

You connect a LangServe deployment of the runnable. The connector calls its /invoke route, and the /docs route confirms the expected input schema.

Q: Where do the API keys live?

Provider API keys stay in the LangServe deployment. The instance holds only a scoped token for that endpoint, not the underlying model credentials.

If your retrieval and tool logic already lives in a repository, you do not need to redraw it in a visual builder. Deploy the runnable with LangServe and let the agent call it — code review on one side, channels on the other.

The layering that works

LangChain is a library. It has no channels, no pairing flow, no approval policy, and no place to put a Telegram bot token — and it does not need any of those, because that is not its job. OpenClaw and Hermes supply exactly that layer. The clean division is: your runnable answers a well-defined question, the agent decides when to ask it and who is allowed to.

The version-control argument matters more than it sounds. A chain in a repository gets diffs, review, and a rollback. A chain drawn in a UI gets whatever the last person clicked.

1. Deploy the runnable with LangServe

Follow the LangServe documentation to serve the runnable you want to expose, pin your dependencies, and put it behind an authenticated TLS reverse proxy. Expose one runnable per capability rather than one endpoint that branches internally on a free-text instruction — narrow contracts are what make the agent's calls predictable.

# LangServe publishes interactive docs describing the input schema
curl -fsS https://langserve.example.com/docs

2. Connect it from Dashboard Tools

Open Dashboard Tools, select a running instance, and connect the LangChain card. The placeholder endpoint is https://langserve.example.com; add the scoped token your proxy expects. The connector installs a small HTTP client and a managed skill so the agent knows the endpoint and the call shape. The client lives at a managed path — tools/dashboard-api-connectors/langchain/tool — and the examples below use tool as shorthand for it.

# Read the schema before calling
tool get /docs

# Invoke the runnable
tool post /invoke '{"input":{"question":"What changed in the release notes?"}}'

Reading /docs first is not ceremony. LangServe derives the input schema from the runnable, so it is the authoritative description of what the endpoint accepts — better than any prompt-embedded description that can drift out of date.

3. Design the contract for an agent caller

Take typed, validated input. An agent will send you something surprising eventually; fail cleanly rather than half-succeeding.
Return structured output with a small, stable shape. Free-form prose forces the agent to re-parse your answer with a model.
Include citations or source identifiers if the chain retrieves. Grounding that the agent can pass through is worth far more than a fluent summary.
Return explicit errors. Silence invites the agent to invent an answer.

4. Respect the connector's limits

Printed responses are capped at 5 MB and the client sets a 120-second socket timeout — a bound on a stalled connection, not on total runtime, so enforce your own request deadline server-side. If a chain legitimately runs longer, return a job identifier immediately and let the agent poll — do not hold the conversation open. For large results, return a reference and write the payload somewhere the agent can fetch on demand.

Production hardening

Authenticate the endpoint and scope the token per instance; provider keys stay server-side.
Rate-limit and set per-request cost ceilings — a messaging channel is a much noisier caller than a batch job.
Log inputs and outputs on your side for debugging, with the same care you would apply to any user data.
Pin dependency versions. A silent library upgrade can change chain behaviour without changing your code.

When MCP is the better shape

If you want the agent to discover several related tools rather than call one fixed endpoint, an MCP server is the more natural fit — see the OpenClaw MCP guide. Use LangServe when there is one capability with one contract, and MCP when you are publishing a toolbox. For a visual alternative to code, see Langflow.

Frequently asked questions

Does OpenClaw replace LangChain?

No. They sit at different layers. LangChain is a library for composing model calls, retrieval, and tools inside your own code; OpenClaw is a hosted agent runtime with channels, approvals, and skills. Deploying a runnable and calling it from the agent keeps each doing what it is good at.

What exactly do I connect?

A LangServe deployment for the runnable you want to expose. The connector points at the LangServe base URL and calls its /invoke route; the interactive docs route is useful for confirming the input schema first.

Where do the API keys live?

In the LangServe deployment, not in the instance. That is one of the better reasons to do it this way: your provider keys stay in your own service and the agent only ever holds a scoped token for that endpoint.