🌅 East — Vision

Human as participant in agentic ecosystem, not just operator. Continuity of creative work across physical contexts (desk ↔ movement). Self-handoff as first-class workflow pattern.

"I am open to having it well named by whoever will interpret this, to create some kind of handing off to the local agent."

🔥 South — Design

Core System

A local, desktop-anchored agentic system that:

• Lets the user speak into a watch/phone while away from keyboard
• Routes, structures, and stores that content
• Hands it off to existing or new local agent sessions
• Supports back-and-forth "handoff to self" between desktop and movement contexts

Main Actors

Actor	Role
Human	Speaks ideas/instructions while moving; reviews/curates when back at desktop
Mobile capture client	iOS Shortcuts + watch-triggered recording, 3 dictation modes (button, short silence, long silence)
Local server	HTTP endpoints: /ingest/raw, /handoff/current, /handoff/update, /sessions/list, /sessions/ingest
Routing agent	Periodic loop (1min), LLM decomposition into atomic units, proposes session mapping
Work agents/sessions	MCP-aware, receive routed messages, expose receive_message, get_context, list_tools
Desktop review UI	Today's mobile notes, Routing overview matrix, Session detail timeline

Core Workflows

1. Start movement session → desktop trigger generates handoff package with active sessions/goals
2. Capture while moving → dictation → POST to /ingest/raw with timestamp, tag, mode
3. Route & decompose → LLM pipeline: clean → segment → extract intent → propose routing
4. Mobile feedback (optional) → shortcut fetches /handoff/current, verbal confirm/change/discard
5. Desktop review & ingest → accept/reject/edit/merge/split → trigger ingestion into sessions

Key Constraints

• Local-first (network optional)
• State-machine/graph orchestration (LangGraph/LangChain compatible)
• MCP-aware sessions
• Reusable components (routing, handoff, UI as attachable modules)

🌊 West — Validation

Ambiguities (from PDE)

• Which LLM powers decomposition — local (Ollama) or cloud (Claude API)? → Make configurable
• Network accessibility iOS → local server? → Same LAN / Tailscale / tunnel?
• How do sessions register? → Push (agent registers) vs pull (manager discovers)
• LangGraph/LangChain depth? → Start without, add as optional backend

❄️ North — Action

Child Issues

• 🔗 jgwill/Miadi#180 — Miadi platform implementation
• 🔗 miadisabelle/Etuaptmumk-RSM#141 — MWDS consolidation ceremony (structural twin)

PDE Decompositions (.pde/)

• 0d80e28b — Meta-decomposition of session missions
• 783e9cc6 — Verbatim voice transcription
• 104a7bd8 — Perplexity-processed spec

---

<details> <summary>📜 Original Verbatim Transcript (from watch recording)</summary>

[Unknown Speaker A]

Okay, so I'm getting up. On my computer, there are various very interesting work that I started. Where I want to go with this is to find a way that I could be considered as a participant in something like the implementation, because in the future these agents would probably be in the loop. Or they would have something that watches their sessions, or rather their messages, to see if they receive something. If they receive a message, it influences the continuity of their sessions, of their work.

Therefore, if I'm a participant and there can be messages left, or if I can leave messages, I think we might be conceiving of a routing agent or something like that. Basically, I'm speaking to my watch and recording an audio, and we will need somewhere to drop this audio so it can be transcribed and processed accordingly, in whatever way it is received. Maybe it is going to be through an iOS shortcut that would receive the recording.

This server has intelligence and is capable of decomposing what I spoke about. It probably has access to what is going on. Maybe in the first version it is not going to be capable of doing everything, but I'm going to speak it out here anyway.

Optimally, these sessions are in an awaiting mode for continuing and are triggered by a change, something decomposed and organized by the routing agent. That is what would be receiving my… I do not know what to call this, but right now I am doing some physical exercise and it makes me see that I really need this interface, or whatever we call that. I am open to having it well named by whoever will interpret this, to create some kind of handing off to the local agent.

I am going to implement something. I think that one of the constraints right now is being local on the computer. When I get up, I can launch a server pretty quickly. Inside of it, there are ways to input and give my content there for processing.

I would be interested in what skills I need to put into motion to do all of that. I know that in these systems there is a relationship with state machines, because yesterday I did some interesting reading and there is something about state machines and large language models with graphs. There is something called LangGraph and LangChain. I have these certifications in progress on the Udemy platform, which probably will not be recognized adequately, but that is not that important. There are libraries and code bases being constructed to help advance the work.

At the level of abstraction, we want a reflection layer that would prepare a handing off to work within our existing libraries, to upgrade them or create new ones. This service or server interface, whatever we call this, is something I am thinking about while getting up and not looking at the screen. I might look at the screen, but I might also not.

There could also be another way to interact with it. In iOS Shortcuts, it is possible to do a loop over a certain number of iterations. It is possible to present a menu that leads into some form of sub‑functions. If I use the dictation tools, I can have something transcribed and sent to an API right away.

There are three modes: when you press the button; when there is a short silence; or when there is a long silence that stops dictating and passes the input to the next node in the workflow graph. This is one of the main possibilities that I would want to support.

There is also something about handing off to myself: from being on the desktop to being in exercise. Right now I am doing an exercise with my shoulder; it is pretty good. It is very important to get up and move.

Given that this application could exist, we already have some code on the server that could probably be used as a platform to call or do something. We do not necessarily have to start from scratch.

My point here is that either I am starting fresh—meaning I get up and start recording, I start my iOS shortcut—or there are other possibilities. When I am getting up, there could be a process that gets triggered on the computer and that prepares something in storage. When I start my iOS shortcut, it would then "grab your handing‑off package."

When the handoff package is retrieved, it is a sequential thing where I can give verbal feedback on each piece of content. But that increases the level of complexity, because it raises a question like: what am I going to input there? That is a good question.

We are creating a system, and often the formulations of the desired outcome are not to my liking. If I am told where we are and what outcome we are trying to achieve, and then I am asked anything, I will speak content that could be decomposed into anything relevant.

There could also be a mode on the computer where, every time content is received, my agents work on it, or it just sits there. When I am finished doing my workout, I sit down at the computer and press a button like "ingest," and it injects the content into whatever session.

I think there would be a routing agent running just for this during the whole session while I am up. It would probably loop in an iteration and, each minute, call to see if there is something to ingest, with proper instructions to do its job.

Hopefully, any other agents that have sessions are registered and have the Model Context Protocol tools, and they know whether they have received a message or not. When I am sitting at the computer, there could be a visual representation of where the messages composed by the routing agent are going to be sent. With something really easy to use visually, I would be able to accept or reject items, or input more content with my voice.

</details> <details> <summary>📐 Unit Schema Example</summary>

{
  "id": "unit-2026-02-22-001",
  "source_raw_id": "raw-2026-02-22-001",
  "timestamp": "2026-02-22T16:16:00Z",
  "text": "I want a routing agent that polls every minute and sends my notes to active sessions.",
  "type": "design_intent",
  "project_hint": "agent-orchestration",
  "priority": "normal",
  "proposed_destinations": ["session-design-docs", "session-impl-tasks"],
  "status": "pending_review",
  "annotations": []
}

</details>