How Lamoom Works
The four pieces#
| Piece | What it is |
|---|---|
| App | A published agent loop with a name, a price, and a category |
| Run | One execution of that loop inside your Claude, against your files |
| Judge | A scoring gate the run must pass before it is allowed to finish |
| Console | The record of every run: files, reasoning, and judge scores |
Where execution happens#
When you say /lamoom run <app>, your Claude fetches the loop definition and executes it locally. Lamoom never receives your files. This is the difference between an agent marketplace and a hosted SaaS tool, and it is the reason app authors can publish loops that touch private repositories and personal documents.
Why loops carry judges#
A plain prompt returns whatever it returns. A Lamoom loop is built to refuse a weak result: the loop scores its own output against explicit gates and repeats until they pass. FrontendBuilder will not finalize a UI change until four judges score it 10/10. Well-Architected Design refuses to produce a decision document until six separate gates hold.
That behavior is what makes a published loop different from a prompt someone shared: the quality bar travels with the app.
What the console keeps#
Every run writes its work to files as it goes, not only at the end. If a subagent dies halfway, its collected data is already on disk. The console shows you the reasoning trail and the judge scores next to the result, so you can see why an output looks the way it does.
Read Runs and Judges for the mechanics of a scoring gate, or go build one with Building a Loop.