Lemma Platform: a shared pod for teams and their coding agents

The gap Lemma claims: a harness that outlives one 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 argument it makes is that coding agents gave you that harness for one person, on one machine, for the length of one session. Lemma's stated goal is to make the same harness shared and permissioned, so many people and many agents work the same records, and the thing keeps running between sessions on schedules, webhooks and table events. The audience is a team that already uses a coding agent and wants its output to be reachable by non-engineers through Slack, Teams, Telegram, WhatsApp or email. That is a narrower audience than the phrase "humans and AI agents work as one team" suggests. If your work is a single developer running a script, Lemma adds a server, a permission model and a CLI you do not need.

Pods, tables and per-person scoping

The unit of everything is the pod: a self-contained environment for one person, a team, or a process. A pod holds shared state, agents, workflows, permissions and one or more apps. The primitives the README lists are tables (typed, queryable business data with row-level security), files (markdown memory for preferences, playbooks and voice guides), agents, workflows and permissions. The scoping example in the README is the clearest statement of intent: Priya is Owner and approves refunds of any amount, Marco is a Member who sees his own jobs and whose refunds route to Priya, and a Classifier agent reads tickets read-only. One permission model covers people and agents, with per-table grants, resource visibility and approval gates on consequential steps. This is the part worth scrutinising during an evaluation, because the README describes the model but does not document the grant syntax or the approval-gate configuration. You get the shape of the model, not the keys.

Getting it running: two paths and a Python 3.14 trap

There are two install paths. For Lemma Cloud, the README gives: uv tool install lemma-terminal, then lemma servers select lemma-cloud, lemma auth login, lemma skills install, lemma pod create support-ops --with-starter, and lemma chat "what can you do in this pod?". For a laptop, you download Lemma Desktop, choose Local, select Install local services, and after that local setup has finished once, run uv tool install lemma-terminal followed by the install.sh bootstrap with --cli-only, which registers Desktop's endpoints as the local server. Then lemma servers select local, lemma auth login, lemma skills install, and the same pod create command. The README is explicit that you must use uv tool install and not pip. The reason it gives is concrete: lemma-terminal needs Python 3.14, uv provisions that interpreter itself, and pip install lemma-terminal on an older interpreter does not fail loudly. It quietly resolves back to 0.6.2, the last release that allowed 3.11, installing a CLI several minors behind the server. lemma --version reports what you actually have. That is an unusual failure mode and it is the first thing to check on any machine.

When the two halves disagree, lemma doctor

The README ships a troubleshooting table, which is a signal about where users get stuck. Server not found: local means Desktop's local setup has not run or the bootstrap was skipped, and the fix is to run it and then lemma servers show to confirm the active server. Agents unavailable, or chat answering with a provider error, means no AI provider has validated yet, and the README points to Local Control Center then AI Providers, with Ollama or LM Studio named as options if you have no API key. The third row is the interesting one: something works in the app but not in the CLI, or the other way round. The answer is lemma doctor, which the README says diagnoses client/server version skew and duplicate installs. Taken together, these three rows describe a system where the desktop app, the local runtime and the CLI are separate moving parts that can drift apart, and where the CLI is the component that reports the truth. Budget time for that drift rather than treating it as an edge case.

What the repository does not tell you

The material covers the build loop and the primitives, and stops there. There is no documented upgrade procedure for a running pod, no statement about how table schemas are migrated when an agent changes them, and no description of backup or export. The README says state is shared and permissioned and that the harness compounds because corrections become standing instructions and sequences become workflows, but it does not say where those standing instructions are stored or how you review them. The release list is also a warning sign rather than a reassurance: the three most recent releases are all desktop-nightly builds tagged with a commit hash, dated the same day. Nightly-only releases mean there is no stable desktop artifact to pin to. The repository is not archived and the last push is recent, but a nightly cadence tells you the surface is still moving.

The licence choice and what it implies for a hosted product

Lemma is AGPL-3.0. For internal use, running it on your own server or laptop, the practical difference from a permissive licence is small. The difference appears if you modify Lemma and let users interact with it over a network: the AGPL's network clause is the part that distinguishes it from GPL-3.0, and it is the reason some companies keep AGPL code out of their stack entirely. The README's own framing, run it on your laptop, your server, or Lemma Cloud, means the project expects both self-hosting and a hosted offering. If you plan to build a product on top of Lemma and expose it to customers, read the licence text rather than this summary; nothing here is legal advice. Note also that the README does not state whether the desktop application and the server components carry the same licence, so check the repository tree before assuming one licence covers everything.

Where Lemma sits next to a plain agent plus a database

The obvious alternative is what most teams do today: a coding agent writing application code, plus a database such as Postgres, plus a chat surface bolted on with a bot token. The difference is not the model, it is who owns the state boundary. In that stack, permissions live in your application code, and every new surface (Slack, Teams, Telegram, WhatsApp, email) is another integration that has to re-implement the same checks. Lemma moves the boundary into the pod: tables carry row-level security, one permission model covers people and agents, and the README claims every entry point reads and writes the same records under the same permissions. The trade is that you accept Lemma's primitives instead of your own schema and your own auth layer. If your data model is unusual, or your access rules are contractual rather than role-based, that trade is worse, not better. A second alternative worth naming is simply not sharing: keep the agent on one machine and export results. That costs nothing and is the right answer until more than one person needs to write to the same records.

Editorial conclusion

Adopt Lemma if your team already writes code with Claude Code, Codex, Cursor, OpenCode or Antigravity and you want the agent's output to become a shared, permissioned app rather than a folder on one laptop. Do not adopt it if you need a stable, versioned release: the recent releases listed are desktop nightlies, and the README itself warns that a wrong install of lemma-terminal silently resolves back to 0.6.2. Before committing anyone else, run lemma doctor and lemma servers show on the machine that will host the pod, and confirm which server is actually active.

Official sources

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