OpenLoomi: an open-source attention agent that runs as a desktop app

The problem OpenLoomi picks: context scattered across tools, and attention spent reassembling it

The README opens with the premise directly: "Your work is scattered across apps." OpenLoomi's answer is to connect the tools you already use, read what is on your screen with your permission, and assemble the context behind your people, projects and decisions. The output is not a chat window. It is a set of decision cards the README describes as approvable in one tap.

The target user is someone whose day is spread across Slack, Gmail, Notion and a code host, and who loses commitments in the gaps between them. The README names the failure mode plainly: overdue replies, creeping deadlines, the "I'll send that follow-up Friday" that never goes out. OpenLoomi's pitch is that a resident desktop process can hold that thread better than you can, because it never stops watching.

This is a deliberate scope choice. OpenLoomi is not a general assistant that answers anything. It is narrow on purpose: notice, remember, remind. The README calls it an "Attention Agent," and the framing is defensive rather than expansive. The stated goal is to surface what needs a decision without competing for focus, which is why the surface is a small bubble rather than a dashboard.

How OpenLoomi works: connectors feed a context graph, memory layers it over time, the Loop engine acts

The architecture is visible in the repository layout. This is a pnpm workspace monorepo: apps/ holds the desktop and web code, plugins/ and skills/ hold the extension surface, benchmark/ holds evaluation code, and Casks/ holds a Homebrew cask for macOS distribution. The desktop shell is Tauri, which the root package.json confirms through its tauri:dev and tauri:build scripts and a src-tauri/tauri.conf.dev.json config path inside apps/web.

Data flows in three stages. First, connectors pull from external tools. The README describes an "auto-fetch background sync loop" that pulls commits, issues, emails and docs proactively into a context graph. Second, memory organizes what arrives. The README describes short, mid and long-term memory that grows on its own and is "visible, auditable." Third, the Loop engine and the Attention Agent decide what deserves a nudge, producing the 9 AM to-do and the 6 PM recap the README lists.

Messaging is a second surface rather than a separate product. Telegram, WhatsApp, iMessage, QQ and Lark/Feishu are named as places where you can talk to the AI inside an existing conversation. The README also states that any agent framework can plug into the same resident desktop, naming Claude Code, Codex, OpenCode, Hermes and OpenClaw. The mechanism for that is the Skills and Plugins directories at the repository root, which the README says deliver the context, memory, connectors, attention agent and Loop engine as open-source components.

One dependency detail is worth flagging. The root package.json pins @whiskeysockets/libsignal-node to a specific git commit through pnpm overrides, and lists better-sqlite3, sqlite-vec and sqlite3 among onlyBuiltDependencies. That tells you the local store is SQLite-based with a vector extension for retrieval, and that WhatsApp support leans on a git-pinned fork. Pinning to a commit is reproducible, but it also means upstream fixes do not arrive until someone updates that hash.

Installing OpenLoomi and getting the first decision card

The README positions OpenLoomi as a native app that "works out of the box." The repository ships a Casks/ directory for macOS and a GitHub Releases page, so the intended path for most people is a packaged build rather than a source checkout. The README does not document a command-line installer, so treat the release page and the cask as the entry point.

If you are building from source, the root package.json sets the floor: Node 22 or newer and pnpm 9 or newer, with pnpm 10.14.0 declared as the package manager. Install dependencies from the repository root.

pnpm install

To run the desktop shell in development, the root package.json exposes a tauri:dev script that sets IS_TAURI=true and PORT=3515 before invoking the Tauri CLI against src-tauri/tauri.conf.dev.json.

pnpm tauri:dev

You should see the Tauri window open with the Loomi companion, served from the web app on port 3515. For a distributable desktop build, the same file provides tauri:build and tauri:build:debug, the latter useful when you want symbols while debugging a connector.

pnpm tauri:build

The web-only path is separate. If you only want the front end, pnpm dev filters to the web workspace and pnpm build produces its bundle. Neither script gives you the desktop companion, the screen context or the background sync loop, so do not judge the product from the web dev server alone. After the desktop app starts, the first real task is connecting a tool and letting a sync cycle complete; the README states the sync loop is what populates the context graph, and memory is described as growing over time rather than being seeded at install.

Where OpenLoomi is the wrong tool: headless deployments, thin documentation, and a young plugin contract

The most concrete limitation is architectural. OpenLoomi is a desktop app by design. It reads screen context, it runs on Windows, macOS and Linux as a native application, and its proactive tasks are described as running "on your desktop." If you need an agent in a container, on a shared server, or in CI, this is not that product. There is no documented headless mode, and the Tauri shell is the delivery mechanism rather than an optional wrapper.

Documentation depth is uneven. The README is rich on capability and thin on operations. It does not document rollback, migration between versions, how to revoke a connector's access, or what happens to the context graph when you disconnect a tool. The privacy section states local-first storage, AES-256 encryption, no data leaving your machine and auditable access logs, but the README does not explain key management or where the encryption key lives. For a tool that reads your screen and your email, that gap matters more than it would elsewhere.

The plugin surface is also young. At v0.9.0, with v0.8.8 and v0.8.7 landing in July 2026, the Skills and Plugins interfaces are still pre-1.0. Building against them now means expecting churn. And the release cadence itself is a signal about maturity rather than a problem: the last push was on 2026-08-31, roughly three weeks before this writing, so the project is moving, but a sub-1.0 version with a single-digit minor history has not yet been through the kind of external scrutiny that surfaces edge cases.

Finally, there is a category of user for whom this is simply the wrong shape. If you want a chatbot you query, OpenLoomi's value is mostly wasted, because its design assumes you do not want to ask. If you want a team-shared knowledge base, the local-first storage model works against you.

OpenLoomi against a self-hosted MCP stack or a note-taking memory tool

The honest alternative is not another attention agent. It is assembling the pieces yourself: an MCP server per tool, a vector store for retrieval, a scheduler for the digests, and a chat client for the interface. That stack is more work and more control. OpenLoomi's difference is that it ships the whole loop pre-wired, including the parts that are tedious to build: the background sync loop, the layered memory, the desktop companion, and the messaging integrations to Telegram, WhatsApp, iMessage, QQ and Lark/Feishu. You are trading configuration freedom for a working default.

A second alternative is a memory-first tool such as a personal knowledge base with an AI layer. Those tend to be retrieval-oriented: you ask, they answer. OpenLoomi inverts the direction. The README's framing is that it tells you what needs attention without being asked, which is a push model. If your problem is "I cannot find what I wrote," a search-oriented tool is a better fit. If your problem is "I forgot to reply," the push model is the point.

The third comparison is against the agent frameworks the README itself names: Claude Code, Codex, OpenCode, Hermes and OpenClaw. Those are runtimes that execute tasks you give them. OpenLoomi's stated position is that it can host them on the same resident desktop while supplying the context, memory and connectors they lack. So the relationship is closer to complementary than competitive, and the decision is whether you want the context layer to be a separate always-on process or something you wire into each runtime individually.

Licence, upgrade cost, and what the repository tells you about maintenance

OpenLoomi is licensed Apache-2.0, and the LICENSE file sits at the repository root. Apache-2.0 is permissive: it allows commercial use, modification and redistribution, and it includes an explicit patent grant, which matters for a project that integrates with third-party messaging networks. It also requires that you preserve notices and state significant changes. If you fork OpenLoomi and ship it, that obligation follows you. None of this is legal advice; read the LICENSE file and the SECURITY.md and CODE_OF_CONDUCT.md documents at the root before you depend on it.

One licence-adjacent detail deserves attention. The pnpm overrides pin @whiskeysockets/libsignal-node to a git URL rather than a registry version. That dependency carries its own licence terms, and because it is fetched from a commit hash rather than a published package, you should check it separately if you redistribute a build. The same applies to the sqlite-vec and better-sqlite3 native modules listed in onlyBuiltDependencies.

Upgrade cost is moderate and mostly predictable. The monorepo uses a single version at the root (0.9.0), and the releases are frequent enough that staying current means regular bumps. Because native modules are involved (better-sqlite3, sqlite3, sqlite-vec), upgrades can require rebuilding against your Node version, which is why the engines field pins Node at 22 or newer. The context graph itself lives in local storage, and the README does not document a migration path between versions, so back up your data directory before a major bump.

On maintenance: the last push was on 2026-08-31 and the repository is not archived. That is recent activity, and v0.9.0 shipped the same day. Beyond that, the repository does not include issue history, contributor counts or a published roadmap, so any claim about long-term support would be a guess.

Editorial conclusion

Adopt OpenLoomi if you want an always-on desktop companion that keeps your context local and you are comfortable building a pnpm monorepo with Node 22 or newer. Do not adopt it if you need a headless service, a stable plugin API, or a project with a long public issue history, because the repository exposes no such history here. Verify three things before you commit: whether the packaged release for your platform exists under Casks/ or GitHub Releases, whether local-first storage and AES-256 encryption match the compliance rules you work under, and whether the Skills and Plugins interfaces have stabilized at v0.9.0.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. melandlabs/openloomi on GitHub
3. Project website
4. README
5. Releases