Why Loom exists
The model is one part of the agent.
Tools define what the agent can do. Authority defines what it may change. Evidence determines what a team can verify. Loom studies how those pieces shape a release decision.
- Unit of study
- One workflow
- Decision
- Ship / Change / Stop
The starting question
When an agent fails, which part of the surrounding system should change?
The answer may be a permission, an approval, an observation, a tool contract, or the shape of the workflow itself. Loom makes that choice explicit and testable.
A working definition
The Harness is the operating system around the model.
A Harness can prevent failure. It can also duplicate evidence, add friction, or make the intended workflow impossible to complete.
How we work
Three moves. One bounded decision.
- 01→
Start with the workflow
Name the outcome, the actions the agent can take, and the systems those actions can change.
- 02→
Follow the evidence
Separate what the tools prove from what the team assumes or infers.
- 03→
Test the trade-off
Compare one bounded change on task completion and protected constraints.
Controlled benchmarks have exposed redundant verification and harmful approval designs.
These findings show why task success and assurance outcomes need to be evaluated together.
How well do these findings transfer to customer production systems?
Loom has no customer production validation or proven willingness to pay yet. Those questions require real workflow conversations.
Customer discovery
Bring one workflow where the release decision is difficult.
Show us what the agent can change, which control is under debate, and what evidence the team can inspect.
Talk to us about your agent workflow