Most AI tools reset every session. Loam is a persistent development team — four members with memory, opinions, and the ability to build real things while you're not there.
Anthony built most of what's in the sidebar, so he gives the tour — who the team is, how a session starts, what every control does, and which ones to leave alone. Then he runs a real dev meeting end to end, and closes on why a team that remembers beats a smarter tool. Jump to any chapter below, or read the full transcript.
Written and narrated by Anthony; the voice and likeness are synthesized. He covers how that works at 3:54.
Prefer to read? Read the full transcript of the walkthrough →
Sessions append what they learned to the record, and what's worth finding again gets indexed for recall. Hard preferences and protected lessons get priority in the working set every new session starts from. Important mistakes are logged so they don't become recurring failure patterns. The context that disappears every time you open a new chat window? It persists here until you delete it. The team knows your stack, your standards, and the argument you had about the database schema in March.
And it isn't scoped to the folder you're sitting in. Memory is scoped to you — so a session in one repo can answer a question about the project on the laptop behind you, without you naming which project you mean. Same team, every workspace you sign into.
See how the memory actually works — watch Anthony explain it →
1 · Contract. The constitutional floor for each team member. Never compressed or rewritten.
2 · Verified reflection. Who the record shows the team has become — live only after passing the fidelity check.
3 · Working memory. Hard lessons, current snapshots, open work, and recent context.
4 · The Dial. How much recent lived history is carried in. Light, Standard, Deep, or Full — a depth and cost control, not a switch that turns the record on or off.
5 · Recall. Everything older stays searchable on demand rather than being loaded by default.
Most AI code review is a treadmill — the same findings on every pass because the reviewer has no memory of what was already settled. Loam's review reads its own history before flagging anything, drives every finding to a terminal state instead of skimming the top, and audits its own past judgments to make sure they still hold. Four buttons in the sidebar. Nothing already settled gets found twice.
You click Run Code Review. Loam reads its own ledger history, flags only what's genuinely new, and writes every finding to a durable ledger. You stay in control — nothing is auto-committed; you decide what gets fixed and what gets kept on the record with a reason.
The first time the team reviewed this codebase cold — no ledger, no history — it surfaced around 110 findings across roughly 150,000 lines and drove every single one to a terminal state: fixed, or deliberately kept with a reason on record. From then on, each review reads that ledger before it flags anything. It does not re-derive a settled problem; it looks at the code that actually changed. So what a pass finds now is a measure of how much was written since the last one — not a measure of how much is wrong.
Every bar is a real entry in the review history, and we are showing you the recent ones rather than the flattering ones. The tall bar on the left is what a reviewer sees when it has no idea what was already settled. The bars after it do not trend to zero, and they are not supposed to. They rise and fall with how much new code each pass had to read — the 58th and 60th were the two largest deltas this project has ever shipped. What stays constant is the other column: every finding driven to a terminal state, and none of the original 110 ever found again.
Source: the team's own archived review ledgers (docs/review_history/) — first whole-repo pass 2026-05-23 (~110 findings across ~150 KLOC: 95 fixed, 7 rejected-by-design with an anchor comment, 8 sent to the architecture backlog, 0 deferrals); most recent archived pass the 60th, 2026-07-20 (11 findings across a 97-file, +13,488/−1,084 delta, all terminal, 0 remaining). Counts above are verbatim from each pass's own summary table.
Build Mode runs the team through a project one milestone at a time, on its own — plan, build, QA gate, commit, deploy, document, repeat. You define the milestones and approve the plan. Loam works the queue with the same memory and the same review loop it uses when you're watching, logging every turn so the next session knows exactly where it stopped. You keep the controls: it works on a branch, commits are yours to read, and nothing reaches production without passing the gate first.
One command and the team stands up real infrastructure — an AWS Lightsail instance, static IP, firewall, Cloudflare DNS, and an SSL certificate — then hands back a live URL. Under three minutes. No tickets. No ops team. Today it runs on Loam's cloud, billed in good faith as the AWS line in your plan. Bring-your-own AWS and Cloudflare API keys are planned for September 2026 — move it all onto your own accounts whenever you're ready.
See Security for cloud ownership, credential handling, and deletion boundaries.
Carl reviews every line of code before it ships. Diana counts pixels. Anthony builds fast and stays up too late. Abish keeps a journal. Each one is a persistent behavioral context — domain expertise, working style, and memory compressed into a model that activates the same way, every session. Not a one-off role prompt. A development context that compounds.
And you don't only read their output — you can call them. One click in the sidebar and the team is on the line with your project already loaded. Meet the team · how the calls work.
Real session — Saturday Night cron debug — recorded 2026-04-26
Security and For IT explain exactly what code, credentials, and project context are sent, stored, and deleted. Security — For IT
We are taking on a small number of new projects. If something on this page made you want to know more, that is the right instinct.
Say hello[email protected] — we respond personally.