A control layer for AI coding agents
Loom binds a plan to the current project, grants implementation authority separately, and requires real evidence before completion.
What makes Loom different
One optimistic status cannot stand in for the whole chain. Loom keeps the observed project, exact plan, implementation authority, and qualifying evidence distinct.
/loom <request> surface
No Loom telemetry
Why Loom exists
A coding request arrives beside repository history, uncommitted files, local instructions, architectural boundaries, domain rules, unknowns, and checks that only make sense in the real runtime.
Loom represents that world before implementation. It can keep small work small, expand consequential work, or block when the evidence needed to plan safely is missing.
One request, six represented states
Planning can be reviewed without permission to execute it. If the exact plan or observed project changes, the earlier authority no longer describes the same work.
A complex request
Loom records the request, resolves the target, and inspects committed, staged, unstaged, and untracked state. A changing or unsafe world is a reason to stop, not a detail to smooth over.
Represented output: project inspection and request scopePlanning
Facts, assumptions, open decisions, likely touch paths, work orders, and required proof are made explicit. Artifacts are produced for a named consumer and decision, or skipped with a reason.
Represented output: plan contract and work ordersExecution authority
A plan can be reviewed without granting implementation authority. Authorization is bound to exact plan content and the observed baseline. If either changes, the earlier authority no longer describes the same work.
Represented output: sealed action and authority stateValidation
Tests, builds, runtime checks, screenshots, or another declared medium provide evidence. A written status flag or a pre-existing deliverable does not establish that the authorized work caused the result.
Represented output: verification evidence and receiptIssue recovery
A failed gate does not silently authorize repair. Loom can represent the blocking condition, preserved state, recovery action, and the smallest route back through planning, authorization, or validation.
Represented output: block reason and recovery receiptCompletion
Completion stays distinct from “the agent stopped.” Loom records the outcome, verification state, reversibility, and the next action the owner can review.
Represented output: owner message and completion stateWhat users can review
Exact contents vary with task consequence, uncertainty, domain coverage, and the consumer who needs to make the decision.
The target, applicable instructions, change census, lifecycle, and unresolved gaps.
Scope, artifacts, dependencies, assumptions, decisions, and required proof.
Exact work, likely touch paths, acceptance evidence, and stopping conditions.
Whether implementation is permitted, blocked, expired, or invalidated by drift.
What ran, what failed, what was preserved, and the bounded route back.
Outcome, consequence, freshness, reversibility, verification, and one next action.
Proofline and Completion
Loom connects intent, authorized scope, implementation, verification, recovery, and completion in one reviewable chain. The current signed public release is Loom 1.8.30.
The release binds source, tag, plugin bytes, hashes, native helpers, and verification metadata to the exact public cut.
Intent ledgers, proof graphs, scope checks, completion reports, trust cards, and proof bundles keep the result inspectable.
Runtime versions remain separate from the encrypted owner vault. Loom sends no Loom telemetry and keeps scoped learning on the owner’s machine.
Start with one request
Loom reads the current project, prepares reviewable work, and keeps authority and completion tied to that exact request.
/loom <request>
The start guide covers artifact verification, installation, the first health check, and the local data boundary.