• 

  Voice observability for parallel coding agents. Ask from the kitchen, approve a resume by voice. Alexa+ track.

• 

  An open MCP server (spec 2025-11-25, Streamable HTTP): four tools, three states, one voice approval.

• 

  Voice approval requires the session name, never a number. Dead-session resume fires; live sessions are refused.

• 

  Honest boundaries: demo on fixture (real reader exists), no Alexa+ device yet, resume stays dry-run.

• 

  analyze_stall returns ranked hypotheses with confidence and evidence, then one recommended action — not just a flag.

• 

  fleet_status output: 4 sessions classified by PID liveness — active, stalled_suspect, dead. Contents never emitted.

• 

  No screen in sight. The user asks "anything going on?" — one session waits for input 30 min, one died with an error.

============================================================

Inspiration

I run several coding agents in parallel. The failure mode I actually hit: I walk away to cook, come back, and one agent has been waiting for my input for 30 minutes while another crashed silently. Checking a screen defeats the point of stepping away — I wanted to ask out loud what was happening and get an answer that respects the fact that I cannot look at a display.

============================================================

What it does

fleet-voice-ops is a self-hosted MCP server that turns parallel coding-agent sessions into a voice-queryable fleet:

• fleet_status — per-session liveness (active / stalled_suspect / dead) from PID liveness checks and last-activity timestamps — never conversation contents
• whats_stuck — the voice-first question "anything going on?" answered in one spoken sentence
• analyze_stall — the agentic part: multiple ranked hypotheses (waiting_on_human_input, blocked_by_unresolved_error, …), each with confidence and evidence signals, plus one recommended action
• request_resume — a write action behind human-in-the-loop voice approval: confirmation requires speaking the session name, never a number

The demo asks from the kitchen, hears one session waiting for input and one dead, and approves resuming the dead session — no screen involved.

============================================================

How we built it

Python MCP server over Streamable HTTP (mcp SDK 2.x, spec 2025-11-25) with a Bearer auth middleware, verified end-to-end through an ngrok tunnel from a generic MCP client. Session state comes from devin list --format json, PID lock files, and transcript structure. All emitted fields pass a two-layer allowlist — raw records contain titles and paths we read but never emit, enforced by exact-key tests (16 tests total). The demo video itself is generated by a deterministic pipeline: Piper neural TTS for narration plus ffmpeg-rendered scene cards.

============================================================

Challenges we ran into

• We assumed live sessions could be re-attached — measured reality: ACP rejects it. So resume targets dead sessions only, and the tool refuses live ones rather than corrupting state.
• Transcript file mtime lagged real activity by up to 24 minutes — we switched liveness to PID checks plus devin list activity timestamps.
• Raw session records mix sensitive fields (titles, paths) with safe ones, so "just don't read it" was impossible — we read internally and emit through an allowlist instead.

============================================================

Accomplishments that we're proud of

• A voice round-trip that actually completes a write action: hear the state, speak the session name, approve the resume — all hands-free.
• Every claim in the demo is verified against real sessions and documented in the repo (reachability-evidence.md, interrupt-test-evidence.md).
• The demo video is itself reproducible: one command regenerates narration, scenes, and the verified final cut.

============================================================

What we learned

Voice observability is different from voice control: knowing what to say — which sessions are stalled, why, and what's safe to do next — is the product. The Alexa+ submission path without partner tooling is real: a self-hosted Streamable-HTTP MCP server plus a simulated voice loop covers the contract.

============================================================

What's next for fleet-voice-ops

• Wire a real Alexa+ device once partner tooling opens beyond preview
• Move resume from dry-run to opt-in execution behind the same name-confirmation gate
• Grow hypothesis coverage from structure signals to outcome signals (PR merged, tests green) so "stuck" becomes "not progressing" detection

Built With

• devin-cli
• ffmpeg
• mcp
• ngrok
• piper-tts
• python
• streamable-http