---
title: "Bring Your Own Agents: OpenClaw and LangChain, now on Guild"
canonical: "https://www.guild.ai/blog/engineering/bring-your-own-agents-openclaw-langchain"
---

# Bring Your Own Agents: OpenClaw and LangChain, now on Guild

- **Category:** Engineering
- **Author:** Cory Waddingham
- **Published:** Sep 09, 2026

A few months ago, when we [announced support for Goose agents](https://www.guild.ai/blog/product/bring-your-own-agents-goose), we promised that more would follow soon.

Soon is now.

We're excited to announce that Guild now fully supports running agents written for OpenClaw and LangChain.

## The promise we made

When we brought Goose recipes onto Guild, the argument underneath was simple. The best AI agent is often one you've already built, and getting it onto a real platform should not mean rewriting it. You declared a Goose recipe, and Guild ran it with a typed interface, versioning, and a runtime the rest of your team could actually call.

Goose was the first framework we supported this way. It was never meant to be the last. Two frameworks join it today, and one of them changes the shape of what "bring your own agent" means.

## Two agents, two very different shapes

Goose recipes are declarative. You describe the agent in YAML and Guild runs the description.

OpenClaw and LangChain are a different breed. One is another framework-native agent with its own runtime and its own idea of a session. The other is your own Python: a LangGraph graph you wrote, running as itself.

Supporting both meant Guild had to run each one on its own terms, without asking you to bend your agent to fit ours. Here is how each works.

## Introducing OpenClaw support

[OpenClaw](https://github.com/openclaw/openclaw) is an open-source agent with a growing following, and OpenClaw authors tend to have real agents already running: prompts, workspace files, MCP tools, the whole thing wired up and working locally.

An OpenClaw agent is mostly the prompt you already wrote. Here is one that turns merged pull requests into release notes:

```
# Release Notes Agent

Turn the merged pull requests I point you at into clean release notes.
Group them into Features, Fixes, and Internal. One plain sentence per
change, each linked by its PR number. Skip anything tagged `chore`.

Use the GitHub tools to read the PRs. If a change is ambiguous, ask
before you file it.
```

That is the agent. On Guild it runs exactly as it does on your machine. The prompt and workspace files come along unchanged, and the tools keep working, because Guild brokers them and governs the model behind them. We run the whole thing inside a sandboxed container that lives and dies with a single task, so one agent's run never sees another's. From the rest of Guild, it looks like any other agent: something with an interface, a version, and a runtime that people and other agents can call.

You do not port an OpenClaw agent to Guild. You bring it, and it runs.

## Introducing LangChain support

This is the one that changes the shape of the thing.

Goose and OpenClaw are frameworks with their own runtimes. LangChain is a library, and a LangGraph graph is Python code that you wrote. There is no recipe to interpret and no external engine to drive. Your compiled graph runs in-process, as itself.

That is a stronger thing to say than "we support a format," so it is worth being precise about what it costs and what it buys.

The cost is a few lines, not a rewrite. You point your model and your tools at their governed equivalents:

```
from guildai_langchain import guild_model, guild_tools
from langchain.agents import create_agent

async def graph():
    return create_agent(guild_model(), await guild_tools())
```

Then you name the graph in a langgraph.json, the same manifest you already write:

```
{ "graphs": { "agent": "./graph.py:graph" } }
```

That is the diff. guild_model() is governed model traffic. guild_tools() is the task's brokered tool set: MCP tools, sub-agents, and integrations, all reached through Guild. Point Guild at the graph, and it imports it and runs it. For those few lines, you get:

- **Model traffic is governed, with or without the swap.** Even a plain ChatOpenAI() in your graph gets routed through Guild's LLM proxy before your code loads. The provider, the model, and the key are resolved server-side, and your team's spend and policy rules apply to every call.
- **The sandbox is the boundary.** Your graph runs in a container with no open path to the internet. Model calls and tool calls go through Guild, under your policy. That is the whole point, and it is why your tools move to guild\_tools(): a tool that tries to reach out on its own has nowhere to reach.

We built this for the v1 generation of LangChain, so create\_agent(model, tools) and modern LangGraph are the target, not the pre-v1 AgentExecutor patterns from early agent deployments.

Swap the model, swap the tools, point us at the graph. Your LangGraph agent runs governed, and every call it makes is on the record.

## What Guild adds, whatever you built it in

The framework is where the differences live. What Guild wraps around all three is the same, and it is the reason to put an agent here in the first place.

Every agent gets a validated, typed interface, so the things that call it know what it expects and what it returns. Every agent gets versioning, so a change is a new version and not a surprise. Every agent runs in an isolated container that is the security boundary, with model traffic and tool access flowing through a control plane your organization owns. And every agent becomes composable: the moment it is on Guild, other agents can call it, people can run it, and it can pull in sub-agents and integrations of its own.

That last part is what turns a single agent into leverage. Your OpenClaw triage agent and your LangGraph reviewer stop being two islands and start being pieces other work can build on.

Agents do the work. Your team owns the outcome, with the governance to prove it.

## From your framework to Guild in minutes

A Goose recipe, an OpenClaw agent, and a LangChain graph walk into a Guild. They come out with the same typed interface, the same version history, and the same governance. The bartender could not tell them apart.

That is the point.

Three frameworks, one path onto the platform. Each keeps its own shape, and each lands with the same interface, the same versioning, and the same governance underneath.

You built it. Guild runs it.

## What's next

Goose was first. OpenClaw and LangChain make three. The list of "agents you can bring" is going to keep getting longer, because the point was never a single framework. The point is that the agent you already trust deserves a real home, and you should not have to rebuild it to give it one.

We have a few more in the workshop. Same promise as last time: more will follow soon.

[Read the docs](https://docs.guild.ai) to see the details for your framework, or [jump in and bring your first agent today](https://app.guild.ai).

## Bring your first agent

Goose, OpenClaw, or LangChain. Your agent keeps its shape and lands with a typed interface, versioning, and governance underneath.

[Bring your agent](https://app.guild.ai)