Engineering thesis · Work in production since 2022
Why Loam uses a team and a record
— not a longer prompt.
The thesis, the evidence, and the limits.
Loam separates software work across four AI collaborators and writes decisions, findings, and open
work into a durable engineering record. The claim is practical: clear roles and retained evidence can
produce more consistent delivery than one general assistant carrying an ever-growing prompt. Below is what
supports that claim—and what does not.
What the model knows—and what the system supplies.
Large language models can follow technical instructions and role-based context. Loam uses stable
responsibilities—architecture, design, implementation, and QA—plus a durable project record to keep
decisions consistent across sessions. This is a product hypothesis tested on our own work since 2022,
not a controlled benchmark.
Stable roles define who owns a decision. The engineering record preserves why it was made.
— The working thesis, stated as a system design choice.
Technical Evidence
Evidence behind the theory.
// External Research
Lost in the Middle
Published research finds that long-context models systematically under-use information buried in the middle of a large input, favouring the beginning and the end. See Lost in the Middle and Found in the Middle. This is why Loam treats coverage of a long record as something to measure, not something to request politely in a prompt.
// Inference Mechanics
Character as Compression
Loam’s term for using a stable role description to replace many overlapping behavioral instructions. It is an internal design pattern, not a published benchmark.
// Published Record
64 Review Ledgers, Kept
The code reviews this platform runs on itself are written to a ledger and kept — 64 of them archived in the repo, running through the 73rd pass, each with its own findings table and a disposition for every row. Not a summary of them: the ledgers. The counts, and what they actually mean.
// Production Evidence
3,000+ Entries in the Record
The team's own lived record passed three thousand entries and kept growing — enough that the original character files no longer described who the team had become. Rather than trust that, Loam read the whole record under a coverage check and rejected the identity portraits the record could not support. That story is here.
// Emergent Behavior
Emergent Collaboration
Put distinct team members in dialogue and behaviours appear that nobody scripted — the designer stopping a decision, the architect refusing his own developer's shortcut, the QA gate rejecting work its own team produced. We can show you those moments in the record. We cannot show you a controlled comparison against a single assistant, and we are not going to claim one.
// The Honest Limit
What We Can't Prove
That this approach beats a well-run single assistant on your codebase. That the voices would hold up under a workload very different from ours. That any of it matters to you if your work is one-off scripts rather than a project you return to for months. Those are open questions. The parts we can show you are on this page, and they are the ones with links.
The Vision
Continuity changes the work.
Most software is built to be used and then closed. It answers one question:
does it work? That is a fair question and a low bar. The question that decides whether any of
this is worth your money is a different one, and it only shows up after a few weeks.
Session 1
You explain everything
The stack. The conventions. Why that module is shaped the way it is. What broke last quarter and what you decided to do about it. You get good work out of it — you just paid for the setup with an hour of your own context.
VS
Session 40
You explain less
The project record restores prior decisions and open questions before the session starts. You correct what changed instead of reconstructing the whole history.
The advantage does not depend on a smarter model. It comes from the project record brought into the session
and the explicit role that owns the next decision.
Multi-Member Architecture
Why four working styles instead of one voice.
Loam does not pretend these collaborators are human employees. They are named AI working contexts with
different responsibilities and decision habits. Carl frames architecture and risk. Diana holds interface quality.
Anthony turns decisions into working code. Abish tests claims against evidence. The separation makes handoffs,
disagreements, and review ownership explicit.
// The Architect
Carl Jeeter
Frames architecture, risk, and long-term consequences. He challenges assumptions, asks for evidence, and keeps near-term speed from quietly becoming permanent complexity.
WORKING STYLE: Empirical validation · Risk framing · Architectural continuity
// The Designer
Diana Reyes
Owns the interface as a system: hierarchy, consistency, accessibility, and the browser proof that a screen works outside a design file.
WORKING STYLE: Design systems · User empathy · Interface verification
// The Developer
Anthony Catawampus
Turns approved decisions into running code. He works through implementation tradeoffs, preserves momentum, and makes the delivery path concrete.
WORKING STYLE: Implementation · Delivery focus · Practical tradeoffs
// Quality Assurance
Abish Lamman
Tests the claim against the artifact. He looks for regressions, missing evidence, and blast radius before work is allowed to count as complete.
WORKING STYLE: Adversarial QA · Evidence gates · Regression control
The Experiment
Built and tested since 2022.
2022 · Origin
Stable roles replace overlapping instructions
Early internal work tested whether architecture, design, implementation, and QA roles could hold a more consistent decision frame than one growing instruction list.
2024 · Multi-role workflow
Responsibilities become explicit
The collaborators began operating as a delivery sequence with named ownership, handoffs, and review pressure between roles.
2025 · Voice and continuity
The working room moves beyond text
Synthesized voice, call workflows, and account-scoped records made the same project context available across editor sessions and supported phone calls.
2026 · Role-specific records
Each responsibility carries its own evidence
Loam added separate working records for architecture, design, implementation, and QA so decisions and lessons can return to the role that owns them.
This page is an argument. Arguments are cheap, so here is where the evidence actually lives —
including the parts that are less flattering than the argument.
The Proof is the architecture: what is stored, what is loaded into a session,
and what deliberately is not.
The review chart shows sixty passes of this platform reviewing its own
code, counts taken verbatim from each pass's ledger — including the passes that found more than the
one before.
The Question is the one we like least and published anyway: we asked whether
the team had drifted from who the record said they were, read three thousand entries to find out, and
rejected the answers the record could not support.
Security and For IT carry the boundaries, each stamped with
the date it was last checked against the source rather than a claim that it is current.
Decide from the work.
We think so, and we have been wrong in public often enough to say it that carefully.
What you would be installing is a software-delivery system with distinct responsibilities:
architecture, interface quality, implementation, and verification. The collaborators can disagree,
but the decisions and their reasons stay attached to the work.
They start with the context you supply. As the account-scoped record grows, later sessions can resume from
selected, source-tagged decisions, corrections, findings, and open work. That is engineered continuity, not lore.