Loom: a delivery harness that keeps agentic coding work recoverable

What Loom is for, and who it is not for

Loom is an open delivery harness for coding agents. The README describes it as running beside the agent you already use and turning a larger change into a delivery loop: clarify scope, plan, build, run checks, repair failures, preview the result, leave a handoff. That framing tells you the intended user. It is not for someone who wants a chatbot to produce a first draft of a function. It is for work that needs more than a generated first pass, which the README lists as a feature, a review, a deployment, a repair, or a change someone else must inspect and continue. The project ships under Apache-2.0 and is written primarily in Rust, with Python handling what the README calls Loom's algorithms. The last push to the repository was on 2026-09-14, and the most recent release listed is v0.2.9 from 2026-08-14. Those dates matter because the tool sits in the path of your delivery process, not off to the side. If you never resume work across sessions and never hand a change to another person, the state directory Loom maintains is overhead you will pay for and not use.

The .loom/ directory is the actual product

Most of what Loom does reduces to one design decision: delivery state lives in a project-local .loom/ directory rather than in the conversation. The README says that directory keeps requirements, task progress, results, runtime facts, and repair history, and that a new session can pick up the actual state of the work instead of reconstructing it from chat history. The delivery model table splits that state across four stages. Scope and design holds confirmed requirements, decisions and task boundaries. Execution holds task-specific context, write targets and recorded results. Verification holds tests, runtime checks, previews and review findings. Repair and handoff holds repair requests, re-verification and the project state for the next person or session. The context routing diagram shows the flow in more detail. The agent sends a delivery goal, repo context, logs, tests and preview evidence into Loom. Inside Loom a dynamic workflow router produces a request manifest and an agent read plan, with four named parts: requestReadPlan for grouped required reads, MCP field resources for targeted retrieval, write targets for authorized artifact I/O, and an action result carrying the next tool and a compact view. What comes back to the agent turn is a compact instruction, selected field groups and a retrieval path. The point of that indirection is stated plainly: Loom selects technical references and context for the current task rather than loading the entire repository or a large generic skill into every turn. Whether that selection is right is the thing to watch. A router that picks the wrong field group will leave the agent confidently under-informed, and the state directory will record the result as if the context were complete.

Installing Loom and running a first build

The prerequisites are narrow. You need one supported coding agent installed locally (Codex, Claude Code or OpenCode), and Docker only for loom deploy. The README gives a one-line installer that detects your OS and CPU, downloads the matching release package, verifies the package .sha256 asset, installs the Rust MCP server, creates an isolated Python runtime for Loom's algorithms, writes the agent MCP registration, refreshes the local plugin, and runs loom-setup doctor. To install for a single agent, pass its name:

curl -fsSL https://github.com/valkor-ai/loom/releases/latest/download/install.sh | bash -s -- --agent claude-code

Substitute codex or opencode for a different agent, or all to register every supported agent on the machine. On Windows the README uses PowerShell instead, downloading install.ps1 and running it with an -Agent argument.

Once installed, the Start Here table gives the command forms. In Codex you address Loom with @loom; in Claude Code and OpenCode you use a slash command. A first real use is a feature request:

/loom build Add a team settings page

What you should see is the delivery loop begin: scope clarified, a plan produced, work executed against write targets, checks run, and failures routed into repair. The other three entry points in the same table are continue, review and deploy, and they map to resuming an interrupted delivery, reviewing and repairing a change, and validating a local preview. If you are working from a checkout rather than a release, the README documents a local build mode that builds the Rust MCP server and setup binary, writes the release package layout, installs through loom-setup and runs doctor:

./install.sh --agent codex --local-build

The README recommends that path after local bug fixes, so that installer, package layout, MCP registration and plugin refresh are verified together.

Upgrades reuse the same command, with an ownership check

There is no separate upgrade path. The README states that running the same install command again upgrades Loom. The installer removes Loom-owned legacy CLI plugin artifacts before installing the MCP runtime. The interesting part is the failure mode it defines: if the installer finds files it cannot prove are Loom-owned, it stops and tells you what to remove manually instead of overwriting user files. That is the right default for a tool that writes into your agent's plugin and MCP registration, but it means an upgrade can halt on a file you created months ago and forgot about. Expect to read the installer's output rather than assume success. The README also notes a July 2026 change that moved the MCP runtime from TypeScript to Rust to make the core smaller and faster. Anyone upgrading across that boundary is running an installer that has to clean up artifacts from the older layout, which is exactly the situation the ownership check exists for.

Where Loom is the wrong tool

Loom adds a runtime between your agent and your repository. The README lists two prerequisites that are also constraints. You must have one of Codex, Claude Code or OpenCode installed locally; there is no documented path for an agent outside that list, and the routing diagram labels future agents as a category rather than a supported one. Docker is required for loom deploy, so a machine without it loses the preview and validation stage of the loop. The larger limitation is structural. A delivery harness is only as good as the state it records, and the README does not document rollback of that state. If a plan is wrong, or a repair request sends the agent down a bad path, the .loom/ directory will faithfully preserve the wrong turn along with everything else. There is no documented command for discarding a delivery and starting clean. For a one-file change, or for exploratory work where you do not yet know what the task is, the scope-confirmation and task-boundary machinery is cost without benefit. Loom is for work whose shape is already roughly known and whose completion someone will need to check.

How Loom differs from a plain agent workflow

The honest alternative is not another harness. It is the workflow you already have: a coding agent, a repository, and a chat session you keep open. The difference in approach is where continuity lives. A plain agent session keeps context in the conversation window, so resuming means either leaving the session open or reconstructing what happened from the transcript. Loom moves that continuity into files under .loom/ and reconstructs a compact instruction and a retrieval path for each turn instead of replaying the whole history. That is a real architectural difference, and it has a real cost: the agent now depends on Loom's router choosing the right field groups, and on the MCP runtime being installed and registered correctly. A second, narrower alternative is the agent's own project-memory features. The README does not compare Loom to them, and the mechanism here is different in kind, since Loom records verification evidence and repair history rather than notes. If your work never crosses a session boundary, the plain workflow is simpler and has fewer moving parts to break.

Licence, maintenance and what the README leaves open

Loom is licensed Apache-2.0, which permits commercial use and modification and includes a patent grant. The repository is not archived, and the last push was on 2026-09-14, three days before this writing, with v0.2.9 released on 2026-08-14. That is a recent cadence, but the version number tells its own story: this is a 0.x project, and the README documents a runtime rewrite in July 2026. Treat the install surface as moving. The README points to a technical report PDF, a use-cases document, a Godot setup guide and a Simplified Chinese README, and the top level of the repository holds AGENTS.md, CONTRIBUTING.md and SECURITY.md alongside src/, plugins/, scripts/ and tests/. The package.json is marked private and its scripts cover Rust and Python test entry points, including a serial variant of the full cargo test run. What the README does not document is rollback of .loom/ state, a supported-agent list beyond the three named, or behaviour when the router selects a field group the task did not need. Those gaps are where a pilot will teach you more than the README will.

Editorial conclusion

Adopt Loom if your work routinely outlives one agent session: multi-step features, reviews, repairs, or changes another engineer must pick up, and you already run Codex, Claude Code or OpenCode. Skip it if you only want a single generated first pass, or if you cannot run Docker, since loom deploy depends on it. Verify first that loom-setup doctor passes after install, that the installer's ownership check does not stop on files it cannot prove are Loom-owned, and that a resumed session actually reads the .loom/ state you expect.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. valkor-ai/loom on GitHub