OpenLoomi: an always-on desktop attention agent that turns tool noise into decision cards
OpenLoomi is an open-source AI coworker. It connects your work tools, understands what you’re working on, and tells you what needs your attention, why it matters, and what to do next. It’s your open-source Attention Agent.
At a glance
- What is it?
- OpenLoomi is an Apache-2.0 TypeScript desktop app that connects work tools, builds a context graph over people, projects and decisions, and surfaces reminders as small bubbles. The promise is attention protection; the practical questions are which connectors you trust with background sync and how much configuration the agent runtimes actually need.
- Who is it for?
- Adopt OpenLoomi if you already live in Slack, Gmail or Notion and want a local-first desktop app that turns those streams into a 9 AM to-do and a 6 PM recap without shipping your data to a SaaS backend. Do not adopt it if you need a hosted multi-tenant service, if your team cannot run desktop software on managed machines, or if you expect a polished connector for every tool you use.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 16 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem OpenLoomi targets: commitments that fall through the gaps between apps
Work is spread across Slack, Gmail, Notion, GitHub and a handful of messaging apps. The README describes the consequence plainly: overdue replies, creeping deadlines, and the follow-up you promised on Friday. OpenLoomi's answer is an always-on desktop companion called Loomi that watches those streams and surfaces only what needs a decision or an action. The stated audience is the individual knowledge worker who already has too many tools open, not a platform team building an internal agent framework. The README also lists a broader integration story: the context, memory, connectors and Loop engine are packaged as open-source Skills and Plugins, so Claude Code, Codex, OpenCode, Hermes and OpenClaw can plug into the same resident desktop. That dual framing, personal companion first and agent host second, shapes every trade-off below.
How the attention loop works: connectors feed a context graph, memory ages, cards surface
The mechanism described in the README has four moving parts. Platform connectors run an auto-fetch background sync loop that pulls commits, issues, emails and docs into a context graph. Memory is tiered short, mid and long term, and the README says it grows on its own while staying visible and auditable. Proactive tasks schedule recurring work such as daily digests and weekly reports on the desktop. The attention agent then surfaces pre-decided reminders as small bubbles: a 9 AM to-do, a 6 PM recap, overdue replies. The README frames this as a complete intelligence loop from perception to action. Two details matter for evaluation. First, the graph is the product, not the chat interface; the messaging integrations (Telegram, WhatsApp, iMessage, QQ, Lark/Feishu) are a way to query it from where you already type. Second, memory that grows on its own is also memory that can drift, which is why the README's emphasis on auditability is doing real work rather than decoration.
Getting it running: a native desktop app plus agent runtime wiring
The README states OpenLoomi ships as a native app for Windows, macOS and Linux, and that it works out of the box with minutes of setup and no configuration wrestling. Releases are published on GitHub, and the current line is v0.9.0 (2026-08-31), following v0.8.8 and v0.8.7 in July 2026. The repository is TypeScript with the default branch main, and the web app lives under apps/web. The material supplied does not include install commands, config keys or environment variable names, so any specific CLI invocation or YAML block would be invented. What can be verified is the shape: a desktop binary from the releases page, connector authorisation handled inside the app rather than through a config file, and agent runtime integration documented at openloomi.ai/docs/reference/agent-runtimes for Claude Code, Codex, OpenCode, Hermes and OpenClaw. Treat the runtime reference as the first page to read, because it determines whether OpenLoomi is your primary interface or a context provider behind another agent.
Local-first storage, AES-256 encryption, and the limits of that claim
The privacy page is summarised in the README as local-first storage, AES-256 encryption, no data leaves your machine, and auditable access logs. Read that as a set of separate claims with different strengths. No data leaves your machine is the strongest and the most testable: if it holds, the context graph, message store and memory tiers all sit on local disk. AES-256 encryption at rest says nothing about whether an LLM call sends excerpts of your Slack history to a model provider, and the README does not resolve that in the supplied text. The topic list includes security and the project ships an auditable access log, which suggests the authors expect scrutiny. The honest position for an evaluator: verify the network egress path yourself before pointing OpenLoomi at a work Gmail account, and check whether the encryption key is derived from an OS keychain or stored alongside the database.
Where OpenLoomi is the wrong tool
Three cases stand out. First, if you need a shared team surface, OpenLoomi is the wrong shape: it is a desktop companion with local-first storage, so a colleague cannot see your decision cards, and there is no evidence in the material of a hosted multi-tenant mode. Second, if your organisation blocks background sync of email and chat into third-party software, the auto-fetch loop is the core feature, not an optional one; disabling it leaves you with a chat client. Third, the connector list is broad but the material does not enumerate per-connector depth. A topic list that includes gmail, slack, telegram and whatsapp does not tell you whether GitHub issues sync bidirectionally or read-only. The README also leans on the phrase works out of the box, which is the kind of claim that tends to mean the default path is smooth and the non-default paths are not. Budget time for the second and third connector.
How this differs from a hosted assistant such as a chat-based AI workspace
The obvious comparison is a hosted assistant that connects the same tools but runs in the vendor's cloud. The difference is architectural, not cosmetic. A hosted assistant centralises ingestion, so onboarding is a few OAuth clicks and the vendor's servers hold the index. OpenLoomi inverts that: ingestion, memory and the context graph run on your machine, which is why the README can claim no data leaves your machine and why the setup is a desktop install rather than a workspace invite. The cost of the inversion is operational. You own the process, the disk usage and the upgrade path, and you cannot hand a teammate a link to your graph. If your constraint is data residency, local-first wins. If your constraint is time-to-first-value across a team, the hosted model wins. OpenLoomi's Skills and Plugins packaging is the attempt to have both, by letting another agent runtime consume the same local context.
Maintenance, release cadence and the Apache-2.0 licence in practice
The release history in the material shows v0.8.7 and v0.8.8 within a day of each other in July 2026, then v0.9.0 about five weeks later. That cadence implies a pre-1.0 project still changing shape, so expect breaking changes between minor versions and read the release notes before upgrading. The licence is Apache-2.0, which permits commercial use, modification and redistribution provided you keep the licence and notice files and state significant changes; it also includes an explicit patent grant. That is permissive enough for internal deployment at a company. It does not, however, grant rights to the OpenLoomi name or logo, and the README's own branding assets live in apps/web/public/images, which is a reminder that trademark is separate from copyright. This is a description of the licence text, not legal advice; if you plan to redistribute a modified build, have counsel review the NOTICE handling.
Verdict: who should install it, and what to check in the first hour
OpenLoomi is a reasonable bet for an individual engineer or PM who already runs Claude Code or Codex locally and wants a resident context layer that other agents can read. It is a poor fit for a team that needs a shared, hosted view or that cannot install desktop software. The first hour should be spent on three checks that the README does not settle. Confirm which connectors v0.9.0 actually ships by reading the release notes rather than the feature table. Watch the process's network traffic while the auto-fetch loop runs, to see whether model calls carry message content. Then open the access log and confirm it records what you expect. If those three pass, the local-first design is the reason to stay; if the third fails, the auditability claim is the part of the README that did not survive contact with the machine.
Editorial conclusion
Adopt OpenLoomi if you already live in Slack, Gmail or Notion and want a local-first desktop app that turns those streams into a 9 AM to-do and a 6 PM recap without shipping your data to a SaaS backend. Do not adopt it if you need a hosted multi-tenant service, if your team cannot run desktop software on managed machines, or if you expect a polished connector for every tool you use. Before installing, verify three things specific to this project: which connectors the v0.9.0 release actually ships, whether the AES-256 local encryption covers the context graph as well as the message store, and whether your preferred agent runtime (Claude Code, Codex, OpenCode, Hermes or OpenClaw) is listed in the agent runtimes reference.
Community notes