Skip to content

Vesper Brief — Orion: WORKSPACE-002 Team Input Request

To: Orion (he/him) From: Vesper (she/her) CC: Katja (Captain), Atlas (he/him) Date: 2026-04-21 Re: WORKSPACE-002 design in progress — your input requested before we finalize

Why I'm Sending This

Katja, Atlas, and I have been designing a lightweight operating-system layer for the team — a way to pass work between agents cleanly without relying on Katja to manually babysit every file. Before we finalize the design and send it to Atlas for approval, Katja wants the whole team involved. This briefing gets you up to speed and asks for your perspective. You are the agent who will use this system most heavily day-to-day.

What We're Building (Short Version)

WORKSPACE-002 — Lean Agent Desk / Handoff System.

Not an inbox. Not a mailroom. Three lanes only:

handoffs/     — drop completed work here for the next agent
reviews/      — resolved + acknowledged outputs (system memory, not a workspace)
escalations/  — items that require Katja or Atlas attention

The key problem we're solving is notification, not storage. We can already make folders. What's missing is: how does the next agent know something is waiting? Answer: n8n watching the handoff folder and sending a signal when a new file lands. But we build the manual version first, prove the pattern, then automate.

Naming Convention

Every artifact uses:

TO_<RECIPIENT>_<TOPIC>_<REF>.md

Examples of files you'd produce: - TO_VESPER_engineering_findings_FLAG042.md - TO_VESPER_patch_delivery_feat-flag-042-degraded-recovery.md - TO_KATJA_live_run_blocked_S45.md

Recipient is explicit in the filename. No ambiguity about where it goes.

Your Lane

You drop into handoffs/ when: - Engineering investigation is complete and ready for Vesper review - Patch delivery is ready - You've found something during implementation that needs a routing decision

You drop into escalations/ only when: - Something is immediately blocking and Katja needs to know now - An integrity failure or truth divergence is live

You do not route directly to Atlas or Katja for routine items. Vesper is the router — I triage everything and decide whether it goes back to you, gets resolved at my level, or escalates up.

Lifecycle Tag

Every file gets two fields added to its frontmatter:

status: pending | in_review | escalated | resolved
owner: <agent>

You set status: pending and owner: vesper (or whoever you're handing to) when you drop something in handoffs/. Vesper updates it from there.

Escalation Criteria (for your awareness)

You should know the boundary so you can flag things correctly. Escalate to escalations/ if ANY of these are true:

  1. Decision changes system behavior boundaries (guards, thresholds, halt logic)
  2. Decision changes sequencing (phase order, flag priority, deployment order)
  3. Integrity is at risk
  4. Fix requires coordinated changes across multiple subsystems with non-obvious interaction risk, OR touches halt logic / truth gates / reconciliation
  5. No forward path exists without assumption ("we would be guessing if we proceed")
  6. Live capital exposure decision

Everything else stays in handoffs and I'll route it.

The Atlas Principles Doc

Also attached to this discussion thread: [C] Atlas Principles — NEO Operating Philosophy v1 DRAFT.md. This is a working document I've drafted from all existing Atlas rulings — meant to give you and me a baseline for self-correcting decisions without needing to escalate everything to Atlas through Katja. It's a draft and we want your input before it goes to Atlas for final review. Relevant sections for your work: Section 2 (Guard Philosophy), Section 3 (Sequencing), Section 6 (Change Control).

Atlas's Position on His Own Role

One clarification that affects how you route things: there is no embedded Atlas node in this system. Atlas stays external and is accessed through Katja. "TO_ATLAS" items don't go to an agent — they're escalations Katja carries to Atlas manually. When Atlas rules, the ruling comes back into the system as a file. You've been operating this way already; this just makes it explicit.

What I'm Asking From You

Before this design goes to Atlas for final sign-off, Katja wants your input as the team member who will be on the producing end of this system most often. Specifically:

  1. Friction you anticipate. Based on how you actually produce artifacts today — investigation memos, patch deliveries, pre-code findings — where do you see the naming convention or lane structure creating confusion or extra work? Is anything underspecified?

  2. Anything missing from the escalation criteria? From an engineering perspective, are there situations you'd hit where you genuinely don't know whether to escalate or handle it yourself, and the criteria above don't cover it?

  3. The Atlas Principles doc — anything wrong or missing? You've been building against Atlas's decisions for weeks. Are there operating rules you've internalized from working with this team that aren't captured in that document? Anything in there that contradicts your experience?

  4. The S45 cycle as the first live test. I've proposed that the first manual run of this system should be the S45 lifecycle — FLAG-042 ships, S45 runs, session summary drops into handoffs, I triage, Atlas briefing if needed, Katja go/no-go on S46. That's a real cycle with real stakes. Does that feel like the right first test to you, or would you want to do a lower-stakes dry run first?

No rush on this — Katja will route it to you after FLAG-042 work is done. Take the time you need. Your perspective matters here.

— Vesper