Flock (Onelevenvy/flock): a Rust and Tauri multi-agent harness with a visual workflow editor

What Flock solves, and who it is actually for

Most agent tooling arrives as a library plus a chat loop. You wire tools by hand, run it in a terminal, and read a wall of text to work out what happened. Flock takes the opposite position: it is a desktop application, and the agent's actions are meant to be visible and interruptible.

The README frames this as a harness rather than a client. The comparison table it publishes puts visual workflow building, filesystem access, multi-step autonomy, cron scheduling and multi-agent orchestration on Flock's side and marks traditional chat clients as lacking them. That is a marketing table, and it flattens real differences between chat clients. The underlying claim is fairer: Flock is aimed at people who want to compose agent pipelines as a graph, watch them execute, and approve the dangerous steps.

The target user is someone comfortable with Rust tooling and containers, who wants a local GUI over LangGraph-style execution and does not want to hand-roll a Tauri shell to get it. It is not aimed at someone who wants a hosted service or a pip-installable Python library.

How the Flock architecture splits across crates and processes

The repository is a Cargo workspace, and the README's architecture diagram is the clearest statement of how the pieces connect. The Tauri desktop UI, built in React with Mantine, talks to the Rust core in `src-tauri` over Tauri commands. That host talks to `flock-agent` over an IPC interface described as a JSON protocol. `flock-agent` holds the executor loop and drives `langgraph-rust` as a graph state machine, with a SQLite checkpointer behind it for persistence and a memory system alongside.

Tool execution is separated into `flock-tools`, a registry that fans out three ways: built-in tools on the local host (bash, files, grep), remote tools over the Model Context Protocol, and isolated container execution through a sandbox client. The sandbox side runs an X11 and VNC server, `x11vnc` plus `websockify`, and streams the desktop back to the UI over WebSockets. Playwright and `xdotool` sit in the same sandbox layer for browser and OS-level control.

Two smaller crates fill gaps. `flock-workflow` contains the node logic and a compiler from JSON to a LangGraph AST, which is what the visual editor produces. `flock-skills` loads system prompts from files with YAML frontmatter and supports hot reloading when those files change.

The split is sensible. Agent execution, tool access and workflow compilation have different failure modes, and keeping the sandbox behind a client boundary means local tools and containerized tools share one interface. The cost is that a bug can sit in any of five crates plus the Tauri host, and the README does not describe how errors propagate across the IPC boundary.

Building Flock and running a first workflow

The README has a Quick Start section in its navigation, but the excerpt available here does not include its contents. What the repository layout does establish is that this is a Cargo workspace with members under `crates/` plus `flock-ui/src-tauri`, and that a `rust-toolchain.toml` pins the toolchain. The workspace declares edition 2024, so a recent Rust toolchain is required.

Building from the workspace root is the path the layout implies. The workspace manifest lists `crates/flock-core`, `crates/flock-tools`, `crates/flock-skills`, `crates/flock-agent`, `crates/flock-workflow`, `flock-ui/src-tauri` and `workspace-hack` as members:

members = [
    "crates/flock-core",
    "crates/flock-tools",
    "crates/flock-skills",
    "crates/flock-agent",
    "crates/flock-workflow",
    "flock-ui/src-tauri",
    "workspace-hack",
]

Because `flock-ui/src-tauri` is a member, a workspace build compiles the Tauri host along with the agent and tool crates. Expect a long first build: the workspace pins `langgraph` at 0.2.5 and pulls in `tokio`, `reqwest` with rustls, and the Tauri stack. A comment in the Cargo.toml notes that `reqwest` uses rustls to avoid a native OpenSSL dependency during cross-compilation, so no system OpenSSL is needed.

reqwest = { version = "0.12", features = ["json", "stream", "rustls-tls"], default-features = false }

The README does not document a run command in the excerpt available, so no launch command is quoted here. The Tauri configuration under `flock-ui/src-tauri` is where the dev and build commands are defined, and it is the first place to look if a build succeeds but the application does not start.

Once running, the README says the built-in agent needs no external CLI: paste an API key for OpenAI, Gemini, Anthropic Claude, AWS Bedrock, or Ollama for local models, and start. MCP servers are connected once, and the README states that all assistants and workflows then inherit the newly exposed schemas and tools. Scheduled tasks use standard cron syntax.

The workflow editor and its ten node types

The visual editor is built on ReactFlow and ships ten node types. `start` and `answer` define inputs and final delivery. `llm` is pure inference; `agent` is a tool-enabled LangGraph agent. `classifier` and `ifelse` handle semantic routing and conditional branching. `code` runs custom JavaScript or Python for transformations. `human` is an interrupt node for manual input. `plugin` and `parameter_extractor` expose custom tools and pull structured data out of model output.

The presence of both `classifier` and `ifelse` is the interesting design choice. A classifier node routes on meaning, which is flexible but nondeterministic; an ifelse node routes on a condition, which is predictable but brittle. Shipping both means the graph author picks per edge, and the README does not say what happens when a classifier returns a label that matches no outgoing edge. That is the kind of gap worth testing before you build anything long-lived on top of it.

The `human` node is the workflow-level equivalent of the interactive tool approvals described elsewhere in the README, where writing files, running bash scripts or modifying configurations require explicit approval. The README also mentions version control and execution history for workflows, so a graph can have multiple versions and past runs can be inspected. How versions are stored is not described; given the SQLite checkpointer in the architecture, the database is the likely place.

Where Flock's design creates real limits

The sandbox is the headline safety feature and also the heaviest dependency. Isolated execution runs in containers, and the VNC path adds `x11vnc`, `websockify` and a WebSocket stream into the UI. On a machine without container tooling, that entire branch of the tool registry is unavailable, and the README does not describe a documented fallback beyond running built-in tools on the local host. Running bash and file tools locally is exactly the configuration the sandbox exists to avoid.

The project also carries its own LangGraph implementation. The README states plainly that `langgraph-rust` is a personal Rust implementation of the LangGraph framework, and Flock is built on top of it. That means two layers under your feet, both maintained by the same author, and the `langgraph` dependency is pinned at version 0.2.5 in the workspace. A LangGraph concept that is well documented for the Python framework may not exist, or may behave differently, in the Rust port. If your workflow depends on a specific LangGraph feature, verify it in `langgraph-rust` before designing around it.

Release cadence is another constraint. The most recent release listed is v0.3.1 from 2026-06-17, with v0.3.0 and v0.2.9 earlier in June 2026. The workspace manifest still declares `version = "0.2.0"` under `[workspace.package]`, which does not match the newest tag. That mismatch may be intentional, but it means you cannot read the workspace version to know which release you are building. The last push to the default branch was on 2026-07-07, so the repository is not archived, but there is a gap between that push and the current date that the release list does not fill.

Finally, the README notes the project was rewritten from a Python, LangChain and FastAPI codebase, with the original preserved in the `legacy/python` branch. Anything you find in older documentation or issues may describe the Python version, which shares a name and a purpose but not a codebase.

Flock compared with running LangGraph in Python directly

The obvious alternative is the Python LangGraph ecosystem: LangGraph itself, LangChain, and a UI layer such as LangGraph Studio or a custom FastAPI backend. The difference is not features so much as where the work happens.

In the Python route, the graph is code. You define nodes and edges in Python, run them in a process you control, and deploy them wherever Python runs. That gives you headless execution, straightforward CI, and the full body of LangGraph documentation and community examples. What you do not get for free is a desktop shell, a visual editor, sandboxed container execution with VNC streaming, or a cron scheduler in the same binary.

Flock inverts that. You get the desktop application, the ReactFlow canvas, the approval prompts and the sandbox out of the box, but the graph is a JSON structure compiled by `flock-workflow` into a LangGraph AST, and execution runs inside the Tauri application through the Rust agent loop. If you need to run the same pipeline on a server without a desktop session, the README does not describe how. The `legacy/python` branch is the historical Python version, not a supported server deployment path.

So the choice is roughly: Python LangGraph when the pipeline must live in your own infrastructure and be scriptable; Flock when a human needs to watch, approve and intervene, and a desktop application is an acceptable delivery vehicle.

Licence and the cost of upgrading

Flock is Apache-2.0, declared both in the repository metadata and in `[workspace.package]` in the root Cargo.toml. Apache-2.0 is a permissive licence with an explicit patent grant, and it does not require you to publish modifications. If you fork the workspace and ship a modified desktop build, the main obligations are keeping the licence and notices intact. That is a general description of the licence, not legal advice; read the LICENSE file at the repository root for the actual terms.

Upgrade cost is harder to estimate. The workspace pins `langgraph` at 0.2.5 and depends on a Tauri host plus five internal crates, so a version bump can touch the agent loop, the workflow compiler and the UI at once. The README does not document a migration path between releases, and it does not mention schema migrations for the SQLite checkpointer. If you run scheduled cron tasks against a database that changes shape between versions, back up the database before upgrading. The `flock-data/` directory at the repository root is where the application's local data appears to live, so that is the first place to look when checking what an upgrade would touch.

Editorial conclusion

Adopt Flock if you want a desktop, Rust-native harness where agent steps are visible and approvable, and you are willing to build it from the workspace rather than wait for a packaged installer. Do not adopt it if you need a documented headless deployment, a stable crate API to depend on, or a project with a long release cadence behind it. Before committing, verify the build succeeds from the top-level Cargo.toml, confirm the workspace version field matches the release tag you intend to use, and check whether the sandbox and VNC components require container tooling on your machine.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Onelevenvy/flock on GitHub
4. README
5. Releases