The team's greenhouse at dusk — tomato rows under Edison lights, a picnic table with a laptop, speakerphone, and four coffee mugs.
Product

How Loam delivers
software work.

A scoped plan moves through implementation, review, verification, and handoff. The engineering record updates at each step.

Loam 5.5.0

Your team, in one place.

Open Loam beside your editor and the whole project is there: the four people you work with, the session you are in, the plan you are building against, and what the team remembers. Start a session, follow a build, read a member’s story, make a call.

The implemented Loam 5.5.0 workspace: project overview, team cards, Build Mode, account memory, session details, and server telemetry. Unconnected readings show Unavailable.
The 5.5.0 workspace, captured before an account was connected. Readings that have nothing to report say Unavailable. Open the full-size image.

The work has a place.

Start a session. Follow the plan in Build Mode. Reviews, debugging, recordings and settings are each a page away instead of a stack of panels.

The team is in the room.

Read a member’s story, see how the week has gone for them, email or call any of them, or Call the Shop for the whole team at once.

Nothing on the screen is invented.

States come from the notes each member wrote. Counts come from your record. Server readings say when they were taken. Anything not reported says Unavailable.

See setup and optional collaboration →
The Walkthrough
31:57

Thirty-two minutes. Every button.

Historical walkthrough, recorded before 5.5.0. This 32-minute tour shows the earlier sidebar layout, a development meeting, memory, review, and Build Mode. Use the workspace and setup guide above for the current controls. Anthony is a synthesized presenter and the implementation-role voice in Loam. Jump to any chapter below, or read the full transcript.

About this walkthrough

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 →

Memory

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 →

architecture
└ Postgres over MongoDB — your call, Apr 3.
└ Reason: existing team knows SQL cold.
preferences
└ No mocks in integration tests.
└ Carl sweeps before every commit.
last_session
└ Left mid-milestone. Auth route open.
▲ loaded into next session automatically
What a session actually loads
Storyboard: the ordered context layers assembled for a session — role contract, verified reflection, working memory of hard lessons and open work, a recent lived-history window governed by a Dial, and team signals, with older detail available on demand.
Loam does not pour the archive into every prompt. A session receives a prioritized working set — role contract, verified identity, indexed decisions and hard lessons, open work, and a Dial-governed recent window. Older indexed detail remains available through recall. Inspect the architecture →
Open the full-size storyboard →
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.

Reception

Call the front desk. Get the work.

Meg verifies you, takes the request in your words, and reads back what you will get. Order documents and research, decks, spreadsheets, email drafts, calendar files, web pages, websites, a review of your application, a dev meeting, or a callback.

Finished work arrives in your inbox. A dev meeting brings a verdict, scope, plan, and a walkthrough call at the time you name. Send photos while you talk, call back with an amendment, or email the same team from your registered address.

A review stays read-only. After you authorize access through the GitHub App and register your project, the team reviews one isolated snapshot and removes the working copy. You keep the report, including the lines it cites. Stored reports, photos, and order text are encrypted; phone transcripts are stored in plaintext. Individual order deletion is not self-service today; account deletion removes its reports and intake records. Read the storage and deletion details.

Small repairs by phone are available: a verified caller confirms one bounded change to a registered project, Loam saves it, and the project’s own pipeline publishes it. Saved and live are reported separately.

See what you can order and what arrives →

reception · a review of your application
└ You authorize — GitHub App, read-only.
└ Sealed snapshot — one point-in-time copy.
└ Reviewed in isolation — never written back.
└ Report delivered — verdict + the exact lines.
▲ working copy removed — the review is what stays
Code Review

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.

Run Code Review
Read-only. Reads prior ledgers and code anchors before flagging anything.
Remediate
Fix or anchor every finding. No deferrals. No skipped rows.
Audit
Interrogates past decisions adversarially. Good calls survive. Wrong ones get reopened.
Remediate Audit Findings
Closes what the audit reopened. Strips stale rejection anchors.
~110 findings in one cold whole-repository review. In sixty archived internal passes, the original findings were not re-derived.
The proof, in one number

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.

First pass — no memory
~110findings, whole repo
all driven to terminal
60th pass — full ledger
11findings in 13,488 changed lines
all driven to terminal, 0 left open
Findings per review pass — verbatim from each pass's own ledger
110
1st
9
53rd
4
54th
2
55th
6
56th
0
57th
12
58th
9
59th
11
60th
First cold pass Delta pass — only what changed Most recent pass

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.

Build Mode

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.

M1 Homepage rebuilt — QA passed, committed, deployed.
M2 Get Started — install safety verified, shipped.
M3 Trust pages — every claim checked against source.
M4 Depth pages — in progress, gated on QA.
M5 Brand & ship — queued, plan approved.

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. The Loam extension adds Loam’s own tools and git, npm, npx, and node commands to the project’s allow list. Not for git commands, unless the project’s Claude Code settings have an ask rule for them. Otherwise, as your Claude Code settings decide. Stopping the session, or a deny rule for git commands in the project’s Claude Code settings. The extension adds its allow rules back at each session start, so deleting them does not last; ask and deny rules override them.
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.

Infrastructure

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.

AWS Lightsail instance created
Static IP allocated & attached
Ports opened, firewall configured
Cloudflare DNS record created
SSL certificate issued & verified
Live URL returned after provisioning and health checks complete.
Four role-specific AI collaborators

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.

Carl Architecture and risk. Challenges assumptions and records tradeoffs.
Diana Design systems, accessibility, and interface verification.
Anthony Implementation, delivery, and practical tradeoffs.
Abish QA, source verification, and regression control.
A Loam session running in the VS Code sidebar during a Saturday Night cron debug.

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 hello

info@loam.team — we respond personally.