The average professional has 4 streams of inbound — Gmail, Calendar, GitHub, Slack — and no single place where "what should I do next" lives. You tab-switch all day, re-read the same thread three times, and miss the calendar RSVP until it's already started. Just as often, the real work isn't inbound at all — it's the half-formed thought on your walk, the screenshot of a deadline you noticed in passing, the article you bookmarked for later, the Slack thread someone pinged you about.
OpenLoomi's Proactive Execution Brain (openloomi-loop) runs inside the desktop app, watches every channel in the background, enriches every new signal through your local memory, and turns each one into a typed decision card ready for a one-keystroke action — or, when you point it at messy input, a structured daily plan that checks back in.
What it does:
Step
Action
👀 Watch
Pulls new signals from Gmail, Calendar, GitHub, and Slack via Composio MCP and accepts voice memos, screenshots, links, pasted notes — every tick, in parallel
🧠 Enrich
Reads senders / organizers / repos through openloomi-memory so the card arrives with full context attached — and writes back new senders to people/ and recurring event titles to projects/
🏷️ Classify
Maps each signal to a typed decision: rsvp, draft_reply, review_pr, todo, slack_reply
✅ Pick
Review the queue in OpenLoomi's Loop panel, the local web UI, or the REPL — one keystroke to execute
If you haven't seen it yet, the Loop is OpenLoomi's proactive execution brain — it lives inside the app and watches your tools 24/7. Ask OpenLoomi in chat to bring up the overview:
Once started, the Loop writes new decisions to ~/.openloomi/skills/openloomi-loop/data/decisions.json. New pending decisions arrive as a desktop notification (top-right) so you see them without opening the view:
Open the Web View at http://127.0.0.1:3614/ and the Loop surfaces them as cards — type badge, confidence bar, triggering context, memory refs, suggested action — in a 3-column kanban at the Q tab: PENDING, DONE, DISMISSED. Click any card to open the full decision detail and run it from the browser:
The detail panel slides in from the right with the suggested action (e.g. calendar_rsvp with response: "accepted") and four explicit buttons — ▶ RUN spawns the Claude session with the decision prompt, DRY RUN previews the prompt without executing, ✓ MARK DONE records it as handled, ✕ DISMISS drops it. Nothing fires automatically; you always pick the action.
The Loop is a scheduled task that ticks every 10 minutes by default. Every tick pulls fresh signals, enriches them through your OpenLoomi memory, and appends typed decisions to the queue. Nothing fires automatically — you stay in control of execution.
The Loop never surfaces raw emails or PRs — every signal becomes a typed decision with a confidence score and the memory refs that explain why it surfaced:
openloomi-memory isn't a static context dump the Loop reads at the start. It's a living layer the Loop co-writes with you across three phases, so every decision arrives enriched by what's been learned before and writes back what's learned now.
1. Watch + Remember — the tick reads AND writes
Every tick enriches first, then remembers what was just learned:
Remember — brand-new senders get written to ~/.openloomi/data/memory/people/<email>.md; recurring calendar event titles become project notes under ~/.openloomi/data/memory/projects/
The tick itself is strictly read/derive against external tools (Gmail, Calendar, GitHub, Slack) — but writing to your own memory is fair game. After a few weeks the Loop has quietly built a contact and project graph you never had to maintain by hand.
2. Execute + Writeback — the action session re-enters memory
When you pick a card, the spawned claude -p session runs with the full memory context baked into the prompt. As it does the work, any new people or insights it discovers are immediately written back via openloomi-memory, so the next tick — and the next decision — already know about them.
$ loop run dec_a1b2c3d4✓ opened session with full memory context … claude reads people/sarah_chen.md, projects/q2_roadmap.md … … drafts reply and sends via GMAIL_SEND_EMAIL … → new person detected (Jamie from design team) → openloomi-memory add-memory "Jamie prefers Loom for async reviews" ✓ decision moved to done (memory already updated for the next tick)
3. Self-Evolve — memory tunes itself between ticks
Memory doesn't wait for the Loop to update it. Between ticks it self-tunes:
📊 Usage tracking — every read increments accessCountTotal / 7d / 30d and lastAccessedAt, so hot context stays hot
🧬 Living Connections (Hebbian Potentiation) — insights accessed within 5 minutes of each other strengthen their link; strength decays on an Ebbinghaus forgetting curve
🔄 Daily analytics refresh (24h) — recalculates trend + valueScore so stale-but-frequently-cited content still surfaces
🧹 Weekly compaction (7d) — merges similar insights, archives low-value or falling-trend entries
📉 Retention policy — 90 days no-access + low score + non-important → soft delete; 180 days → hard delete
The result: every decision the Loop surfaces arrives enriched by a memory layer that's read on entry, written on exit, and self-evolving in between — never a static snapshot.
Pick a card and the Loop spawns a fresh Claude session with the full context — sender memory, project notes, the original signal, and the suggested action — all baked into the prompt. OpenLoomi captures the result and moves the card to done with the action recorded.
The executing session also writes back any new people or insights it discovers via openloomi-memory, so the next tick already knows about them. The memory layer never goes cold between decisions — it grows every time you act.
The Loop never leaves you with an empty queue. When a Composio toolkit isn't connected — say you're missing slack for the day — the tick falls back to openloomi-memory list-insights --channel=<channel> and synthesizes signals from pre-extracted insight summaries. If even memory is offline, data/inbox/ stays available as a manual drop folder so the lib-level analyze path still produces typed decisions.
Prerequisite: Before this step, finish the AI Configuration in Getting Started → AI Configuration — the OpenLoomi app needs your AI provider's ANTHROPIC_AUTH_TOKEN, ANTHROPIC_BASE_URL, and ANTHROPIC_MODEL set in ~/.claude/settings.json (or via the on-screen Settings → API Settings panel). The Loop builds on top of that foundation.
Both keys live in Settings → API Settings. OpenLoomi uses them in tandem — one for the local server, one for the Composio MCP toolkit the Loop calls into.
Key
Where to get it
Why OpenLoomi needs it
COMPOSIO_API_KEY
Sign up at composio.dev, then Settings → API Keys → Create Key
Authenticates the Composio MCP toolkit that fetches signals from Gmail, Calendar, GitHub, Slack
💡 Prefer the terminal? Use the Composio CLI instead. Recommended for headless servers, CI, and local debugging — install the CLI, log in, and the Loop picks the key up automatically (no need to paste it in Settings → API Settings):
The CLI writes the key to ~/.composio/.env; OpenLoomi's Loop reads it from there on the next tick. Use composio whoami to confirm you're authenticated, and composio logout to clear it.
After pasting both keys (or after composio login), click Test Connection in Settings → API Settings — OpenLoomi will confirm both endpoints are reachable before you move on.
Each toolkit OpenLoomi exposes for the Loop routes through Composio under the hood. You only need OAuth once. We recommend doing this through the Composio CLI (or the composio-cli skill from inside OpenLoomi chat) — it handles the OAuth browser flow, persists refresh tokens locally to ~/.composio/, and is scriptable for headless servers.
Log in (skip if you already ran composio login in Step 1):
Each toolkit should show a status of ACTIVE. If any show INACTIVE or are missing, re-run composio add <toolkit> to redo the OAuth flow. You can also run composio whoami at any time to confirm your overall auth state.
💡 Prefer to stay inside OpenLoomi? Invoke the composio-cli skill from chat — "connect gmail, googlecalendar, github, and slack for the Loop" — and it drives the same login + OAuth flow without leaving the app. Both the CLI and the skill write to the same ~/.composio/ store the Loop reads from, so they stay in sync.
The Loop is a continuously running execution brain — it needs a scheduled task to tick on a regular interval. The fastest way to start it is to simply ask OpenLoomi in chat:
Start the openloomi-loop proactive execution brain.Run a tick every 10 minutes so new signals from Gmail / Calendar / GitHub / Slackget pulled, enriched via openloomi-memory, classified into typed decisions(rsvp / draft_reply / review_pr / todo / slack_reply), and queued in the Loop panel.
OpenLoomi handles the rest — it creates the scheduled task, registers it in Agent → Automation, and runs the first tick immediately so the queue isn't empty. The Loop panel in the sidebar starts showing cards within seconds.
Optional — terminal control (headless server / CI / debugging)
If you want to drive the Loop yourself instead of letting OpenLoomi manage it, the bundled helper starts both the schedule and the local web UI:
cd ~/.openloomi/skills/openloomi-loop./loop-ctl.sh start# ✓ schedule started (pid=…, interval=600s)# ✓ web started (pid=…, http://127.0.0.1:3614/)./loop-ctl.sh status # confirm both schedule and web are aliveopen http://127.0.0.1:3614/ # Ink & Circuit UI — Q / T / A views
The web UI binds 127.0.0.1:3614 (not the OpenLoomi app's 3414) so both can run side-by-side. Override the defaults with PORT=4000 INTERVAL=300 ./loop-ctl.sh start when you need a faster demo.
Each card carries the memory refs that explain why it surfaced — click any 🧠 memory_refs entry to inline-load the person / project / insight note. Screenshots of the web UI's Queue view and the four action buttons on every card live in See It in Action — this step stays focused on setup.
🔧 Extensible by design. The four typed actions above (rsvp, draft_reply, review_pr, slack_reply) are just the defaults — openloomi-loop is a normal skill directory at ~/.openloomi/skills/openloomi-loop/, so you can iterate on it like any other OpenLoomi skill. Add new decision types, swap in custom classifiers, point at additional toolkits (composio add linear, composio add notion, composio add jira, …), or teach the Loop to handle a brand-new channel by editing the skill's classify / enrich code and reloading. Ask OpenLoomi in chat to evolve it — "extend openloomi-loop to also classify Linear issues into linear_review decisions" — and it handles the edit + reload for you.
Four inboxes collapse into one typed queue: rsvp, draft_reply, review_pr, todo, slack_reply, etc.
Each card carries the memory refs that explain why it surfaced — no guessing, no re-reading
Confidence score (0.85 known / 0.60 cold) lets you triage in one glance
⚡ Continuous Without Burnout
The Loop ticks every 10 minutes by default; you only open the panel when there is something to do
Watch timers run independently — a hung tick never blocks notifications on new decisions
Nothing fires automatically; execution is always an explicit ▶ RUN click or a loop run <id> command
🔄 Graceful Degradation
Missing Composio toolkit → falls back to openloomi-memory list-insights for that channel
Missing memory → the lib-level loop analyze + data/inbox/ drop folder still produce typed decisions
Queue never goes silent; the Loop works on day one with zero toolkits connected
🌱 Self-Evolving Memory
Loop reads (search-all / search-memory / list-entities / list-insights) and writes (add-memory for new senders + projects, add-insight for new discoveries) through openloomi-memory in the same tick
Executing a decision spawns a fresh Claude session that writes back any new people or insights it encounters, so the next tick already knows about them
Between ticks, memory self-tunes: access counts, Hebbian Living Connections (5-minute co-access), 24h value-score refresh, 7d compaction, 90/180-day retention — the layer that grounds every decision is never frozen
For the full reference — every CLI flag, the lib-level analyze / route / notify APIs, the JSON schema for decisions.json, classifier prompt templates, the loop-ctl.sh lifecycle, and how to extend the Loop with new decision types and toolkits — see the source-of-truth spec:
