How Loam delivers
software work.
A scoped plan moves through implementation, review, verification, and handoff. The engineering record updates at each step.
Thirty-two minutes. Every button.
This 32-minute walkthrough covers setup, sidebar controls, a development meeting, memory, review, and Build Mode. Anthony is a synthesized presenter and the implementation-role voice in Loam. 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 →
Relevant decisions return with the work.
Learning-active sessions can store selected decisions, corrections, preferences, and open work in an account-scoped record. Later sessions load a prioritized working set and can recall older entries on demand. You can review or delete the record.
The record is account-scoped rather than folder-scoped, so relevant context can be available across workspaces signed into the same account. It does not cross into another customer account.
See how the memory actually works — watch Anthony explain it →
Read this storyboard as text
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. Older indexed entries remain available through recall rather than being loaded by default.
Request supported work by phone.
Reception verifies the caller, captures the request in plain language, and routes supported work. Available now: read-only codebase review, question research, and document generation. Phone-ordered debugging and code changes are planned.
And we show our work on your code. We touch a repository only after you authorize it — a GitHub App you install, a project you register, a short-lived read-only credential. One sealed snapshot into an isolated sandbox, reviewed read-only, and the working copy is destroyed after every review: on success, on failure, on interruption. We don't keep a copy of your codebase — we keep the review, and you can delete it anytime.
Planned, not shipped: phone-ordered debugging and code changes. Available now: codebase review, question research, and document generation by phone.
Review decisions stay in the ledger.
Each pass reads prior findings and recorded dispositions before reporting new or reopened issues. Findings reach a terminal state—fixed, accepted with a recorded reason, or reopened when later evidence challenges the decision.
You start the review and choose which fixes to apply. Loam records the findings and dispositions. Nothing is auto-committed by the review itself.
A review ledger keeps settled findings attached to later work.
In one dated internal case, the first cold review surfaced around 110 findings across roughly 150,000 lines and assigned each a terminal disposition: fixed, or deliberately kept with a reason on record. Later archived passes read that ledger before reviewing the new delta, and the original findings were not re-derived. Later pass counts vary with the code delta and review scope; they are not an accuracy benchmark.
all driven to terminal
all driven to terminal, 0 left open
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/archive/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 pass charted here 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.
Approve a milestone plan; Loam works the queue on a branch.
Build Mode advances approved milestones, records commits and QA results, and pauses at blockers or configured gates. You define and approve the plan, retain control of merge and deployment, and can inspect the branch before anything is promoted.
AWS instance, DNS, SSL certificate, live URL.
The team can provision an AWS Lightsail instance, static IP, firewall, Cloudflare DNS, and an SSL certificate, then return the live URL. Current hosted model: Loam-managed AWS and Cloudflare. Bring-your-own cloud is planned and is not available today.
See Security for cloud ownership, credential handling, and deletion boundaries.
Architecture, interface quality, implementation, and verification.
Carl frames architecture and risk. Diana reviews interface quality. Anthony implements. Abish verifies evidence and blast radius. Each role uses the project record relevant to its work.
You can also open a synthesized-voice session with all four collaborators or call one role directly. Relevant project context is prepared before the call. 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
Curious?
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 helloinfo@loam.team — we respond personally.