The Proof

How Loam records, reviews, and verifies delivery.

Trace each major claim to a running behavior, an implementation guarantee, a dated artifact, and the boundary where the evidence stops.

The short version

Three claims. The receipts are below.

Before the diagrams and the code: here is what Loam actually does, in one line each. Skip to any section for the implementation behind it.

Claim 01

Selected records persist.

Learning-active sessions can add selected, source-tagged decisions, corrections, findings, and open work to the account-scoped record. Later sessions receive a prioritized working set; older entries remain available through recall.

Claim 02

Review retains prior findings.

Code Review can write findings and anchors to a ledger. In Loam’s dated internal case, later passes read the existing ledger and did not re-derive the original findings; results vary with the delta and review scope.

Claim 03

Build Mode performs real work.

Build Mode dispatches a milestone as an isolated subagent, runs it against your real files, and chains to the next on completion — or calls your phone when it hits a blocker.

Architecture

The Memory Pipeline

Learning-active sessions can add selected decisions, corrections, and open work to the account-scoped record for later recall.

Not all synthesis is the same job
Split-lane storyboard comparing memory consolidation, which turns older indexed items into era summaries and durable lessons, with identity synthesis, which reads the raw lived record to produce a session reflection and a public portrait.
Memory consolidation keeps normal work usable over time. Identity synthesis separately reads the raw lived record and produces verified identity artifacts. Two lanes, two jobs, two different guarantees — and neither deletes the source record.
Open the full-size storyboard →
Read this storyboard as text

Lane one — memory consolidation. Older indexed items become era summaries and durable lessons so ordinary sessions stay efficient. The source rows are retained, not replaced.

Lane two — identity synthesis. A separate deep read of the raw lived record produces a compact session reflection and a longer public portrait.

Why they are kept apart. Consolidation is about staying usable. Identity synthesis is about staying honest. Collapsing them into one 'synthesis' would let a summary of a summary become the team's self-description.

Coverage is the other half. Splitting the work into two lanes only helps if the lane that produces identity can prove it read everything it claimed to read.

How coverage is proven
Storyboard: a pinned archive roster divided into bounded read groups, coverage receipts adding back to the complete record, and an independent fidelity check rejecting identity claims the record does not support.
The record is pinned before the read, divided into bounded groups, and accounted for with coverage receipts. Claims must join back to raw entries and survive an independent attempt to disprove them — and a failed verification leaves the previous verified identity in place. Read the whole story →
Open the full-size storyboard →
Read this storyboard as text

Pin, then read. The input set is fixed to a cutoff and every raw entry is identified before anything is read.

Partition in code. The roster is divided into bounded groups by code, not by the model.

Require receipts. Each group accounts for the entries it was handed, and the totals must reconcile to the pinned roster or the read runs again.

Cite and verify. Every factual claim cites raw entries. An independent cold reader tries to refute them. One correction cycle is allowed.

Fail closed. An unsupported portrait is rejected and the last verified reflection stays live.

Session IDE or web session generates conversation turns
Extraction Preferences, decisions, and knowledge isolated per team member
Memory Persistent per-member storage with timestamped sessions
Enforcement Relevant account preferences can enter the prioritized session working set
Compression AI-driven reduction preserving critical details and preferences
Recall Prioritized working set assembled per session; older detail on demand

Call Pipeline

Voice callbacks with dynamic context generation. The team calls your phone with session-aware openers — not scripts.

context_service event_service ide_integration onboarding_service

Build Mode

Autonomous multi-milestone project execution. Subagent-per-milestone dispatch with fresh context windows.

project_service advance_milestone orchestrator session_cap

Document Engine

Professional output generation — SOWs, SOPs, frameworks. Template-driven with brand injection.

sow_builder sop_builder framework_gen
Real Code

Production Patterns

Trimmed excerpts from the running code, checked against source on 2026‑09‑13. Paths are relative to backend/.

services/persona_memory_service.py Memory
# Learning-active sessions can append selected entries
# with timestamped source tracking

timestamp = datetime.now(timezone.utc)
separator = f"\n\n--- {source} ({timestamp}) ---\n"

if memory:
    existing = memory.content.strip()
    memory.content = existing + separator + new_content
    memory.updated_at = datetime.now(timezone.utc)
else:
    memory = PersonaMemory(
        user_id=user_id,
        persona_key=persona_key,
        content=new_content,
    )
Memory grows per session, per team member. Each append is timestamped and source-tagged — the system knows where every piece of knowledge came from.
services/call_pipeline/context_service.py Pipeline
# Call context adapts to WHY the call is happening

def get_trigger_context(trigger_type, call_topic=None):
    if trigger_type == "manual":
        if call_topic:
            return (
                f'The user asked you to call about '
                f'a SPECIFIC topic: "{call_topic}". '
                'Lead with the topic.'
            )
    elif trigger_type == "team_blocked":
        return "The team is working on a milestone..."
Each trigger type shapes how the team member opens the call — from "you requested this" to "the build hit a blocker." Context-aware, not scripted.
services/persona_memory_service.py Compression
# Pinned rules are lifted out before the model sees the memory
must_enforce_lines_all = [
    line.rstrip() for line in memory.content.splitlines() if "MUST-ENFORCE" in line
]
# A repeated rule is kept once (case and trailing .!? ignored)
for line in must_enforce_lines_all:
    normalized = line.strip().lower().rstrip(".!?")
    if normalized not in seen_me:
        seen_me.add(normalized)
        must_enforce_lines_deduped.append(line)

# ... the model compresses everything else ...

# Drop any marked line the model wrote; append the originals verbatim
narrative_lines = [
    line for line in compressed_text.splitlines() if "MUST-ENFORCE" not in line
]
compressed_text = "\n".join(narrative_lines).rstrip()
if must_enforce_lines_deduped:
    compressed_text += "\n\n--- HARD RULES ---\n" + "\n".join(must_enforce_lines_deduped)

# Abandon the write if the memory changed while the model worked
await db.refresh(memory)
if memory.updated_at != snapshot_updated_at:
    return False
Pinned rules survive by construction, not by a count check: every line marked MUST-ENFORCE comes back word for word. That covers marked lines only. A lesson that was never marked, or the second line of a rule, is compressed like any other text.
routes/ide/build_mode.py Build Mode
# Trimmed: the milestone-advance endpoint

async def ide_advance_milestone(body, db):
    if body.status == "blocked":
        project.build_mode_paused = True
        await initiate_reachout_call(persona_key="carl", trigger_type="build_mode_blocked", ...)
        return {"action": "paused"}

    # "complete": sign off, then push to GitHub if a repo is linked
    spawn_background_task(_auto_push_to_github(project_uuid, job.id, user.id))
    if _cap_count >= SESSION_CAP_DEFAULT:
        project.build_mode_paused = True
        return {"action": "session_cap"}
    next_milestone = await kick_off_milestone(db, project_uuid, job.id)
    return {"action": "continue", "milestone_instructions": instructions}
After you start a plan, Build Mode advances milestones until a blocker or the session cap pauses the run. A blocker triggers a call. A completed milestone also starts the push to GitHub when a repository is linked.
Dated internal snapshot

System Metrics

These are historical internal counts, not customer benchmarks or current totals. Each names the source used at the snapshot date.

1,100+
Automated Tests
Automated test count at the June 2026 snapshot
73K+
Chars of Memory
Largest team member's persistent knowledge base
2,600+
Commits Shipped
Git commits in the repository at the June 2026 snapshot

Snapshot verified: June 2026 · Sources: git history, pytest suite, production memory store, release ledger.

Architecture

The Request Path

From the VS Code sidebar to Loam and back — the request path used by supported sessions, reviews, and calls.

Your machine
VS Code extension
The Loam sidebar — sessions, Build Mode, Code Review, calls
MCP server / Claude Code
Runs in user space with the developer’s configured Anthropic account for supported editor workflows
HTTPS 443 · outbound
Loam · AWS us-east-1
Session orchestration
Routes each turn; loads the right specialist and context
Memory · project context · review ledger
Per-specialist record, field-encrypted at rest; selected context is loaded for learning-active sessions
server-side · selected workflows
External providers
Anthropic Claude API
Provider account depends on the editor workflow and trial state
Gemini
Build Mode image generation — Loam-managed key, server-side
Voice synthesis
Text-to-speech for team phone calls
 …and back to your sidebar — results, review findings, and the team’s memory of the session.
Stack

What Powers Each Layer

Backend
Python 3.12 FastAPI SQLAlchemy asyncpg Alembic
Frontend
React 19.2.4 Vite Lucide Icons
Database
PostgreSQL 16 Fernet Encryption Async Sessions
AI Layer
Anthropic Claude Workflow-specific context Streaming SSE Tool Execution
IDE
VS Code Extension MCP Server Session State Build Mode UI
Infrastructure
AWS Lightsail nginx systemd
How to verify

Claim, evidence, and the honest limit.

For the three big claims: what we assert, where to confirm it, and where the line sits. We'd rather hand you the limit than have you find it yourself.

“Memory is persistent and carries across sessions.”
Evidence Learning-active sessions can append timestamped, source-tagged decisions and lessons to an account-scoped record; relevant entries can be recalled later. Pattern shown above from persona_memory_service.py.
Limit Memory is per-account and isolated — there is no shared or organizational memory today. The lookup metadata recall searches against (names, keyword tags, short summaries) stays in plaintext so search works; the conversation content itself is field-encrypted at rest.
See it Ask any team member on a later session what you decided last time, then delete that memory and ask again. The Security page documents exactly what is stored and what is plaintext.
“Review improves over time, not just per-run.”
Evidence Code Review writes findings and anchors to a persistent review ledger that is recalled on the next pass. Compression keeps every line marked MUST-ENFORCE word for word and appends it after the compressed text — pattern shown above.
Limit “Improves” means the team carries prior findings forward and converges on a hardened tree — it is not a formal accuracy benchmark. Review still runs on what you share in a session, not an automatic scan of your whole repo.
See it Run a review pass, fix the findings, and run it again on the same tree. The second pass should reference the first and return a shorter list, not repeat it.
“Build Mode executes scoped milestone work.”
Evidence The Build Mode orchestrator hands milestone work to subagents (services/templates/build.py). The endpoint shown above, from routes/ide/build_mode.py, chains to the next milestone on completion and pauses and calls your phone on a blocker.
Limit Build Mode reads the files a requested milestone needs and is user-initiated — it does not run on its own or touch files outside the work you start. Image generation, when enabled, goes to Gemini server-side with a Loam-managed provider key. When a GitHub repository is linked, each completed milestone pushes to its main branch without another prompt — see what starting Build Mode authorizes.
See it Start a Build Mode project and watch the milestones advance in the sidebar; force a blocker and confirm the call comes through. The For IT page lays out exactly what leaves the machine.
Verify

Trace the Architecture

Every pattern mentioned on this page has a real implementation. Here's where to look.

Orchestrator Facade Pattern

When a 4,000-line module splits into six, every consumer keeps working. The facade re-exports the public API. Zero breaking changes across 11 import sites.

call_pipeline/__init__.py → 6 submodules

Memory Compression Engine

AI-driven compression that lifts every MUST-ENFORCE line out first and appends it back word for word. The original is kept if the model returns nothing or the memory changed during the run.

persona_memory_service.py → compress_persona_memory()

Build Mode Dispatch

The orchestrator hands milestone work to subagents and chains completion calls — when one milestone finishes, the next begins until a blocker or the session cap pauses the run.

routes/ide/build_mode.py → ide_advance_milestone()

POST-EXTRACTION RULE

After any component extraction, every JSX identifier is grep-verified against the import list. Three extraction bugs taught this rule. It's now enforced on every split.

Enforced across all frontend decompositions

Inspect the architecture, dated evidence, and stated limits—then decide whether the delivery system fits your work.

Meet the Team →