lmthing

A complete platform for building, running and deploying AI agents — and a super agent, THING, that builds the rest for you. Describe what you want; THING creates the knowledge, spawns the specialist agents, and orchestrates them until the thing exists: a database, an API, a web app, a team workspace, a scheduled job that runs while you sleep.

You can use it as a chat app, as a workspace for your team, as a store of installable apps and integrations, or as a runtime you build on. Same system underneath.

One statement at a time, streamed. The host evaluates each statement as it arrives — inside a QuickJS WASM sandbox, against a set of globals that a capability grant decides an agent may even see. There is no generic filesystem on any agent's surface. An agent that was never granted db:write does not get a "permission denied"; the function is not in its world at all, not in its types, not in its prompt.

What that buys you:

• Real control flow. Loops, map, conditionals, intermediate variables — one turn does work that a tool-calling loop spends ten round-trips on.
• A typechecker in the loop. Generated code is typechecked against generated DTS before it is saved, so faults are caught in the writer, not at 2am in production.
• Safety by construction, not by asking nicely.

→ org/docs/runtime/ · org/docs/runtime-globals/

The other half of the system is the space format — the on-disk shape everything is authored in. A space is a directory of AI specialists plus the tooling they reference, and it is the unit you read, diff, edit by hand, commit to git, publish to the store and install into someone else's pod.

<space>/
├── agents/<slug>/
│   ├── charter.md      # who this agent is — fork-safe identity and guardrails
│   └── instruct.md     # YAML frontmatter (its wiring) + operating instructions
├── functions/          # deterministic TypeScript helpers — no LLM, no tokens
├── knowledge/          # structured domain docs, loaded ON DEMAND, not glued to every turn
├── tasklists/          # DAG workflows: index.md + numbered steps (a .ts step is a code node)
├── components/         # UI the agent renders — view/ for display(), form/ for ask()
├── events/             # typed emitter defs (webhook / cron / db / internal) — a space can be an EVENT SOURCE
└── hooks/              # event consumers

An agent's frontmatter is its wiring — which functions it may call, which knowledge fields it may load, which components it may render, which actions map to which tasklist, which capabilities it holds, and canDelegateTo (who it may hand work to). Every one of those references is resolved against the sibling directory at load time: name a function that isn't there, or misspell a frontmatter key, and the space refuses to load rather than quietly granting nothing.

Why this matters in practice:

• Prompts stop being monoliths. Knowledge is a tree of small aspects a turn pulls in when it needs them, so an agent can know a great deal without paying for all of it every message.
• Determinism where you want it. Anything that doesn't need a model is a function. Anything with a fixed shape is a tasklist DAG.
• Agents that build agents stay honest. A model can't write these files directly — it goes through typed builder functions that are rooted to the space and typecheck the source before it lands on disk. That is idea #1 doing the work for idea #2.
• It is portable. A folder is a store listing, a git repo, a pull request, a copy-paste.

→ org/docs/format/space/ · the project format

You talk to one agent. Behind it, THING writes new spaces, forks itself for parallel work, and delegates to specialists whose powers are narrower than its own — a data modeler that can touch schemas and nothing else, an API author that can write one endpoint, an engineer with a throwaway sandbox. It grows the team the job needs, and you can open every member in a text editor.

→ org/docs/runtime/ · delegation

Ask for a recipe planner, a health tracker, a trip organiser. The builder writes a schema, a set of typed endpoints that are typechecked at save time, and a UI authored as a spec against endpoints that already exist — then runs an acceptance stage that asks whether the app is right, not merely well-shaped. It is served at a clean URL on lmthing.app, with its own data, its own hooks and its own scheduled jobs.

→ org/docs/app/ · app authoring

lmthing.team: several people, their own accounts, one workspace. A team is not a share of someone's account — it is its own principal, with its own compute pod, its own tier and its own subscription, so nothing a team spends is billed to a member and no member's personal keys are involved.

• Channels, DMs, handles, pinned apps and roles (owner / admin / member / viewer) that are actually enforced — a viewer's write is refused by the pod, not hidden by the UI.
• THING lives in the channels. Reply in a thread without @-mentioning it. It knows who is in the team, what the other channels are, and what was decided last week: teamContext, teamMembers, teamChannels, teamHistory, teamPost, teamCreateChannel, teamPinApp — gated by team:read / team:post.
• Shared tasklists, live activity, and an invite that actually tells the person they were invited.

→ org/docs/cloud/teams.md · team globals

A native Tauri v2 app for Linux, macOS and Windows, running the same chat / teams / dashboard surfaces as the web app and the phone. It exists for two things a browser tab can never give an agent: your local files, and a browser that is logged in as you.

The browser pane is a real webview inside the app window — not a screenshot stream, not a hidden headless Chrome. One DOM, one cookie jar, one scroll position, watched by you and driven by the agent at the same time. It uses WebView2 / WKWebView / WebKitGTK, which you already have, so the download cost is zero. The agent gets 13 purpose-built functions — open, readText, elements, clickAt, typeText, waitFor, back … — and when it opens a page, the pane opens visibly. Giving an agent a browser nobody can see is the exact thing the design exists to prevent.

→ org/docs/desktop/ · the live browser

The mobile app renders the same source as the web app — screens are imported from @lmthing/ui, not rewritten. Push notifications sent only by your own pod, over-the-air updates from a self-hosted update server with a staging→production two-stage flow, message drafts and editing, history paging, pull-to-refresh, haptics, and an honest offline state.

→ org/docs/mobile/

lmthing ships as a single-file executable (Node SEA) for 5 targets. Download it, run it, and you have the whole pod runtime — CLI, REST API, WebSocket, agents — on a machine with nothing installed. The zerostack coding agent is inside it; a browser is one command away. One tagged release carries every client: desktop binaries, the Android APK and the CLI bundles.

→ org/docs/cli-api/bundle.md · CLI commands

Passwordless email sign-in, alongside GitHub. A 6-digit code and a magic link — and the magic link signs in the browser that asked for it, and nobody else. No password to choose, leak, or reset.

→ org/docs/cloud/auth.md

There is deliberately no filesystem on the model surface, which leaves one gap: nothing can look at a live generated app — read the project a user is complaining about, run its typechecker, open its SQLite file. zerostack (a ~26 MB static Rust agent, shipped inside the compute image) is an ordinary process with an ordinary shell, and it can. It sits at the end of a deliberate escalation chain — THING → engineer → zerostack — and it is a leaf: it drives a shell, it does not re-delegate.

→ org/docs/system-spaces/zerostack.md

• Bring-your-own-token integrations, each one a self-contained space — adding a provider is adding a folder. Browse and install them from lmthing.store, setup guide included.
• Events everywhere: emitter definitions (webhook / cron / db / internal), event hooks, and emitEvent in the sandbox. Something happens outside; your agent wakes up and deals with it.
• Inbound webhooks brokered by the gateway straight into your pod.
• Consent, in front of you. Installing a space that wants powers shows you a card naming them.

→ events & integrations · store & consent

webSearch and webFetch are backed by an in-cluster headless-browser render service, so JavaScript-rendered pages are readable and search falls back across providers instead of dying. Agents also read images, audio (transcribed), spreadsheets and office documents.

→ render & web search

lmthing.store carries whole apps, agent spaces and integrations. Install one into your own pod in a click; it arrives as files you own and can edit.

→ org/docs/product-spas/ · apps API

Every user (and every team) gets an isolated compute pod. Free-tier pods scale to zero and are woken by the edge on any request — cold wake takes about a second, with real boot progress on screen instead of a spinner that lies. Cron jobs are externalized, so a sleeping pod still keeps its appointments. Four tiers, multi-window budgets, and your workspace backed up to your own GitHub repo.

→ org/docs/devops/infrastructure.md · billing & tiers

org/docs/ is the single source of truth for this codebase. Every factual sentence there ends with a citation to the implementation that makes it true (path#Symbol), and pnpm docs:check resolves every one of them as a hard CI gate. When a README, a CLAUDE.md or a skill disagrees with org/docs, org/docs wins; when org/docs disagrees with the code, the code wins and the doc is a bug.

A code change is not done until the matching org/docs/ page is updated in the same change — the contract is org/docs/SYNC.md.

Prerequisites: Node.js ≥ 24 · pnpm ≥ 9 · Git (package.json:5-7)

git clone [email protected]:lmthing/lmthing.git
cd lmthing
git submodule update --init --recursive   # sdk/org is a submodule
pnpm install

cd sdk/org/apps/web && pnpm dev    # /studio, /computer and /chat are client-side routes

cd sdk/org/apps/desktop && pnpm tauri:dev

Ports, the *.test nginx proxy, demo auth and every make target are documented in org/docs/devops/local-dev.md.

The monorepo is organized by TLD — each lmthing.* domain has its own top-level directory.

lmthing/
├── sdk/org/            # git submodule (github.com/lmthing/org) — the runtime + shared libs + the clients
│   ├── libs/           # @lmthing/{auth,cli,config,core,css,state,ui,utils}
│   ├── apps/web/       # the unified Vite SPA: /studio, /computer, /chat
│   ├── apps/desktop/   # the Tauri v2 desktop app
│   └── apps/mobile/    # the Expo / React Native app
├── cloud/              # THE backend — Hono gateway (/api/*) + LiteLLM (/v1/*)
├── org/                # lmthing.org — the docs site; org/docs/** is the source of truth
├── store/              # lmthing.store SPA + the catalog (store/projects/, store/spaces/)
├── com/ social/ space/ blog/ casa/   # product app shells (static SPAs)
├── devops/             # terraform, ansible, argocd, k8s manifests
├── app-specifications/ # worked example specs for project-apps
└── automation/         # long-running agent harnesses (not part of the product)

There is no separate backend service. cloud/ is the sole backend; every frontend is a static SPA that calls it. Any server-side logic — new endpoints, DB ops, webhooks — belongs in cloud/gateway/.

Never write a raw color in any web surface (no hex, no literal rgb()/hsl(), no stock Tailwind color utilities like gray-*/blue-*). Use a design token (var(--foreground), bg-primary, …). Hard gate: pnpm lint:tokens and CI. Rules → org/docs/design-system/.

No license has been declared for this repository yet — all rights reserved by default.