Weft: a Rust language where an LLM call, a Postgres query and a human approval are all nodes

Cloning the repository and starting two terminals

The quick start is a clone, a config copy, and two commands in separate terminals. There is no build step for the language itself because there is no compiler binary to install; `dev.sh` is the entry point.

git clone https://github.com/WeaveMindAI/weft.git
cd weft
cp .env.example .env

Then the backend and the dashboard come up as separate processes:

./dev.sh server
./dev.sh dashboard

The dashboard listens on port 5173. The prerequisites list is short and specific: Docker for PostgreSQL, Node.js, and on macOS a note to install bash 4 or newer with `brew install bash`. The comment on the server command claims it auto-installs dependencies, starts PostgreSQL and Restate, and brings up the remaining services, and it also states that Rust, Restate and pnpm are installed automatically if missing.

That last promise is the one to test before relying on it, because a script that installs a Rust toolchain on your machine is doing something you may want to see rather than discover. The `.example.env` files at the root give you the shape of the configuration without any secrets in them.

API keys are entirely optional. The README says a node that needs a key raises a clear error at run time when it is missing, so you can get the language running with nothing configured and add credentials node by node:

OPENROUTER_API_KEY=     # LLM nodes (OpenRouter)
TAVILY_API_KEY=         # Web Search nodes
ELEVENLABS_API_KEY=     # Speech-to-Text nodes

OpenRouter for model access, Tavily for search, ElevenLabs for speech. Apollo enrichment and a Discord bot token are also named. The `.env.example` file adds an E2B key for the Python execution node and a base64 32 byte value for AES-256-GCM credential encryption, with an explicit warning that a development key is used if you leave it unset and that this is not secure for production.

Every node is a folder with a Rust file and a TypeScript file

The most concrete architectural decision in this repository is that `catalog/` is the single source of truth, and each node is a directory holding exactly two files. `backend.rs` holds the Rust implementation against the `Node` trait. `frontend.ts` holds the dashboard definition: ports, config fields and an icon.

The catalog is organised by capability rather than by layer: `ai/` for LLM config and inference, `code/` for Python execution, `communication/` for Discord, Slack, Telegram, WhatsApp, Email and X, `data/` for Text, Number, Dict, List and pack or unpack, `enrichment/` for Apollo, web search and speech to text, `flow/` for gate and human query or trigger, `storage/` for Postgres, and `triggers/` for cron, webhooks and polling. The README puts the count at a few dozen nodes across those categories and describes the selection as intentionally opinionated.

The two file split explains a design choice that would otherwise look odd. The same node definition drives the compiler, the backend runtime and the visual graph, which is why the project can claim a graph that is generated from the program rather than drawn separately and kept in sync by hand. The cost is that adding a node means writing in two languages, and that a compiler improvement that changes the node contract has to land across every existing catalog entry.

Underneath, four Rust crates carry the weight: `weft-core` for the type system, the Weft compiler, the executor and the Restate objects; `weft-nodes` for the node trait, registry and node runner binary; `weft-api` for the REST surface covering triggers, files, infrastructure and usage; and `weft-orchestrator` for the Restate services and the Axum project executor. The dashboard is SvelteKit on Svelte 5, and there is a browser extension built with WXT for the human in the loop path.

Restate is what makes a three day wait ordinary

The claim that separates Weft from a workflow library is durability across long waits. Programs survive crashes and restarts through Restate, and the README's phrasing is that a human approval taking three days is the same code as one taking three seconds. The human-in-the-loop node sends a form to a person, waits, and resumes at the exact point it left off, with no webhook plumbing and no polling loop in your own code.

The `Cargo.toml` confirms this is a real dependency rather than a slogan: `restate-sdk` at version 0.7, with `weft-orchestrator` holding the Restate services. For that to work, each suspended step has to be reconstructible from durable state, which is the part that makes the type system and the executor cooperate rather than sit beside each other.

The browser extension is the other half of that story. A form sent by email or chat is awkward to fill in, so the project ships a WXT extension for the human in the loop path, which is a small detail that tells you the author has actually watched the flow rather than only designed it.

Two native views are claimed for the same program: dense code for people building with AI, and a graph for people reviewing it, with edits in either reflected in the other. Given the catalog arrangement described above, that consistency has a plausible mechanism behind it, since both views would read the same catalog entries and the same project files.

The main branch is parked while an mvp rewrite ships

The README opens with a status note that should shape how you read everything after it. It says the main branch is inactive because Weft is being rebuilt in the mvp branch, with a planned release for September 2026, and it invites feedback on Discord. The repository description on GitHub says the same thing in four words: a programming language for AI orchestrations, marked POC.

Set against that, the repository listing is busy. Four workspace crates, a catalog, a dashboard, a browser extension, shell scripts, an `init-db.sql`, a `.sqlx` directory, a `sidecars/` directory, a `catalog/` tree, and a `DESIGN.md` next to a `ROADMAP.md`. The last push was on 2026-09-19, and the single release is tagged `mvp-latest` under the name Rolling build (mvp), published 2026-08-31, whose body says the build is produced from a specific commit and that `setup.sh` downloads it when its checkout matches the manifest.

Both of those facts are true at once and the tension between them is the thing to plan around. The source tree you can read today is substantial and current, while the branch that receives the rebuild is somewhere else. If you are evaluating this, the concrete question is which branch your work would sit on, because the README itself warns that breaking changes are expected while the shape settles and that migration notes will accompany them.

One detail in the release notes does not match the tree. The `mvp-latest` body says `setup.sh` downloads the build when a checkout matches the manifest, yet no `setup.sh` appears at the root, where you find `dev.sh`, `init-db.sh`, `cleanup.sh` and `build-extension.sh` instead. Both can be true if the script lives on the mvp branch, but a reader following the release notes from `main` will not find the file they were told to run.

The README is also unusually candid about its own writing, noting that most of the prose was written quickly to get the release out and inviting pull requests that improve the documentation. That is a good sign about the project's intentions and a reason to distrust any single README sentence as a specification.

A license field that names no license you have seen before

GitHub reports no recognised license for this repository, and there is a LICENSE file at the root. The workspace manifest explains the mismatch: the shared package metadata sets `license = "LicenseRef-OSAASy"`, a custom SPDX license reference rather than one of the standard identifiers.

That form is legal and deliberate. SPDX permits a `LicenseRef-` prefix for licenses that have not been issued an official short identifier, and it signals that the grant is documented in a file rather than in a widely recognised standard. The practical consequence is that a license scanner will not match this repository to a known license, and an automated compliance check may flag it or silently pass it. You have to read the LICENSE file to know what you are agreeing to, and that reading is not optional before commercial use.

Two other files sit alongside it that are worth knowing about. `SECURITY.md` describes how to report a vulnerability, and `CODE_OF_CONDUCT.md` sets expectations for behaviour in the project. `CONTRIBUTING.md` is listed too, and the README's request for documentation pull requests suggests the contribution path is genuinely open.

For a project that stores encrypted trigger credentials and provisions Kubernetes sidecars, the existence of a security policy is worth more than it would be in a small library, and the `.env.example` warning about a non-production encryption key shows the authors are thinking about where that boundary sits.

What the compiler claims to catch, and what it cannot

The type story is the part of the pitch that deserves the most scepticism. The README lists generics, unions, type variables and null propagation, and says the compiler catches missing connections, type mismatches and broken architecture before anything runs. The poem example makes the claim concrete: four nodes and four edges, with the compiler validating every connection and type before the paragraph finishes loading.

Here is the whole of that example's execution half, which is the part worth reading closely because it shows how little ceremony a node connection needs:

poet = LlmInference -> (response: String) {
  label: "Poet"
}
poet.prompt = topic.value
poet.config = llm_config.config

output = Debug { label: "Poem" }
output.data = poet.response

A node declares its output type in the constructor, then inputs are attached by dotted assignment rather than by arguments. The `LlmInference` node names a single typed output, `response: String`, and the two config lines bind a text input and an LLM config to it. Reading assignments rather than a call signature is a real design choice, and it is what lets the same source collapse into a graph node.

What the compiler cannot check is the semantic layer. It can tell you `poet.response` is a String and that `output.data` expects whatever `Debug` accepts. It cannot tell you that temperature 0.8 is the right setting for a four line poem, that an Apollo enrichment call on a domain that does not resolve is wasted spend, or that a human gate placed after a paid model call is the wrong order. The README claims the compiler catches broken architecture, and it is worth reading that as type-level and connectivity-level rather than as business logic.

The README is candid about one limit itself. The long-term goal is to let projects define their own nodes fluently in the language, and it states plainly that this is not the case right now: today every node is a folder written by hand in Rust and TypeScript.

Editorial conclusion

Weft is interesting as a design document you can execute. The idea it commits to, that a human waiting three days is the same node as a model call returning in three seconds, is a genuinely useful thing to see working, and the `catalog/` directory makes adding a node a two file job rather than a framework negotiation. Two facts should govern any decision to build on it. The workspace declares `license = "LicenseRef-OSAASy"` rather than a standard SPDX identifier, so the grant needs reading from the LICENSE file before you ship anything built on it. And the README's first line says the main branch is inactive during an mvp rebuild, so the language, the type system and the durable executor may all move. Start at the four node poem program, read `DESIGN.md` next to it, and pin a commit before you depend on any of it.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. WeaveMindAI/weft on GitHub