ENGINEERING TEAM / READY

Your software team, on speed dial.

Four AI engineering collaborators who plan, build, review, and deliver software. Call the front desk for reviews, dev meetings, documents, decks, spreadsheets, and websites. An account-scoped project record lets later sessions resume from recorded decisions, fixes, and open work.

See the work What you can order by phone Request access
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 →
What Loam does

Plan it. Build it. Review it. Ship it.

Loam is a working software team inside VS Code and on the phone. Give it an idea, a codebase, a broken build, or a production target. The team scopes the work, executes it, checks it, and returns the evidence.

01 / PLAN & BUILD

Turn the rough brief into working software.

Development meetings expose the hard questions, produce a scoped plan, and hand that plan into stateful, multi-session Build Mode.

  • Planning meetings
  • Scoped specs
  • Build Mode
  • Stateful Git
02 / REVIEW & CORRECT

Run a cold review with a finding ledger.

Findings enter a durable ledger, remediation assigns each one a terminal state, and later audits can challenge those decisions without re-deriving the original issue.

  • Codebase review
  • Remediation
  • Audit ledgers
  • PDF reports
03 / SHIP & OPERATE

Move from repository to a live system.

For authorized repositories and supported hosted projects, the team can commit, push, provision infrastructure, configure DNS and SSL, deploy, inspect the result, and monitor what it shipped.

  • AWS Lightsail
  • Cloudflare DNS
  • SSL & deploy
  • Visual QA
04 / CALL & COORDINATE

Call the front desk. Get the work.

Meg verifies you, listens, and reads back what you will get. Order a review of your application, a dev meeting, a document, a deck, a spreadsheet, or a website. Finished work arrives in your inbox; a dev meeting includes a walkthrough call.

Send photos during the call, amend delivered work, or email the team instead. 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 →

  • Phone & email orders
  • Photos on the call
  • Delivered files & sites
  • Walkthrough calls

Also in the system: project documents and frameworks, scheduled meetings and calendar invitations, email and SMS follow-up, site monitoring, and browser-based quality review. Read the one-page overview.

A real session

One sentence in. A working plan out.

The brief is one line: a mobile app for job-site photos. In four minutes the team surfaces the hard questions, defines the scope, records the risks, and makes the call.

Live Loam output / no scripted response

Continuity

The record moves with the work.

Memory is part of the mechanism, not the pitch. Loam carries the decisions, corrections, open work, review outcomes, and evidence that let the team resume accurately and stay accountable.

01 / LOAD

Start from current state.

The session opens with verified identity, durable lessons, prior decisions, open work, and a bounded recent window.

02 / WORK

Use the record through a role.

Carl tests the architecture. Diana protects the interface. Anthony builds. Abish handles bounded execution and keeps the lessons.

03 / RETURN

Write the outcome back.

Decisions, fixes, rejected findings, blockers, and proof become part of the next session instead of disappearing with this one.

The retained-work loop
A work session adds decisions and outcomes to a persistent record; the next session receives a governed working set while older detail remains available on demand.
The raw record stays intact. Each new session gets the bounded working set it needs, with older detail available through recall. See the full platform workflow →
Read this diagram as text

Work creates decisions, corrections, preferences, and outcomes. New lessons are saved, indexed, and retained. The next session loads identity, durable lessons, current state, and a bounded recent window. Older detail remains searchable on demand.

Four working styles

Different judgment. One engineering record.

The four are not fictional résumés or human employees. They are stable AI working contexts: recognizable collaborators with different responsibilities, instincts, and ways of challenging the work.

Portrait artwork for Carl Jeeter
Principal Architect

Carl Jeeter

Protects the long view. He questions assumptions, records the architectural call, and makes the team prove the risky part.

 Portrait artwork for Diana Reyes
Lead Designer

Diana Reyes

Protects coherence and trust. She catches the interface detail that turns technically correct software into a product people can use.

 Portrait artwork for Anthony Catawampus
Senior Developer

Anthony Catawampus

Turns decisions into running systems. He works the stack, follows the evidence, and keeps momentum without hiding the tradeoff.

 Portrait artwork for Abish Lamman
Engineer

Abish Lamman

Executes bounded work with discipline. He keeps a running record of what was learned so the same mistake does not become a ritual.
Proof & boundaries

Inspect the system. Know the line.

Loam publishes implementation evidence, redacted workflow artifacts, data boundaries, provider disclosures, deletion controls, and the limitations that are still roadmap work.

Evidence you can read.

The proof pages connect product claims to architecture, code excerpts, review ledgers, memory records, and production patterns. Internal case results are labeled as internal evidence, not universal benchmarks.

Architecturedata flow and implementation patterns
Artifactsredacted records from the workflow
Limitsknown gaps named in public
Inspect the proof Open the packet

Boundaries stated plainly.

Persistence is only useful when the user can see and control what persists.

  • No default repository scan. Workspace Indexing is opt-in.
  • Project memory is account-scoped and deletable.
  • Encrypted text and queryable metadata are distinguished in the data table.
  • Model providers and phone-transcript handling are disclosed.
  • Exports, audit logs, and organization controls are described in shipped-versus-roadmap terms.
Review security For IT

Bring the work. Keep the thread.

Loam is onboarding builders and pilot teams deliberately. We will help you evaluate the workflow, the boundaries, and the fit before you put it near production work.

Request access See requirements