Glossary

OpenLoomi is best read as a single chain from input to action, not as one big chat window. Connectors bring events in, Memory holds context, Loop decides what matters and turns each signal into a Decision card, the Attention Agent (Loomi) shows the card on your desktop, you tap Approve, and an Action Runner executes through a Connector — then the outcome is written back to Memory and recorded in the Audit Log.

This page exists to make that chain legible. It first walks the chain end-to-end, then defines every concept you're likely to meet in other pages, and finishes with a short table of distinctions that get confused in practice. Every cross-reference links to an existing page; nothing here duplicates their full setup or configuration.

---

How the concepts fit together

OpenLoomi is one pipeline. The same pieces appear on every page, just framed differently.

Two parallel input paths feed the same context layer. The main one is real-time and runs through Loop; the side one is screen-based and lands in Memory without going through Signals.

A short reading guide for the figure:

• Connectors are the real-time input path: they pull raw events from external platforms and turn them into Signals, which Loop polls on its tick. Everything that becomes a Decision card comes in this way.
• Screen Capture (macOS only) is the side input path: pressing the global capture shortcut summarises the frontmost window and the result is stored directly as a Memory record. Screen memories show up alongside messages, summaries, and insights inside Memory; they do not flow through Signals and Loop won't tick on them.
• Memory is the long-lived context layer: people, projects, prior decisions, summaries, insights, screen memories, and Knowledge Base chunks. Loop reads the relevant slice before it judges; Chat reads Memory through retriever skills; the result of every approved action is written back into Memory.
• Loop is the only thing that produces Decisions. A Decision is the typed judgement ("this email needs a reply", "this PR needs a review"), and a Card is how that judgement looks in the UI.
• The Attention Agent (also called Loomi, the pet, or the fox) is the messenger. It surfaces cards on the desktop. It does no judging of its own.
• You always tap Approve before anything runs. After approval, an Action Runner calls a Connector to actually send mail / post the comment / update the ticket.
• The result lands back in Memory (so the next Loop tick has sharper context) and in the Audit Log (so you can see who did what and when).

Worked example — "An email needs a reply"

9:12 AM. Sarah writes: "Hi — I tweaked tomorrow's Q2 review agenda, can you take a look? Also, I'd like to move our Wednesday 1:1 to Thursday same time — works for you?"

Step by step through the chain:

Every term in that table is defined in the next section.

---

Core concepts

These are the terms that anchor every other page. They are linked in the same order as the pipeline above.

Connector

A Connector is the integration boundary between OpenLoomi and an external platform — Gmail, Outlook, Telegram, WhatsApp, iMessage, Slack, GitHub, Linear, Calendar, Notion, and so on. Connectors handle both directions: pulling raw events out of the platform so the rest of the system can see them, and pushing actions back in once you approve them. For the full list and per-platform setup flows, see Connectors.

Signal

A Signal is one raw event produced by a Connector — "email arrived", "calendar invite received", "@mention on Telegram", "PR review requested". Signals are unopinionated: they carry the payload from the source platform and a shape so the rest of OpenLoomi can reason about them. They are the only thing Loop consumes. (Screen Capture is a separate input — see Memory below.)

Memory

Memory is OpenLoomi's long-lived context layer — people, projects, prior decisions, summaries, insights, uploaded documents, and Screen Capture memories — held locally on your machine. Both Chat and Loop read from Memory to ground their answers in your history, and approved Actions write back into Memory so the next judgement has sharper context. Screen Capture lands here directly: pressing the global capture shortcut summarises the frontmost window and stores it as a Memory record; it does not flow through Signals or Loop. See Memory for the storage model, tiers, and the forgetting engine.

Loop

Loop is OpenLoomi's proactive judgement engine. On a regular tick it pulls Signals from connected sources, reads the matching slice of Memory, and turns the ones that need you into typed Decisions. Loop never executes anything itself — it only "sees, thinks, and queues a card". For the full lifecycle, briefings, classifier rules, and extension points, see Loop.

Decision

A Decision is the smallest unit Loop produces — one signal becomes one structured judgement. A Decision carries a typed action (for example email_reply, rsvp, review_pr, im_reply, todo), a confidence score, a short preview of the proposed action, and any sender / subject / memory slice that's relevant.

Card

A Card is what a Decision looks like in the UI. A Card has the typed action, the confidence score, a preview body, the four-button tray (Approve / Edit Draft / Later / Skip), and — for any outbound action — a red "⚠ OUTBOUND" warning. Cards surface in three places at once: the main OpenLoomi window, the Attention Agent bubble, and the pet card. See Loop — Approvals and dry-run for the full card anatomy.

Action / ActionKind

An Action is the actual side effect that runs after you Approve a Card. The shape of an Action is fixed by an ActionKind literal — email_reply, im_reply, calendar_rsvp, github_review, linear_review, todo, deadline_notify, and a small set of others. Every approved Card maps to one of these; the runner for that ActionKind is the only thing that actually calls a Connector to execute. Custom decision types register a label + icon, but always route to one of the built-in ActionKind runners.

Attention Agent / Loomi / Pet

The Attention Agent is the desktop companion — a 168×168, always-on-top, transparent little fox that lives on your desktop and shows Card bubbles when Loop queues something for you. Loomi is the fox's name; Pet is a generic nickname for the same surface. The Attention Agent / Loomi / Pet is the messenger, not the judge — every bubble it shows is a Decision Loop has already produced. See Attention Agent.

Audit Log

The Audit Log records the consequential moments of OpenLoomi's day: every Memory read/write, every Loop judgement, every Approve / Edit / Skip, every outbound Action invocation and its result, and every Connector authorization change. Audit is the first place to look when a Card disappears, an action runs that you don't remember approving, or you need to know who saw what. See Privacy & Security — Audit Logs.

---

Supporting concepts

These are the surfaces and side capabilities that show up across the product. Each one is described by what it solves, what it doesn't take responsibility for, and where it plugs into the main chain.

Chat

Chat is the conversational entry point in the main OpenLoomi window. It solves "I have a question, a request, or a draft to write". It does not watch your day or queue cards — that's Loop's job. Chat reads Memory to ground answers and, when you tap Edit Draft on a Decision Card, you land here with the draft already loaded so you can refine it with the AI before Approving. See Chat.

Automation

An Automation (also called a Task or Scheduled Job) is a prompt and schedule that you have defined in advance — "every weekday at 9 AM, summarise my unread inbox". Loop, by contrast, discovers Signals on its own and judges whether to surface them; Automation is the executor that runs whatever you told it to run. Both share the same scheduled-jobs runtime under the hood; Loop's own brief and wrap are themselves scheduled jobs. See Automation.

Library / Knowledge Base

The Library is the user-facing surface; the Knowledge Base is what's behind it — the set of uploaded documents (PDF, DOCX, TXT, Markdown, spreadsheets, slides, images) that you want OpenLoomi to reason over. Library is explicit, user-uploaded context and is not the whole of Memory: Memory is built from your connectors and chats, Knowledge Base is what you deliberately added. See Library.

Skills

Skills are reusable capabilities the agent can call when it needs to do something specific — code generation, PDF creation, data analysis, browser automation, search, image generation, and many more. Inside a Skill, OpenLoomi runs through its Agent Runtime; Skills are how those runtimes are reached from Chat, Loop, or Automation. See Skills.

Agent Runtime

An Agent Runtime is the underlying execution environment OpenLoomi uses when it needs a model that can act — Claude Agent SDK (the default), Codex CLI, OpenCode, Hermes, or OpenClaw. Runtime selection is deployment configuration; it's not something you switch mid-task. Agent Runtime is the engine that powers Skills; Plugins (below) are the inverse bridge that lets those runtimes call OpenLoomi instead. See Agent Runtimes for the supported matrix.

Plugin

A Plugin is a thin bridge in the opposite direction: it lets an external agent shell (Claude Code, Codex CLI) call into the local OpenLoomi runtime. Once installed, Memory, Connectors, scheduled jobs, and the Pet become reachable as slash commands, skills, or @OpenLoomi prompts inside your existing shell. A Plugin does not run OpenLoomi's models — it just exposes OpenLoomi to the shell you already live in. See Plugins.

Composio / Loop channel

Composio is the hosted OAuth broker that authorizes several Connector flows behind the scenes (Google Calendar / Docs / Drive, GitHub, Notion, Linear, HubSpot, Jira, Asana, Outlook Calendar, and similar). A Loop channel is the per-source subscription that tells Loop which platform to poll on which cadence and what shape the Signal should take. The relationship to remember: Composio handles "is this user authorised?"; Loop channels handle "how often does Loop look, and what does each record look like?". Custom Loop channels today wrap a Composio toolkit + tool slug.

---

Common distinctions

These are the pairs and triplets that get mixed up in conversation. Each row states the contrast in one line.

Connector vs Signal vs Loop channel

Memory vs Knowledge Base vs Insight

All three are searchable and feed Chat and Loop; only Memory is built automatically without an explicit upload step.

Decision vs Card vs ActionKind

In short: Loop emits Decisions, the UI shows Cards, and the runner that executes uses an ActionKind.

Loop vs Automation

Loop is the discovery + judgement layer; Automation is the executor for work you already know you want done.

Attention Agent vs Loop

The mnemonic used elsewhere in these docs: Loop is the brain; Loomi is the bubble. If you see a notification, Loop decided you should.

Plugin vs Agent Runtime

They look similar because they share the word "agent", but they point in opposite directions.

Loomi / Pet / Fox and the Attention Agent

All four refer to the same desktop messenger — just different names a user might meet on different pages.

---

Where to read next

Each of these pages covers one concept in depth. Glossary is the connective tissue; the source-of-truth details live here:

• Connectors — every supported platform and the per-platform setup flow.
• Memory — the local-first tiered store, forgetting engine, and Knowledge Base inside it.
• Loop — judgement engine, briefings, dry-run, custom types / channels / classifier rules.
• Attention Agent — the desktop companion, gestures, and what bubbles when.
• Automation — scheduled jobs you write by hand.
• Chat — the conversational entry point in the main window.
• Library — uploaded documents and Knowledge Base retrieval.
• Skills — reusable capabilities the agent can call.
• Plugins — Claude Code / Codex CLI bridges that call into OpenLoomi.
• Agent Runtimes — Claude, Codex, OpenCode, Hermes, OpenClaw.
• Privacy & Security — Audit Logs, data residency, and what each surface can and can't see.

---

Related

• What is OpenLoomi? — the 30-second pitch
• Getting Started — install + first run
• Use Cases — see the chain in action