# Video Analysis: Loop Engineering — Agents for Everyday Recurring Life **By Nate B. Jones** | Published June 24, 2026 | ~15:38 | YouTube: https://youtu.be/A4zMyjkL0Dc **Companion Substack:** https://natesnewsletter.substack.com/p/ai-loop-managers **Substack title:** "The Five Questions That Turn a Messy Task Into an AI Loop" --- ## How the transcript was obtained Direct YouTube transcript API was IP-blocked from the Hetzner cloud server. Content reconstructed via: - Video chapter breakdown provided directly by user - Companion Substack post fetched (June 24, 2026 — same day as video) - Cross-referenced web search for the loop spec, five components, Friday build details - Author confirmed: Nate B. Jones, VP Product background, AI strategist **YouTube transcript skill install (for coding agent):** ```bash # Install pip install youtube-transcript-api # v1.2.4+ # Usage — works on home IPs, blocked on cloud/Hetzner from youtube_transcript_api import YouTubeTranscriptApi api = YouTubeTranscriptApi() t = api.fetch('VIDEO_ID_HERE') text = ' '.join([s.text for s in t]) # Cloud IP fallback 1: yt-dlp with cookies from browser yt-dlp --skip-download --write-auto-subs --sub-format vtt \ --cookies-from-browser chrome \ --output /tmp/yt_%(id)s "https://www.youtube.com/watch?v=VIDEO_ID" # Cloud IP fallback 2: pass proxies to the API api = YouTubeTranscriptApi(proxies={"https": "http://your-proxy:port"}) # Fallback 3: search for companion Substack post (creator often publishes one) # web_search("natebjones.com OR natesnewsletter.substack.com [video topic]") ``` **OpenClaw skill:** `media-ingest` at `~/.openclaw/workspace/skills/media-ingest/SKILL.md` --- ## Full Video Summary ### Core Thesis A week feels heavier than it should because **you are the integration layer** for your own life. Apps solved individual tasks and left the wiring between them to you. The school trip isn't hard because packing a lunch is hard. It's hard because the email, the weather, the pickup time, the calendar conflict, and the kid who outgrew the raincoat all live in different places — and the job of connecting them lives in your head. Nobody logs that as work. More AI inside more apps (AI in your email, AI in your calendar, AI in your grocery app) doesn't fix this. It just puts an AI in each silo. The wiring is still your problem. Jones's answer: **a loop of loops** — a set of narrow, recurring AI jobs that each have memory, sources, safe actions, and boundaries, and are allowed to notice when one affects another. --- ## The Three-Level Distinction | Level | When it applies | Example | |---|---|---| | **Prompt** | You have a specific question right now | "Help me write this email" | | **Loop** | The same obligation keeps coming back | Check school announcements every Monday | | **Loop of Loops** | Those obligations aren't independent — a change in one should wake up work somewhere else | Rain forecast → update packing list → flag calendar conflict → notify parent | The key insight: **most of life's hard work lives at the loop and loop-of-loops level, not the prompt level.** Prompt-first AI tools only help with the easy part. --- ## Chapter-by-Chapter Breakdown **[00:00] Why a week feels heavier than it should** The invisible overhead: remembering, checking, following up, noticing that one small change moves three other things. This "work between apps" never shows up on a to-do list. It just shows up as exhaustion. **[01:31] Prompt vs Loop vs Loop of Loops** The distinction above. A prompt is synchronous — you initiate, AI responds, done. A loop is asynchronous — it runs on a schedule or a trigger, with or without you. A loop of loops is a coordination system. **[02:17] Agents are loop managers** Reframe: an AI agent isn't a chatbot you talk to. It's a loop manager. It runs your recurring jobs so you don't have to hold them in your head. **[03:03] A loop of loops handles the school trip** The concrete example. Individual loops for: checking school emails, monitoring weather, tracking packing list, managing calendar. When the weather loop detects rain, it wakes up the packing loop (raincoat check) which wakes up the pickup time loop. The parent gets a single "heads up, here's what changed and what I'm proposing" — not 4 separate notifications from 4 apps. **[04:06] Why apps left the hard part to you** Apps optimized for individual task completion, not cross-task coordination. The integration work was always left to the human. This is structural — it's not a bug in any particular app. **[05:04] Spotting the loops in your own life** The five questions to identify a loop candidate (see below). Jones has two specific prompts for this — one that walks you to a single loop, one that finds where loops should notice each other. **[06:33] Starting simple: sales and research loops** For work contexts: a sales loop that checks for trigger events (funding rounds, new hires, company news) and drafts the outreach message. A research loop that monitors a topic and surfaces weekly summary. Both **draft only** — nothing sent until you approve. **[08:57] The boring loops: kids clothes and spinach** The domestic version is less glamorous but higher leverage for real families: - A kids clothes loop that tracks growth/seasons and flags when something needs replacing before it's an emergency - A grocery loop that notices the spinach keeps getting wasted and quietly removes it from the list These aren't AI assistants doing impressive things. They're just loops absorbing mental overhead. **[10:39] This is not about never asking** The important counterpoint. A good loop isn't one that never bothers you. It's one that bothers you at the right moment — and only then. The goal is "fewer, better interruptions" not "no interruptions." **[11:35] The questions that define a good loop** Five questions — see below. These determine whether a recurring job is loop-ready. **[12:40] Loops of loops as a control pattern** How the coordination layer works: loops hand off *what changed*, not the full context. The next loop starts with the delta. This keeps context windows manageable and each loop focused on its domain. **[13:49] The Friday build and a safe first project** Jones's recommendation: start with the most boring, low-stakes loop you have. Something that drafts before acting, can't cause damage if wrong, and has an obvious "this is done" condition. Build it on a Friday. If it breaks over the weekend, nothing terrible happens. --- ## The Five Questions That Define a Good Loop | Question | What it tests | |---|---| | Does this come back? | Is it genuinely recurring or just feels that way? | | Can I describe it precisely? | Is the job specified well enough to write down? | | Can it check its own work? | Is there a verifiable output / pass/fail condition? | | What can go wrong? | What are the edge cases and failure modes? | | Where should it stop and ask me? | What's the human judgment boundary? | If you can't answer question 5, don't build the loop yet. --- ## The Loop Spec (Build Primitive) Jones's five components of a robust agentic loop: 1. **Persistent Instructions** — the agent refers to foundational context/rules on every cycle 2. **Skills** — domain knowledge injected for specific tasks (portable, not hardcoded) 3. **Verification** — the agent can check its own work (tests, checklists, known-good output) 4. **Hooks & Guardrails** — hard rules it cannot violate (budget caps, max retries, prohibited actions) 5. **Stop Conditions** — explicit criteria for "done" or "must terminate" And the **loop record** — what the loop writes down at the end of each cycle so the next cycle starts with context, not from scratch. --- ## Relevance to OiMy — Honest Assessment ### Where this is directly applicable (high signal) **1. OiMy is currently a prompt-level product used for loop-level problems** Users come to OiMy with recurring family obligations — morning chaos, screen time, meal planning, school emails. They're asking one-off questions about things that come back every week. OiMy answers the prompt. Then it forgets. Then the user comes back next week with the same thing. Jones's framework makes this gap explicit. The companion layer (Grok/Gemma) is a prompt layer. OiMy needs a **loop layer on top of it** — a place where recurring patterns are recognized and converted into something that runs without the user having to ask again. This is the exact architectural gap the "proactive nudges" / signal detector (Task 5) was meant to address. The loop of loops framework gives us a vocabulary and build pattern for that. **2. The "draft before send, stop before act" principle solves OiMy's trust problem** The eval data shows trust signals are low (3.27/5). Part of that is the companion giving unsolicited advice. Part of it is users not knowing what OiMy will/won't do. Jones's principle is explicit: **a loop that can do something irreversible must stop and show you the draft first.** If we apply this to OiMy's outbound capabilities (school email drafts, Telegram messages, reminders), making the stop point visible and consistent would build exactly the kind of trust we're scoring poorly on. **3. The "boring loops" section is OiMy's addressable market** Kids clothes → kids growth tracking (size changes, season changes) Spinach → meal planning memory (what gets wasted, what the family actually eats) School trip coordination → the multi-signal event we already have in the rhythm system These aren't impressive demo features. They're the accumulated mental overhead that parents carry silently. OiMy is positioned better than any other product to own these because it already has the family profile, the conversation history, and the recurring touchpoints. **4. The "loop of loops" architecture maps to our Signal Detector + Rhythm system** Our existing rhythm messages are embryonic loops (daily check-in, morning briefing). The signal detector work is the coordination layer (loop of loops). What's missing is the formal structure: each signal getting its own trigger, memory, safe actions, and explicit stop condition. ### The specific OiMy pattern Jones describes The school trip example directly maps to an OiMy flow that doesn't exist yet: - Email loop: monitors school emails for trip announcements - Weather loop: checks forecast for trip date - Packing loop: maintains family packing list (knows raincoat was outgrown) - Calendar loop: flags pickup time conflicts These don't exist as separate loops in OiMy. They exist as individual skills (meal-planning, calendar, etc.) that don't talk to each other. The "loop of loops" architecture would wire them. ### Where this is interesting but not immediately actionable **The Friday Build / simple first loops:** Jones starts with work/sales loops. OiMy's equivalent is simpler and more domestic — but the build pattern is the same. A good first OiMy loop: the spinach loop (track what gets requested, what gets wasted, quietly update the default grocery list). Low stakes, verifiable, boring. ### Where this is NOT relevant to OiMy - **Sales/business loops:** OiMy is family-only - **Research loops with external monitoring:** Requires web access and scheduled crawls — infrastructure we don't have - **Full loop builder UI for users:** Interesting product direction but not current sprint scope --- ## What OiMy Should Actually Build (Priority Order) ### Priority 1: Recurring Pattern Recognition (1-2 days) **What:** When the same topic appears in ≥3 sessions (rolling 14 days), flag it as a loop candidate. **How:** In `_track_session_threads()`, add a cross-session count. When count ≥ 3, surface: *"Sounds like [topic] comes up a lot. Want me to keep an eye on it automatically?"* **Why now:** This is the cheapest possible loop entry point. No new infrastructure — just session data we already have. Pure companion behavior. **Stop condition:** User says yes or no. No autonomous action taken. --- ### Priority 2: "Draft Before Act" Consistency (0.5 days) **What:** Every OiMy outbound action (email draft, Telegram forward, reminder, grocery list update) must visually present the draft with an explicit "approve / edit / discard" step. No silent actions. **How:** The current skill outputs already do this for school emails. Make it a system-level guarantee, not skill-by-skill. Add to the V2 prompt: ``` [RULE] Any action that affects the real world (sends a message, creates a reminder, modifies a list) must first be shown as a draft with explicit approval required. "I'll send this when you say go" — not "I sent this." ``` **Why now:** Directly addresses the trust signal drop (3.27/5). The eval flagged "OiMy overstepped" patterns. This closes it systematically. --- ### Priority 3: Cross-Signal Loop Coordinator (1-2 weeks) **What:** When Signal A fires, check if it should wake up Signal B. Build a simple dependency table in the signal detector. **Example wiring:** ```python LOOP_DEPENDENCIES = { "weather_change": ["packing_list", "outdoor_activity_plan"], "school_announcement": ["calendar_conflict", "packing_list"], "kid_sick": ["meal_plan", "school_absence_draft"], "grocery_waste_signal": ["meal_plan_update"], } ``` When the weather signal fires for a user's upcoming event, it also checks the packing loop and notifies if there's a conflict. User gets one message: *"Rain forecast Saturday for the soccer game — Riya's cleats are on the list but I don't see a rain jacket. Want me to add it?"* This is the loop of loops applied to OiMy's family context. **Why this matters:** This is what separates OiMy from a smart FAQ bot. If we can show that OiMy noticed the connection between two things the user didn't explicitly connect — that's the product moment. --- ### Priority 4: Loop Memory (Persistent Cross-Session Context) **What:** When a recurring topic is identified, store the loop state in Honcho so the next session starts with context: "Last time you mentioned Arjun's school lunch → here's what we figured out → this is still open." **How:** Wire Honcho (API key already in systemd) to surface open loop state at session start. The loop record (what Jones calls the "record" — what the loop writes down at the end of each cycle) maps to a Honcho insight. **Why it matters:** Currently, every session starts from zero. The user has to re-explain context. Cross-session loop memory makes OiMy feel like it actually knows the family — which is the "feel" that drives high NPS. --- ## What We Should NOT Build (Loop anti-patterns for OiMy) - **Loops that act without a stop condition** — Jones is explicit: if you can't define "where to stop," don't build it. For OiMy this means: no autonomous message sending, no autonomous grocery ordering, no autonomous calendar booking. Always draft + approve. - **Loops that pretend life is simpler than it is** — Jones's precise warning: "I do not want a system that pretends my life is simpler than it is, or one that turns a bad assumption into an action because autonomy looks good in a demo." This is exactly the Klarna anti-pattern. We've already seen it in our evals (OiMy jumping to fix when user just wanted to vent). - **One giant agent managing everything** — Jones explicitly rejects this. Multiple narrow loops > one smart agent. This validates our skill-per-domain architecture over a general assistant approach. --- ## The One-Sentence Product Insight > **OiMy's job is not to answer questions. It's to absorb the mental overhead of running a family — the invisible work that lives between apps and between sessions.** This is what the loop of loops framework articulates clearly, and it's what OiMy should use as its north star for the next sprint. --- ## Updated File for Other Coding Agent The PREVIOUS analysis file at `cdn.oimyai.com/docs/oimy-nate-jones-prompting-framework.md` was based on the WRONG video (a different Nate Jones video about 4 prompting disciplines). Disregard that file. **This file is the correct one.** Key implementation items: - Priority 1: `_track_session_threads()` cross-session count + loop candidate surfacing - Priority 2: Draft-before-act rule in V2 prompt - Priority 3: `LOOP_DEPENDENCIES` dict in signal detector - Priority 4: Honcho wiring for loop memory All changes are in `/opt/oimy-engine/api.py` (Priorities 1-3) and systemd env.conf (Priority 4 — Honcho key already there, just needs wiring).