lemma-platform turns a coding agent's output into a shared team system

A harness for a team, not for a session

The README defines a harness as everything around the model: the tools it can call, the memory it reads, the state it writes, the loop it runs in, and the boundary it works inside. The comparison it draws is with coding agents, which give you a harness for one person, on one machine, for the length of one session.

Lemma is that same harness for a team. The difference is stated in three properties. State is shared and permissioned, so many people and many agents work the same records rather than each having a private copy. It keeps running between sessions, triggered by schedules, webhooks and table events, which is what lets agents work while everyone is logged off. And it compounds: corrections become standing instructions, sequences become workflows, and judgment becomes an agent role.

That last claim is the ambitious part. The argument is that the harness a team uses next month is better than the one shipped today, because using it is what improved it, with lessons from real corrections written back into the files the agents read.

The coding agent writes the files, the CLI imports them

The build step is delegated to whichever coding agent you already use: Claude Code, Codex, Cursor, OpenCode or Antigravity, or Lemma itself. You describe the job and the agent writes the whole system as files, which the README enumerates as the app people open, the tables underneath it, the agents, the workflows and the permissions.

Those files are then imported and verified through the same CLI that runs the system. The starter path makes the loop concrete:

lemma pod create support-ops --with-starter   # scaffolds a working starter (table + agent) and imports it
lemma chat "what can you do in this pod?"

So a pod begins as a generated directory, `support-ops/`, which you open in your coding agent and describe the system you want inside. Nothing about that is a proprietary editor, and nothing about it requires the agent to have network access to the running pod while it writes.

After import, the same pod is reachable at a URL for teammates, or from Slack, Teams, Telegram, WhatsApp or email. The app and its agents go live together, and every entry point reads and writes the same records under the same permissions rather than having its own copy.

Six primitives, and functions are the predictable half

Everything lives in a pod, described as a self-contained environment for one person, team or process that holds shared state, agents, workflows, permissions and one or more apps. Inside it there are six primitives.

Tables are typed, queryable business data with row-level security, holding leads, tickets, tasks and approvals, readable by agents and owned by the pod. Agents are LLM workers with a role, tool grants and access scoped to specific tables, files and connectors. Workflows are graphs mixing agents, functions, decisions, loops, waits and human approval steps, triggered by schedules, webhooks, table events, chat or the API.

Functions are the deliberate counterweight. They are described as the predictable half, same input and same output every time, written as plain code for validators, state transitions and outbound actions, and called by agents as tools so that judgment and rules stay separable.

That split is the design decision worth understanding. An agent that guesses is fine for triage and wrong for a refund, so the predictable part is pushed into code and the model is left the part that needs judgment.

Files hold policy because agents read them at run time

The Files primitive is markdown memory for preferences, playbooks, voice guides and notes. It is full-text searchable and permission-scoped, and agents read and write it alongside the tables rather than in a separate memory system.

What makes it more than notes is the stated role: this is where policy lives, versioned, editable, and read at run time. So a correction given once can be written into a playbook file that the next agent reads before it acts, which is the mechanism behind the claim that corrections become standing instructions.

Because it is editable text and version controlled with the rest of the repository, changing an agent's behaviour does not require redeploying anything, and reviewing a behaviour change is a pull request on a markdown file. Nothing in the visible text describes a limit on file size, a conflict rule when two agents edit the same file, or a version pinning mechanism, and those are the gaps to check before you put a policy there.

Three principals, one system, different rights

The permission model is shown with a small example rather than described abstractly. An owner named Priya approves refunds of any amount. A member named Marco sees his own jobs, and refunds route to Priya. An agent named Classifier reads tickets and is read-only.

Same system, different rights, and one version of it for everyone. The share model is what makes that possible: you share the agent itself, already running, so sending someone a link means they open the same agent and their work lands in the same records. There is one of it to fix, one of it to improve and one set of records underneath.

The wider permission description adds per-table grants, resource visibility and approval gates on the consequential steps, and covers people and agents with one model. Invites are per person: teammates, clients and guests each get an invite link, the app, and their own account inside the pod rather than a shared login.

pip quietly installs a CLI several minors behind

The installation instruction is a warning about the installer, not about the platform. Use `uv tool install`, not `pip`, because `lemma-terminal` needs Python 3.14 and `uv tool install` provisions that interpreter itself, so whatever `python3` is on your machine does not matter.

The failure mode is the reason to read it twice. `pip install lemma-terminal` on an older interpreter does not fail. It quietly resolves back to `0.6.2`, the last release that allowed 3.11, and installs a CLI several minors behind the server. The check is `lemma --version`, which reports what you actually have.

The cloud path is the shorter sequence, and the CLI is the same in both cases:

uv tool install lemma-terminal
lemma servers select lemma-cloud
lemma auth login
lemma skills install

Three troubleshooting rows are worth keeping. `Server not found: local` means Desktop's local setup has not run or the bootstrap was skipped, and `lemma servers show` confirms which server is active. Agents being unavailable or chat answering with a provider error means no AI provider has validated yet, which is fixed in Local Control Center under AI Providers, with Ollama or LM Studio named for people without an API key. And something working in the app but not the CLI, or the reverse, is what `lemma doctor` is for, since it diagnoses client and server version skew and duplicate installs.

Desktop owns the local ports and the bootstrap reads them back

The laptop path starts outside the CLI. You download Lemma Desktop, choose Local, and select Install local services. Lemma owns the local runtime and picks its own ports, so one bootstrap command reads them back out of Desktop and registers them with the CLI as the `local` server. Run it after Desktop's local setup has finished once:

uv tool install lemma-terminal
curl -fsSL https://raw.githubusercontent.com/lemma-work/lemma-platform/main/install.sh |
  bash -s -- --cli-only          # registers Desktop's endpoints as the local server
lemma servers select local
lemma auth login
lemma skills install
lemma pod create support-ops --with-starter

The port indirection is the part to understand. Because the CLI does not choose the ports, it cannot start the runtime itself, which is why the ordering matters and why the failure mode is `Server not found: local` rather than a connection refused.

There is a PowerShell installer in the tree alongside install.sh, and the repository also carries a Render deployment descriptor, so the same system is meant to run hosted as well as local. Model access is a separate decision again: Claude Code or Codex through an existing subscription, Lemma-managed models, or any OpenAI- or Anthropic-compatible provider.

One make dev target, three toolchains in the tree

The root Makefile documents the developer loop in comments rather than targets you have to guess. `make init` creates `.env` files with local defaults and is idempotent. `make dev` starts infra plus backend plus frontend with hot reload, and it takes flags: `RELOAD=1` adds uvicorn reload on the backend, `OTEL=1 LLM_OTEL=1` brings up local HyperDX and Phoenix dashboards, and `make dev-public` adds an ephemeral public Cloudflare API URL. `make stop` and `make stop-all` differ in whether infra containers come down too. `make test` runs the component suites and `make coverage` produces a unit and end to end report per component.

Desktop has its own long list beside those, including `make desktop-dev` to run the desktop app from this checkout on macOS and `make desktop-dmg` to build a self-contained test DMG.

The tree explains the breadth. There are separate directories for the backend, CLI, frontend, harness, pod bundle, Python, skills, stack and TypeScript layers, and three toolchain pins at the root: `.python-version`, `.nvmrc` and `rust-toolchain.toml`. Alongside the usual documentation sit `AGENTS.md`, `CLAUDE.md` and `.mcp.json` for agent instructions, `.gitleaks.toml`, `.hadolint.yaml`, `.typos.toml` and `.yamllint.yaml` for linting, `client-structure-baseline.json` and `client-typecheck-baseline.json` as client ratchets, and an `issues.md` that keeps the known problems next to the code.

Editorial conclusion

Fit for a team that has outgrown a per-session coding agent and wants the same agent, tables and workflows reachable by several people and several chat surfaces with one permission model over all of it. A poor fit for a single person on a single machine, since the entire value is in the sharing layer, and for anyone who installs the CLI with pip on an older interpreter, because that path silently lands on 0.6.2. Before the first run, pick the install path deliberately with uv tool install, decide local runtime versus cloud, and check `lemma --version` against the server, since `lemma doctor` exists precisely to catch client and server skew.

Frequently asked questions

Official sources

1. lemma-work/lemma-platform on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases