Memory & learning

LoopCodeLab treats every build as something to learn from. Over time it tunes itself to how you work: the defaults it offers, which agent it picks for a piece of work, and the notes it keeps while a build runs. This is the Loop System, learn, build, repeat. It runs on four parts, and all of them are suggestions you can change.

Preference memory

Every time you start a build, swap an agent, or finish a run, LoopCodeLab records what you chose. Those choices are distilled into a short profile of your consistent preferences. The next build uses that profile to fill in smarter defaults for you, and the planner reads it too.

A single choice does not become a rule. A preference is only confirmed once it recurs across separate builds, so a one-off never turns into a fixed expectation. If you keep picking the same output type, agent, or option, that pattern is what gets remembered.

Agent routing

When the planner splits your idea into stories, it also picks an agent for each story. It weighs three things: how reliable an agent has been, what it costs, and whether it is available right now. That choice is then adjusted by your own history. An agent that keeps stalling or getting its work rejected on your builds gets routed around, and an agent that does well on a kind of task is favoured for it.

You see each pick in the review step before the build starts, and you can change any of them. If you swap an agent while a build is running, that decision feeds the same memory. In solo mode, where one agent does everything, routing steps aside and leaves your choice alone. You can read more about the agents in The build team.

Skill library

After a build finishes, LoopCodeLab can distill a few reusable skill files from what that build learned. A skill file is a short, general set of instructions for a kind of work, written so it would help any future build of that type, with no details specific to your project.

These start as suggestions only. Nothing a build proposes is used in a future build until an admin approves it. A scheduled tidy-up retires skills that have gone unused and merges near-duplicates, and it never deletes anything outright. So the library grows from real builds, but only the approved parts ever shape a new one.

The build logbook

While a build runs, the master agent that reviews and integrates the work keeps a logbook, MASTER.md. It records the decisions it makes: the rulings on each story, any steering it gave a worker, and what it learned along the way.

That record keeps a long build consistent with itself. Later checks read the log instead of working out the same call again, and new workers inherit the standing rulings, so the build holds one line of thinking from start to finish. You can read the logbook for a build to see how those decisions were made. For the wider flow, see How a build works.

It stays a suggestion

All of this is suggest-only. Memory sets smarter defaults and the planner reads what LoopCodeLab has learned, but the confirm step always shows before a build starts, so you can override anything you disagree with. Every time you override, that too becomes part of what it learns.

Because you bring your own keys and can self-host, the memory LoopCodeLab builds about your work lives with you, next to your code and under your control. See Bring your own keys for how that setup works.