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 goes into an isolated sandbox, is reviewed read-only, and the working copy is removed when the review finishes, fails, or is cancelled. We don't keep a copy of your codebase — we keep the review, which quotes the lines it cites. Review reports remain scoped to your account. Individual work-order deletion is not currently available as a self-service control, and account deletion does not yet remove delivered report files. What Reception keeps.
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.
Build Mode advances the milestones in the plan you start, records commits and QA results, and pauses at blockers or configured gates. You write or approve the plan. Starting Build Mode authorizes the run to work on its own, including a push to your linked repository’s main branch after each completed milestone. See what starting Build Mode authorizes.
What starting Build Mode authorizes
Approval happens up front. Once these conditions are in place, Build Mode does not ask again before each action.
| Action | What turns it on | Asks again each time? | What stops it |
|---|---|---|---|
| Commit | Build Mode runs inside Claude Code in your editor, under your Claude Code permission settings. Loam’s Supervised trust mode adds Loam’s own tools and git, npm, npx, and node commands to the project’s allow list. | Not for git commands in Supervised mode. Otherwise, as your Claude Code settings decide. | Stopping the session, or removing git commands from the project’s Claude Code allow list. |
| Push | A GitHub repository linked to the project, with GitHub connected. After each completed milestone, Loam commits the project files it has stored to that repository’s main branch. It does not open a pull request. | No | Turning Build Mode off: the milestone in progress finishes, and nothing after it runs or pushes. A blocker or the session cap also stops the run. Disconnecting GitHub stops pushes entirely. |
| Provisioning | A Loam administrator. Customer accounts cannot provision servers today. | Not applicable | Not available to customer accounts. |
| Deployment | A Loam administrator sets up a hosted server from a repository branch. That server checks the branch about once a minute and deploys new commits. | No, once the server is set up | Tearing down the server. A server set up from a different branch is not affected by Build Mode pushes. |
Put together: if a hosted server deploys from the same main branch, a completed milestone can go live without another prompt. Decide that before you link the repository.
AWS instance, DNS, SSL certificate, live URL.
Loam administrators can provision an AWS Lightsail instance, static IP, firewall, Cloudflare DNS, and an SSL certificate, then return the live URL. Customer accounts cannot start provisioning themselves today. 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.