NEO Lean Handoff System v1¶

From: Atlas (he/him) To: Katja (Captain), Vesper (she/her) Date: 2026-04-21 Re: Replace overbuilt "inbox" idea with lightweight, reliable handoff model

1. Core Principle¶

We do not need a full mailroom or a giant inbox tree right now.

What we need is a handoff system, not an inbox system.

That means only three things must exist:

A place to drop work
A way to know something new is ready
A clear rule for who picks it up next

If those three are true, the desk works.

2. The Design Goal¶

Agent A finishes work → Agent B knows there is something to review → Agent B responds in the correct lane → Only true escalations reach Katja or Atlas.

That is enough. Everything beyond that is optional until the process proves itself.

3. Why the Big Inbox Model Is Too Much Right Now¶

A full inbox tree sounds organized, but too early it creates: folder sprawl, duplicate artifacts, uncertainty about where something belongs, extra routing overhead, more maintenance than value.

Right now NEO needs clarity, not complexity.

4. The Lean Model — 3 Lanes Only¶

A. `handoffs/`¶

Where the current agent drops the completed artifact for the next agent. Examples: Orion drops a patch memo; Vesper drops a strategy review; a completed session summary gets written here. This is the work transfer lane.

B. `reviews/`¶

Where the next agent processes items that were handed off. Examples: Vesper checks for new engineering outputs; Orion checks for routed bug investigations; Atlas checks only for architecture-alignment items; Katja does not live here — she should not be forced to monitor this continuously. This is the thinking / response lane.

C. `escalations/`¶

Only for items requiring higher-level attention. Examples: something needs Katja's approval; a structural design issue needs Atlas; a live run is blocked; an integrity failure occurs; a patch has consequences beyond local scope. This is the high-priority lane, not a general discussion area.

5. Minimal Folder Structure¶

NEO Desk/
  handoffs/
  reviews/
  escalations/
  status/

Do not go beyond that until the process proves itself.

6. The Real Problem Is Notification, Not Storage¶

The challenge is not where the files live. The challenge is how the next agent knows it has work waiting.

The MVP is: - Agent A drops artifact - Agent B is notified or can reliably detect it - Agent B responds in the right lane

7. Ownership Rules¶

Orion owns implementation notes, bug investigation memos, patch summaries, engineering outputs. Drops into handoffs/ when ready for Vesper or Atlas. Drops into escalations/ only if immediate operator awareness is required.

Vesper owns strategy reviews, triage, classification of whether a handoff is routine, bug-related, architectural, or escalatory; translation of technical results into decision-ready briefings. Drops into handoffs/ when routing to Orion or Atlas. Drops into escalations/ when Katja needs to decide. Vesper is the router, not just the reviewer.

Atlas receives only architecture handoffs, escalations, and phase-level decisions. Should not be in the general review stream.

Katja receives only escalations, final briefings, and decision-ready artifacts. Should not have to continuously watch handoffs or reviews.

8. Naming Convention (Critical)¶

TO_<RECIPIENT>_<TOPIC>_<SESSION or FLAG>.md

Examples: - TO_VESPER_session_summary_0041.md - TO_ORION_bug_investigation_flag037.md - TO_ATLAS_alignment_guard_recovery.md - TO_KATJA_live_run_go_nogo_S45.md

This gives: recipient, purpose, context — without any extra tooling.

9. Tiny Status System¶

One file in status/: CURRENT_HANDOFF_STATUS.md

Contents like: - Ready for Vesper: session 41 summary - Ready for Orion: investigate flag 037 - Ready for Atlas: guard recovery ruling - Waiting on Katja: live run approval

Or marker files: READY_FOR_VESPER, READY_FOR_ORION, READY_FOR_ATLAS, READY_FOR_KATJA.

The point: the next person can tell in seconds whether work is waiting.

10. Practical Options for Notification¶

Option A — Manual but structured: shared handoff folder + strict file naming + one status file. Low-tech and good enough to start. Works today.

Option B — Lightweight automation: use n8n only for: watching the handoff folder, detecting a new file, sending a notification / creating a task / writing a marker. This is the best next step once the manual process is stable.

Option C — Full inbox / dispatch system: do not build this yet. Save it for later.

11. What to Preserve When Porting Agents¶

Do not get hung up on perfectly cloning agents into another platform. The important thing to preserve is not the personality — it is the operating spec. What actually matters: role, responsibility, output format, review rules, escalation rules, pickup/dropoff logic.

12. Minimal NEO Handoff System v1¶

Required: one shared handoffs/ folder, one shared escalations/ folder, one status/ file or marker system, naming convention by recipient.

Nice to have: one reviews/ folder for processed outputs, one lightweight notification layer later.

Not needed now: giant inbox trees, multi-folder mailroom, full dispatch bureaucracy, perfect agent cloning.

13. Example Flow¶

Session summary: (1) Session process generates summary → (2) TO_VESPER_session_summary_S41.md written → (3) Status updated: "Ready for Vesper: S41 session summary" → (4) Vesper reads and routes to: TO_ORION_..., TO_ATLAS_..., or TO_KATJA_....

Engineering bug: (1) Orion finishes investigation → (2) Writes TO_VESPER_engineering_findings_FLAG037.md → (3) Updates status → (4) Vesper reviews and decides: route to Atlas for design decision, route to Katja if approval needed, archive if routine.

14. Final Recommendation¶

Build now: handoffs, reviews, escalations, status, naming convention.

Add later: lightweight n8n notification, session-end automation, richer routing.

Defer: giant inbox systems, full dispatch architecture, agent personality portability.

The lean version is the correct version for NEO right now.

— Atlas