Slack as a mobile memory capture and retrieval channel

Research Question

Can a Slack bot in a personal or team workspace serve as a memory capture and retrieval surface? What is the minimum viable setup: slash command vs bot, incoming webhook vs Socket Mode, and does a free Slack workspace support enough API access? Can the bot call search_brain and return results into a thread?

Findings

(Populated from §6 Synthesis above.)

Executive Summary

A free Slack workspace fully supports a memory capture and retrieval bot using Socket Mode, which eliminates the public URL requirement via an outbound WebSocket connection. The minimum viable implementation is a Bolt for Python process that subscribes to message.channels for capture and handles a /brain slash command for retrieval via search_brain, with the 3-second ACK requirement satisfied cleanly by the ack() + respond() async pattern. The binding constraint is hosting: Railway, Render, and Fly.io (new accounts) do not sustain always-on WebSocket processes on free tiers; Oracle Cloud's Always Free ARM A1 VM is the only genuinely zero-cost always-on option. Slack is the correct channel [inference] when it is already the user's ambient environment. For a purely personal bot with no existing Slack workspace, Telegram is strictly simpler.

Key Findings

1. Socket Mode is available on free Slack workspaces, requires no public URL, and is the correct transport [inference] for a personal memory bot — the bot process connects outward to Slack via WebSocket without needing any inbound HTTP endpoint.

2. A single Slack app handles both capture (message event subscription) and retrieval (slash command), counts as 1 of 10 allowed integrations on a free workspace, and satisfies both use cases with no free-tier API feature restrictions.

3. The minimum viable bot scope set is channels:history, channels:read, chat:write, and an App Token with connections:write; the full capture and retrieval handler is approximately 15–20 lines of Bolt for Python using the message.channels event and a slash command.

4. The 3-second Slack slash command ACK requirement is satisfied by the ack("Searching…") + respond() async pattern: the bot acknowledges immediately with interim feedback, runs search_brain asynchronously, and posts results within 30 minutes using the response_url provided in the command payload.

5. The free workspace's 90-day message history limit is irrelevant to this use case because GitHub is the canonical memory store and each captured message is committed to the repository immediately; no memory is stored in or retrieved from Slack's message history.

6. Railway, Render, and Fly.io do not provide reliably always-on free hosting in 2024–2025 for a Socket Mode bot that requires a persistent WebSocket process; new Fly.io accounts (post October 2024) have no free tier, and legacy-free accounts face autosuspend risk for outbound-only connections.

7. Oracle Cloud's Always Free ARM A1 Compute is the only genuinely zero-cost always-on host: up to 4 OCPUs and 24 GB RAM across 1–4 VMs, no expiry, suitable for a Python bot running as a systemd service; the trade-off is Do It Yourself (DIY) setup (SSH, systemd) rather than PaaS one-click deployment.

8. End-to-end capture latency is approximately 200 ms–1 s (Socket Mode event delivery 50–200 ms, GitHub Contents API write 100–800 ms), and retrieval UX feedback is sub-second because the ACK posts "Searching…" immediately; full results follow when search_brain completes.

9. Telegram long-polling is functionally equivalent to Socket Mode for the no-public-URL requirement, has no workspace or integration limit, requires a single BotFather token (vs. two Slack tokens), and is strictly simpler to set up for a purely personal bot; Slack is the better choice only when it is already the user's ambient mobile environment.

10. iOS Shortcuts (direct GitHub Contents API write from lock screen) and a Slack bot capture path are complementary surfaces: Shortcuts handles spontaneous ambient capture from Apple Watch or lock screen; Slack handles deliberate capture with conversational context from within an existing Slack workflow.

Assumptions

• Assumption: The user has a Slack workspace or is willing to create one. Justification: Research is conditional on Slack being used; without a workspace, Telegram is unambiguously better.
• Assumption: search_brain is invocable as a Python function or subprocess from the bot process. Justification: Required for the retrieval path; implementation is out of scope for this item.
• Assumption: A fine-grained GitHub PAT with Contents: write on the Memory-System repository exists or can be created. Justification: Same credential established by the iOS Shortcuts research; no additional approval needed.

Analysis

The key architectural question — Socket Mode vs. webhook — resolves conclusively to Socket Mode for any deployment that cannot expose a persistent public HTTPS endpoint. Socket Mode requires no inbound connectivity; the bot process connects outward to Slack. The cost is that the process must run continuously. The prior research finding (slash commands incompatible with GitHub Actions) does not apply here because this item uses a dedicated bot process.

The hosting analysis is the most practically important finding [inference]: free PaaS options fail the always-on requirement. Oracle Cloud's ARM VM is the only credible free path, and it is genuinely powerful (6 GB RAM for a single VM vs. the 256 MB of typical free PaaS containers). The setup cost is higher (manual SSH/systemd configuration), but this is a one-time cost.

Slack vs. Telegram resolves to usage context: Telegram is simpler to set up with no workspace overhead, while Slack has the advantage for users already in it all day. One empirical question determines the answer [inference]: does the user already use Slack?

Risks, Gaps, and Uncertainties

• search_brain is unimplemented. The retrieval path depends on a callable search_brain function whose latency and output format are unknown. Memory-System W-0003 implementation work must define this interface.
• No on-process test conducted. Implementation patterns are documentation-derived, not device-validated.
• Fly.io autosuspend risk for outbound-only processes. Autosuspend is documented as triggered by absence of inbound HTTP traffic, which a Socket Mode bot never receives; legacy free users may find the bot autosuspends anyway.
• Socket Mode connection loss. Events during WebSocket reconnection windows can be missed. Acceptable for personal use; unacceptable for high-reliability systems.
• Oracle Cloud capacity availability. ARM A1 free capacity can be exhausted in high-demand regions, requiring retries or region selection at sign-up time.

Open Questions

• Does the user already use Slack for work? This single question determines whether Slack or Telegram is the better channel. If yes, Slack. If no, Telegram.
• Should the bot confirm each capture with a reply? A "✓ Captured" reply increases user confidence but adds one chat.postMessage call per capture event.
• Should captures go to inbox/ or notes/ in the Memory-System repo? The inbox/ pattern matches the established approach; notes/ skips a processing step.
• Can the same Oracle Cloud VM host both the Slack bot and the Telegram bot? Both are lightweight Python processes; co-hosting on a single 1 OCPU/6 GB VM is trivially feasible.

sources

• [x] Research/completed/2026-03-02-agent-memory-management-context-injection.md — production memory system patterns; "memory accessible from wherever you already are"
• [x] Research/completed/2026-03-02-slack-msteams-research-integration.md — existing findings on Slack API for this research repo; directly applicable to the hosting and API access questions
• [x] Slack API docs (Bolt for Python)
• [x] Slack Socket Mode docs
• [x] Slack free plan limits
• [x] GitHub Contents API docs
• [x] Fly.io free tier docs
• [x] Railway free tier docs