What's the overhead of the bridge?

~80 microseconds per call (PyO3 boundary crossing twice — wrap and unwrap). Negligible vs LLM call latency.

Do streaming tools work?

Yes — generator-returning LangChain tools stream through the bridge. We yield each chunk as a Tool yield, the LLM sees them as observation increments.

What about async LangChain tools?

Native — agentmatic runs an asyncio compatibility layer over the Tokio runtime. ArunnableLambda and async BaseTool both work.

Should I rewrite my LangChain tools as native Agentmatic tools?

Usually no. The bridge is fast enough. Rewrite only if (a) the tool is hot-path performance-critical, or (b) you want it to be language-agnostic (rewrite as MCP server instead).

Tutorial

LangChain tools in a Rust-engined agent: the zero-friction bridge

How from_langchain_tools() actually works, why bringing your existing LangChain toolbox costs zero engineering time, and the cases where you should rewrite a tool natively anyway.

Dipankar Sarkar May 28, 2026 6 min read

langchaintoolsmigrationintegration

The single biggest blocker to migrating off LangChain is “I have 50 tools written as LangChain BaseTools.” So we made it so you don’t have to rewrite them.

from agentmatic.integrations.langchain import from_langchain_tools
from langchain_community.tools import (
    WikipediaQueryRun, DuckDuckGoSearchRun, PythonREPLTool,
)

tools = from_langchain_tools([
    WikipediaQueryRun(),
    DuckDuckGoSearchRun(),
    PythonREPLTool(),
])

agent = create_react_agent(llm=OpenAI(), tools=tools)

That’s the whole pattern. Let me explain what actually happens.

What from_langchain_tools does

For each BaseTool in the input list:

Inspect the tool’s args_schema (Pydantic). Convert to Agentmatic’s internal tool schema.
Build a wrapper Tool that, when called, invokes the LangChain tool’s .run() (or .arun() for async).
Forward the return value back into the Agentmatic execution loop.

The wrapper is ~30 lines of Python. The boundary cost is ~80 μs per call (one PyO3 crossing into the agent, one out). Compared to a typical LLM call (200–2000 ms), this is invisible.

Async support

Async LangChain tools work without modification:

from langchain.tools import StructuredTool
from langchain_core.runnables import Runnable

async def my_async_tool(query: str) -> str:
    return await some_async_call(query)

tool = StructuredTool.from_function(coroutine=my_async_tool)
agent = create_react_agent(llm=OpenAI(), tools=from_langchain_tools([tool]))

We run an asyncio compatibility layer over the Tokio runtime. Your async def tools execute on a per-call coroutine.

Streaming tools

LangChain tools that return generators (yielding chunks) stream through:

def streaming_tool(query: str):
    for chunk in some_streaming_source(query):
        yield chunk

agent = create_react_agent(llm=OpenAI(), tools=from_langchain_tools([streaming_tool]))

The agent observes the streamed chunks as incremental tool observations. The LLM sees the partial state in subsequent reasoning steps.

When NOT to use the bridge

The bridge is great. There are still cases where you should rewrite:

When the tool is hot-path

If a tool is called 1000+ times per second (e.g., a tight retrieval loop), even 80 μs adds up. Rewriting as a native @tool saves the boundary cost.

# Native — no boundary cost
@tool
def hot_path_lookup(key: str) -> dict:
    return cache[key]

When you want language portability

LangChain tools are Python-only. If you want the same tool callable from TypeScript / Rust / Go agents, rewrite as an MCP server:

# A LangChain tool you've ported to MCP
from agentmatic.tools.mcp import serve_mcp
from my_tools import lookup, search

if __name__ == "__main__":
    serve_mcp([lookup, search], transport="stdio")

Now any Agentmatic SDK (Python, TS, Rust, Go, Java) can use the same tool. Plus Claude Desktop / Cursor users get it.

When the LangChain integration is heavyweight

Some LangChain tools import langchain + langchain_community + pydantic + a vendor SDK, contributing to cold start. If cold start matters (serverless), rewrite the tool against the vendor SDK directly.

Going the other way: Agentmatic agents as LangChain Runnables

The reverse bridge wraps an Agentmatic agent as a LangChain Runnable:

from agentmatic.integrations.langchain import as_langchain_runnable

agent = Agent.build("helper", llm=OpenAI(), tools=[...])
runnable = as_langchain_runnable(agent)

# Now usable in LCEL chains, LangServe deployments, LangSmith traces.
chain = prompt | runnable | output_parser

This is how teams keep LangSmith tracing during the migration. The Runnable wrapper emits spans in the LangSmith format; nothing else changes.

TypeScript bridge

The TypeScript SDK has @agentmatic/langchain-js:

import { fromLangchainTools, asLangchainRunnable } from '@agentmatic/langchain-js';
import { DynamicTool } from '@langchain/core/tools';

const wikipedia = new DynamicTool({ name: 'wiki', description: '...', func: async (q) => '...' });
const tools = fromLangchainTools([wikipedia]);

Same semantics, same wrapper overhead.

Headline

The cost of bringing your LangChain toolbox to Agentmatic is approximately zero engineering time and near-zero runtime cost. The cost of rewriting tools is a real engineering investment. Pick the bridge first; rewrite only when there’s a concrete reason.