Lang-Agent: a visual LangGraph builder that lets you define your own state variables

The problem: workflow builders that only pass the previous node's output forward

Most visual agent builders treat a graph as a pipeline. The output of one node becomes the input of the next, and any branching decision has to be derived from that single value. Lang-Agent's README states the project exists because traditional workflow-like projects do exactly this, and it positions itself against that model by allowing custom state variables that can be read and written by nodes and by conditional edges. The practical consequence is that a loop counter, a retrieved document set, a user-supplied path, or an intermediate classification can live in the graph state and be consulted anywhere, instead of being threaded through every intermediate node. The audience is narrow and specific: developers who already understand LangGraph concepts such as nodes, edges and state, and who want a canvas on top of that mental model rather than a replacement for it. The README is explicit that the design is closer to ComfyUI than to Dify or Coze, which is a statement about who is expected to build the blocks. If you want a catalogue of pre-built integrations, this is not the framing you are looking for.

How the canvas maps onto LangGraph state, nodes and conditional edges

The Agent configuration page is split into a resource tree on the left and a canvas on the right. Nodes and Agents are dragged from the tree onto the canvas, edges are created by dragging between the stubs of two nodes, and Backspace deletes the selected node or edge. That canvas is not a runtime of its own; it is a configuration surface that produces a LangGraph structure. The start node is mandatory and unique per Agent, and it carries the state variable definitions. The README notes that a state variable called messages always exists to hold conversation messages, and that users can add their own. Nodes update that state when they execute, and conditional edges read it to decide whether the target node runs. The expression syntax differs by variable type: messages entries are referenced as {{messages['x']}} where x is the name of some node in the Agent, while custom variables are referenced as {{y}} where y is the variable name. Conditional edges, system prompts, user prompts and several node fields all accept these expressions, which is what makes the state model useful rather than decorative. One documented restriction matters here: custom state variables do not currently support the list type. The README says this is under consideration for later. Until that changes, anything list-shaped has to live in messages or be encoded some other way.

The node inventory, including two nodes that execute code and shell commands

Beyond start and end, the README documents input, LLM, VLM, counter, transformer, document loader, image loader, document saver, code executor, command executor and vector recall nodes. Each has a name that must be unique within the Agent, and most have optional prompt fields that accept state variable expressions. The counter node increments a chosen state variable, which is how the documented loop examples are built. The transformer node moves a value from a source state variable to a target state variable, defaulting to messages as the source. The document loader accepts txt, pdf, docx and md; the image loader accepts jpg, png and jpeg and outputs base64, which is what the VLM node consumes through its image URL field. Two nodes deserve separate attention. The code executor runs Python that must be wrapped in triple-backtick python fences, and the command executor runs operating system commands, defaulting to the lang-agent-backend directory when no working directory is given. Neither is described as sandboxed in the material provided. That is a design decision with consequences: an Agent containing these nodes is effectively an execution environment, and the trust boundary is whoever can edit the Agent configuration. The README does not discuss permissions, authentication or per-user isolation, so treat that as unverified rather than absent.

Prebuilt versus reusable Agents, and how SupervisorAgent composes them

Lang-Agent splits Agent nodes into two categories. Prebuilt Agents ship with the project and can be dropped onto the canvas directly. The README documents two: ReactAgent, which lets the model call MCP tools configured in the MCP configuration page, and SupervisorAgent, which lets the model call other reusable Agents. Reusable Agents are ones you built yourself and marked with the reusable switch in the Agent configuration. That gives a two-level composition model: leaf Agents that do work, and a supervisor that routes between them. The ReactAgent requires a model and a selection of tools drawn from the MCP configuration, so tool availability is a configuration step before the Agent is built, not something the Agent discovers at runtime. The SupervisorAgent requires a model and a selection of reusable Agents. Both are documented with example JSON files in the examples directory, which is also how the project communicates intended usage for nodes like the loop chat, the poet example, the VLM demo and the advanced conditional edge case. If you want to understand the intended shape of a graph before building one, those files are the reference, not the screenshots.

Getting it running: poetry for the backend, yarn for the frontend

The repository is split into lang-agent-backend and lang-agent-frontend. The backend uses poetry. The README gives these commands: cd lang-agent-backend, then poetry env use python, poetry shell, and poetry install. The backend starts with python -m lang_agent.main. The frontend uses yarn: cd lang-agent-frontend, yarn install, then yarn dev, with the default address http://localhost:8820. Configuration happens through the UI rather than through files. For a model you click the model configuration tab, press the plus icon, and fill in a unique name, a type (llm, vlm or embedding), a channel, and connection parameters that follow the ChatOpenAI parameter set. The README states the channel currently supports only OpenAI-compatible endpoints, with more planned. MCP connections take a unique name, a description, and parameters following langchain-mcp-adapters. Vector stores take a unique name, a type limited to postgres or milvus, plus URI, username, password, database name, collection name and an embedding model chosen from your model configuration. Documents are added, vectorised and deleted from the document management view inside a vector store configuration. Note the asymmetry: the backend is Python and poetry, the frontend is TypeScript and yarn, and the repository's primary language is listed as TypeScript, so expect to work in both toolchains.

Where it is the wrong tool: no release artefacts, no sandboxing claims, no list state

Three limitations are visible in the material. First, custom state variables do not support lists, which constrains how you model anything collection-shaped. Second, the model channel is limited to OpenAI-compatible endpoints, so a provider with a different protocol needs a translation layer you write yourself. Third, and most consequential, the code executor and command executor nodes run Python and shell commands with no sandboxing described in the README. That makes Lang-Agent a poor fit for any deployment where Agent authors are not fully trusted, and a poor fit for multi-tenant SaaS without additional work that the documentation does not cover. There is also a maintenance signal worth naming plainly: the repository has no releases retrieved, and the last push date is 2026-07-20. The README itself promises that more channels and list-type state variables are coming. Those are statements of intent, not shipped features, and you should plan as if they will not arrive. If your requirement is a hosted builder with a large integration catalogue and no shell access, this project is aimed at a different user.

How it differs from Dify and Coze, and from writing LangGraph by hand

The README draws its own comparison, saying the design is closer to ComfyUI than to Dify or Coze. The difference is where the extensibility lives. Dify and Coze are oriented around a supplied set of blocks and integrations that you configure; Lang-Agent is oriented around nodes you develop, with the README stating that custom node development requires no changes outside the custom node directory itself. That is a real architectural claim: the frontend has a custom node directory, and the backend is expected to accept new node implementations without edits elsewhere. The other comparison is against writing LangGraph directly in Python. Here the trade is explicit. You give up the full expressiveness of Python for graph construction and get a canvas, a saved Agent record in a database, import and export as JSON, and a chat panel for running the result. For graphs that are mostly linear with a few conditional branches and a state variable or two, the canvas plus export is a reasonable artefact to hand to a colleague. For graphs that need dynamic node generation or complex state reducers, the canvas will get in the way, and dropping to raw LangGraph is the better call. The state variable expression syntax is the seam between the two worlds, and it is deliberately small: {{messages['x']}} and {{y}}.

Licence, upgrade cost and what the repository does not tell you

The project is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. That is the permissive end of the spectrum, and it means you can vendor and modify the backend and frontend without a copyleft obligation on your own code. It does not tell you anything about the dependencies you will pull in through poetry and yarn, and those carry their own licences that you should review separately. On upgrade cost, the honest answer from this material is that it is unknown. There are no releases retrieved, so there is no changelog to read, no version tags to pin against, and no migration notes. The README describes features as planned rather than versioned. If you adopt this, pin your dependencies and keep your exported Agent JSON files under version control, because those exports are the portable artefact of your work and they are what you would rebuild from if the project's direction changes. The import and export buttons on the canvas exist precisely so that the graph definition is not trapped in the database, and using them is the cheapest insurance available here.

Editorial conclusion

Adopt Lang-Agent if your team already writes LangGraph nodes in Python and wants a canvas to wire them together, and if you are comfortable running an agent that can execute arbitrary Python and shell commands. Do not adopt it if you need multi-tenant isolation, a hosted service, or a node library you do not maintain, because the project expects you to develop nodes for your own business. Before committing, verify three things on your own machine: that the backend starts with python -m lang_agent.main, that your model endpoint is reachable through the OpenAI-compatible channel the project currently supports, and that the code executor and command nodes match your security posture, since the README documents no sandboxing for either.

Official sources

1. cqzyys/lang-agent on GitHub
2. Issues
3. License: Apache-2.0
4. README