The Execution Lane: Routed Is Not Done

The Failure It Fixes

Three documented occurrences of the same thing: a request over the channel whose doer was the system — “research X and send me a report”, “draft the addendum and send the file” — got routed into a task, acknowledged with a receipt, and then never executed. No routine worked the system’s own tasks. The human’s phrasing, twice: stuff is falling through the cracks. The sixteenth anti-pattern: routed is not done.

The Lane

1. The router recognises a deliverable. When an inbound request asks for an artifact back — a report, a file, a research answer — and the work is (a) autonomously executable (vault, research, writing; no third parties, no money, no infrastructure) and (b) bounded to roughly one session, it creates a task with the cos-exec label and a deliver: note: report-only, report+file, or message. It also records the originating message ID.
2. The dispatcher checks the lane every tick. If there is a routing backlog, routing wins — inbound closure comes first. If the lane is non-empty and nothing else is running, it launches a headless worker session for exactly one task.
3. The worker does the work, writes the artifact into Efforts/reports/ (HTML if it will be sent as a file — Markdown reads as plain text on a phone), delivers per the spec via the coordinator, closes the task, and sends a receipt threaded to the originating message.
4. A reply to the delivery resumes the worker session — context intact — rather than starting cold.

The label alone is sufficient intent. A small dispatch cache mirrors the labelled tasks so the tick is cheap; it is rebuildable from the task graph at any time.

What Does Not Go in the Lane

• Anything waiting — that is on someone else, not the system.
• Anything needing your input. The receipt says “needs a live session”, and it waits for one.
• Anything that spends, signs, sends outward, or touches infrastructure. Those stay with you or with a chartered operator.
• Work inside a venture’s own codebase. That is the anti-pattern of the chief of staff doing operational work; it belongs in that venture’s session.

The Worker Is Deliberately Unpersonalised

A conscious call: the worker session does not read the identity file or the feedback log. It reads the task, the constitution’s report conventions, and whatever the task points at. Reports come out in a consistent editorial shape rather than an imitation of your voice, and the session stays fast. Personalisation lives in the routing session, which wrote the task.

Things the Lane Taught

• A blocked delivery must not starve the queue. One receipt that could not send sat at the head of the queue; every later task waited behind it for hours, and the prior session had asserted the queue was fine without reading the dispatcher. Read the dispatcher; surface blocks where the human will see them, at the first tick.
• A hard rule read too widely freezes a lane that was fine. A denial on one specific action was generalised to “all actions by this agent”, and the lane froze for ten hours. Name the action, not the actor; test a differently-shaped call before generalising.
• “Will surface in the brief on the 23rd” is a mechanism claim. Verify the mechanism exists before receipting it.
• Reports get a table of contents, bead handles, and a fixed frontmatter — the worker inherits the report conventions so every deliverable is a review surface. See Reports as deliverables.

Start with the Label

You do not need the dispatcher on day one. Start by labelling system-owned deliverables distinctly, so they are at least visible as a class in the weekly review. When the class is non-empty three weeks running, build the lane.

#execution · #cos-exec · #deliverables · #dispatcher