← lab

Rasputin_Loop

2026

one agent loop, no router

Built for the Slack Agent Builder Challenge · submitted jul 2026

The problem

A Slack-native agent built on Strands and running on MiniMax M3. @mention it (or /loop) and a single agent loop thinks, optionally calls a tool, and replies in-thread — reading attached files, remembering what matters, and running several distinct Slack apps from one process.

The constraint

One brain, or a router? The obvious build is an intent parser dispatching to handlers. That fails the moment a request straddles two intents. The bet here: no parser, no command router, no extraction pipeline — one agent decides, and everything else is a tool it can reach for.

What the git log says

  • $ Episodic memory in SQLite, each entry stamped with who/where/when and re-injected with provenance — the agent is its own filter: saves signal, skips chit-chat, de-dupes.
  • $ Hybrid recall over libSQL/Turso: FTS5 lexical + local `fastembed` vectors fused by Reciprocal Rank Fusion — no embedding API key in the loop.
  • $ Guardrails inside the loop, not bolted on: tool-call caps, repeat limits, a token budget, and a risky-Slack-method blocklist.
  • $ `loop-eval` runs a golden set through the real agent and gates on regressions; per-interaction telemetry and per-step traces persist to SQLite.
  • $ Jira auto-triage: bug reports detected in-thread → title/priority/assignee extracted → confirmed with the user → ticket created, with @mention → Slack email → Jira account ID routing.

What I learnt

A single loop with good tools beats a router with good intentions — the routing logic you don't write is the routing logic that can't be wrong. Provenance on a memory is what makes it safe to re-inject; an unstamped memory is a rumour.

PythonStrandslibSQL/TursoMCPSlack