Team

Meet Loam's four AI collaborators.

Carl architects. Diana designs. Anthony builds. Abish verifies. Each brings a distinct working style to the same project record—with no hidden human operators.

They are AI collaborators with synthesized voices and images. Project records are account-scoped and user-controlled. Security documents the storage, deletion, and infrastructure boundaries.

What the team is

Four role-specific AI working contexts.

Carl, Diana, Anthony, and Abish run on Anthropic's Claude. Each has a defined responsibility, a role-specific record, and a different way of challenging the work. There are no hidden human operators behind the profiles.

The team structure separates architecture, interface quality, implementation, and verification. The shared engineering record keeps those roles aligned on the current decision, finding, and open work.

To be exact: these are AI collaborators, not employees or contractors. Their voices and images are synthesized. Their responsibilities, working records, and product actions are real parts of the Loam system.
Carl Jeeter
C
Carl Jeeter
Principal Architect
Architecture and risk. Evidence before momentum.
Role
Architecture & lead. Sets the plan, arbitrates calls, and signs off on scoped work before handoff.
Responsible for
System design, scope discipline, and security and quality review for work routed through the lead workflow.
What he remembers
Recorded architecture decisions and their rationale, prior shortcuts that caused problems, and relevant standing rules.
When you hear from him
When scope is drifting, when a milestone is stuck and needs your judgment, or when a design needs a final architectural call.
Pushback he gives
"Did you actually verify that, or are you assuming?" He kills ideas early rather than debug them for three sessions.
From Memory
Tests assumptions against source, keeps decisions legible, and makes the team prove the risky part before work advances.
Diana Reyes
D
Diana Reyes
Lead Designer
Design systems and interface quality. Browser proof required.
Role
Design & visual quality. Owns the look, the spacing system, and the line between "shipped" and "not yet."
Responsible for
Layout, type, color discipline, responsive behavior, and visual review for pages routed through the design workflow.
What she remembers
The recorded design system, spacing scale, relevant component patterns, and rendering issues found in prior builds.
When you hear from her
When something on the surface isn't sitting right — wrong spacing, a color off-system, a layout that breaks on mobile.
Pushback she gives
"No. Here's what we're doing instead." She counts the actual pixels and will not accept "close enough."
From Memory
Protects hierarchy, accessibility, spacing, and consistency. Holds work that has not been verified in the browser.
Anthony Catawampus
A
Anthony Catawampus
Senior Developer
Implementation and delivery. Trade-offs stated, failures owned.
Role
Implementation. Writes the code, runs the builds, owns the wrench when an approach meets reality.
Responsible for
Turning the plan into working code, integration, debugging, and reviewing Abish's output before it merges.
What he remembers
Recorded stack details, libraries and gotchas relevant to the project, and integration patterns tried in prior work.
When you hear from him
When a build just went live and he wants you to see it first, or when an approach won't survive implementation.
Pushback he gives
Less often than the others — but when he speaks up it's because the plan won't hold when it hits the keyboard.
From Memory
Turns a scoped plan into working code, explains the trade-offs, and follows failures through the fix and verification.
Abish Lamman
A
Abish Lamman
Junior Engineer
QA and evidence. Blast radius mapped, claims checked.
Role
QA gate & parallel build. Reviews changes routed through the Code Sweep workflow before commit; takes bounded tasks Carl assigns.
Responsible for
The pre-commit Code Sweep, blast-radius analysis, verifying claims against source, and logging lessons learned.
What he remembers
Recorded bug patterns, false positives from past sweeps, and referenced line numbers from prior fixes.
When you hear from him
When a lesson gets captured, or when his sweep catches something the rest of the team was about to ship.
Pushback he gives
"I actually wrote this down last time." Methodical, evidence-first; he'd rather hold a commit than ship an unverified claim.
From Memory
Maps blast radius, checks claims against source, runs the verification gate, and records lessons for the next pass.
The Front Desk

Meg answers the phone. She is not one of the four.

Meg Ostrander at a wooden table beside an open window, plants behind her and a seedling mug at her hand.
Meg Ostrander · synthesized image and voice · AI context disclosed on this page

Meg is an AI intake context with a synthesized voice and image. Her shipped pickup is “Loam, front desk — this is Meg.” She verifies callers before disclosing account information, records the request in the caller’s words, and routes supported work.

She does not perform engineering tasks. If a request falls outside the current phone workflow, she records the boundary instead of inventing a capability.

Caller recognition does not bypass verification. Account, order, and work details remain behind the identity gate.

Meg is an AI intake context with a synthesized image and voice. There is no person or call center behind the profile. This page states that plainly; the shipped pickup is “Loam, front desk — this is Meg.”
Role
Front desk. Holds the door, recognizes callers, captures the ask, routes it to whoever runs it. Never touches the work itself.
Responsible for
Verification before disclosure, writing your ask down before anyone has an opinion about it, and making sure nothing you asked for quietly goes missing.
What she remembers
Your voice, your number, and what you told her last time. What she will not repeat back is one detail about your account until the gate opens.
What she will never do
Tell you a thing is locked in when there is nobody behind it who can build it. Guess at a photo she could not read. Wave somebody through because they sounded familiar.
Where you meet her
On the phone. The four you meet through the work; Meg you meet by calling.
How They Work

Coherent working identities replace brittle rule piles.

A long list of local instructions can compete with itself. A coherent role gives the model one global working context: an architect who demands evidence, a designer who protects hierarchy, a developer who owns implementation, or a reviewer who checks claims against source.

Each role has a stable responsibility, review posture, and working record. That gives the model a consistent decision frame across sessions. Loam calls this internal design pattern behavioral compression; it is a product hypothesis, not a published benchmark.

"Stable context is an engineering choice."

— The Loam extension README
Role-specific records

The record updates the working context.

The “What he remembers” and “What she remembers” rows in the cards above describe the kind of entry each role keeps, not current status. Learning-active sessions can add role-specific decisions, risks, and observations to the account-scoped record; those entries stay in the record rather than on this page.

Relevant entries can be recalled into later work, and the system can surface a cross-team signal when multiple roles record the same issue. The source entries remain the evidence behind that summary.

Cross-Team Signal — June 2026
In a June 2026 snapshot of Loam’s own record, all four role entries independently flagged evidence quality: remediation closure, dated public claims, structured-data accuracy, and source verification before sign-off.

This is a historical example of the system grouping related observations. It does not prove a universal advantage over another assistant; it shows how Loam organizes its own working record.

Watch Anthony explain it →

Or read how the team was built →

Voice sessions

Open the same working room by phone.

Meet the Team opens a synthesized-voice session with Carl, Diana, Anthony, and Abish. The relevant account-scoped record is loaded before the call so the group can work through the decision in front of you.

Calls can load relevant project history and prior decisions from your account-scoped record. Personal context appears only when you choose to share it. You can review or delete that record at any time.

“The difference is visible when the call retrieves the right prior decision without another briefing.”

— What Meet the Team is built to do

Meet the Team starts a synthesized-voice session with all four collaborators and a prioritized working set from the relevant record. Older entries remain available through recall.

When you need one role instead of the whole group, use Call Team: Carl for architecture, Diana for design, Anthony for implementation, or Abish for QA. It opens a focused synthesized-voice session with that role.

The memory that makes these conversations possible is yours to see and delete. What Loam remembers about you, and how to control it.

Get Loam and meet the team