reimagine-work

Reimagine work (v3.3 template: weekly Elon loop + continuous stream + escalation ladder + earned autonomy)

Template. Replace every <PLACEHOLDER> with your own values. Nothing in this skill sends, posts, spends or approves anything; it only proposes. The judge it refers to ships in shadow mode (log only) with hard gates on.

Find every place a human is what work waits on, remove that wait, and do it again next week. The deliverable is a short ranked list and exact yes lines, not a long report.

Asks that are already answered (never re-ask)

Before any yes line reaches the human, check these in order. If any one is true, the work proceeds with no new ask, and it gets logged with what authorized it:

1. The human already said it. If the owner's own words in this conversation asked for this exact action ("send these follow-ups, by email and chat"), that is the yes. A copy tweak they asked for ("keep it simple like the outbound") is still inside that yes. Do not send a confirm line for the same batch.
2. A lane owner approved it. If the person who owns the lane (for example, the content lead for publishing) approved, proceed under their conditions. Don't ask the top owner for a second yes.
3. A standing approval with a cap covers it. Check the approval ledger. A matching row with owner_bots, a cap and a scope is the yes.
4. It's reversible or read-only. No yes at all.

The human gets a yes line only for a new send, spend, publish, delete or gate change that none of the four covers. Each yes line that does reach them gets counted. If any lane sends more than 2 a day, flag it in the next pass as a defect to fix.

Where the idea comes from

These principles come from a public write-up by a ten-person company that runs a fleet of permanent agents. Its founder says they "found what work was waiting on and removed it, over and over." Use these principles to judge each redesign:

1. Own an area. Each agent is permanent and owns one part of the company. Two agents doing the same job is a SIMPLIFY finding.
2. Coordinate through the world, not through messages. Agents stop "telling each other what they were about to do." They read and change a shared record (queue, ledger, state file). A human relaying a message between agents is a finding.
3. Fix forward. A small reversible change goes in, a later check catches problems, and any break is fixed with a new change on top. Asking before a reversible internal fix is a finding.
4. Test on a clock, not per change. Run the full check on a schedule against the latest state. "It broke since the last run" is enough to find the cause.
5. Review by someone who didn't write it. Helper agents try to break a change before it lands.
6. Agents read production themselves. Errors, receipts and metrics go straight to the owning agent, and no human relays them.
7. A stall is an incident. A lane that ships nothing for a full working period pages its owner agent.
8. AI judges from recorded decisions. A judge either decides and cites where the owner already answered, sends back a wrong question, or holds the question for a human. "When a judge gets one wrong we say so, and the judges read that next time."
9. Nothing waits on the queue. Open asks that sit for days are the loop's main measure of failure.
10. Hard gates stay small and dumb. Anything that touches the outside world and can't be undone goes through "a small set of dumb, hard-coded gates."
11. Humans keep taste. That means saying no, deleting what the last model needed, and asking for 10x or 100x, which models do not ask for on their own.

A second source adds the stream layer: a public post on agent-written code ("code used to arrive one drop at a time. soon, if not already, code will be written as if it were a continuous stream") and the engineering manifesto it quotes. Principles 12 to 16 come from those two texts:

12. Work is a stream, not drops. Design for constant small changes, not batches that wait for a person. "AI needs to be able to work autonomously and continuously with less and less human babysitting."
13. Make the easy thing the right thing. Guardrails do the steering, so that even agents "with little context about the right way of doing things" land work inside them. A rule an agent must remember is weaker than a check it cannot skip.
14. Bottlenecks move. "what happens when you eliminate a bottleneck? Another takes it is place", including "approvals, specifications, and code reviews". Re-measure after every fix. Don't assume the old bottleneck is still the one.
15. Rework, don't only speed up. Phase 1 is speeding up existing steps. Phase 2 is "reworking and rethinking them altogether". When the pace breaks a workflow, rewrite it instead of adding another patch.
16. Fix the class, for everyone. Build the "habit of ensuring that repeated failures trigger an investigation and a fix", and put the fix in a shared skill, prompt or context file so every agent gets it next time.

A third source is a follow-up thread by the same founder on how the fleet got there ("we started with a simple thing that worked", "it earned autonomy over months", "we audit every token against our goals hourly / we double down on what works / and cut things that don't fast"). Principles 17 to 21 come from it:

17. Start narrow, earn autonomy. Start with one small job that works, check its output closely, and widen scope one ask type at a time as the record proves it. Autonomy is granted per ask type, never per agent.
18. One dial for how much to take on. Spend is set by a threshold for what counts as an actionable signal ("how bad does a bug have to be? are we fixing every P5 or only P3+"). Saying no to more is how cost goes down, and it can be turned back up the next day. The owner moves the dial; nobody decides item by item whether a low-value item is worth doing.
19. Audit cost against outcomes on a clock. Tokens are checked against the goal often (cost per outcome that actually changed something). Double down on what works, and cut what doesn't, fast.
20. Rate the work where it lands. Ask the people the work is for to rate it on a fixed cadence ("every 15 messages") and track the trend, instead of the owner reviewing items.
21. Watch a newcomer try it. A regular cold-start test ("watching newbies try [the product] weekly", borrowed from playtesting culture) finds what only the owner knows.

Rules

• Write only your own report, your own state file, and internal checks that are reversible, tested and logged, with a backup next to each changed file.
• Never send, post, publish, spend, enroll, delete, merge, change a routine, or edit a skill. You recommend these, and the owner decides.
• Never edit a script marked FROZEN. Report what it needs instead.
• Every count comes from a file opened this run, cited by path and date range. Label time estimates "estimate" and show the math.
• Never print secrets, tokens or cookies. Never put personal data about candidates or leads, money amounts, or deal names in the output. Use counts and lane names.
• Hard gates always stay human (see "Classify"). A redesign can make a gate faster or batch it, but never remove it.
• Run the existing tests before and after any build. If tests were already failing, find out why before you build. A broken shared reader is a finding in its own right.

Evidence: the ledger is the source of truth

Use what exists, in this order:

1. Approval ledger. Every owner yes and no, with scope, caps and date. Count asks against answers: asks per answer, and re-asks of things already answered.
2. Outcome record. For each yes: baseline, target, check dates, verdicts, and what_changed (changed / no_change / unknown / pending / overdue). A yes that changed nothing is evidence against that kind of ask.
3. Judge logs. Backtest and shadow rows: match rate by ask type, misses, decide / send-back / hold counts.
4. Queues. Yes-queue files, kickoff queue, open-asks list. Measure age (median, max, item-days) and asks per bot per day against the cap.
5. Gate and receipt logs. Send and publish gate rows by sender, routine receipts, browser and lock logs, missed-run reports.
6. Correction log. Every "no, wrong, redo" from the owner.
7. Chats, Slack, email and calendar (read only). Relays, pastes and access requests.

The loop (five steps, in this order)

1. QUESTION: where did agents wait on a human?

One row per kind of wait, not per instance: step, lane, who (a role, not a name), evidence (path, count, window), frequency, wait time, and touch time (estimate). Also look for yes lines, per-item picks, pastes, relayed approvals, logins and seats, reviews of work that already passed a check, chase messages, stale asks, and the same correction made twice.

2. DELETE: what protects nothing?

Delete candidates include bots, routines and yes lines with no output or receipt in 14 days, asks the bot itself would answer no to, re-asks already in the ledger, and scaffolding the current model no longer needs. Rank delete candidates by cost per changed outcome (tokens, plus dollars labeled estimate, divided by outcomes with what_changed = changed in the window). Rank "double down" candidates the same way from the cheap end. Never propose cutting a lane younger than 14 days, or one whose latest outcomes are still pending, so slow work is not cut just before it lands. Proposals only. Expired asks are recorded as "unanswered", never as "no", so a judge never learns to refuse from silence.

3. SIMPLIFY: one owner per job

List duplicate agents and loops. Name one owner per job, using the evidence: receipts, gate rows by sender, open asks. When the owner has already picked the owner (for example, a shared team agent so others can use it), that pick stands. The evidence then becomes a readiness checklist, not a reason to overrule the pick.

4. SPEED UP: remove the wait, not the step

Check for ordering bugs (work that lands after the digest it belongs to), polling hops, lock clashes, relay hops (a human or coordinator agent passing a resolve on, when the owning agent could read the shared record), and bot-to-bot asks parked in the owner's file.

5. AUTOMATE: the escalation ladder is this step (default)

Every decision a bot would otherwise hand to the owner climbs this ladder, cheapest rung first, and stops at the first rung that settles it. A rung that is unsure, errors, is skipped or times out passes the item UP, never down and never to "yes".

Ladder rules:

• New rungs start in shadow: they log their answer next to the rung above and act on nothing. A rung goes live for an ask type only through the go-live gate below.
• Log every rung's answer, reasons, tokens and cost estimate per item, so the weekly pass can report, per ask type, how far up items climbed and where each rung disagreed with the one above.
• Report second-opinion model cost as tokens (actual, from the API usage field) and dollars (labeled estimate, with the rate and its source). Never invent a rate.
• Report second-opinion model accuracy only from an eval file opened this run (backtest against the owner's recorded answers, or a labeled fixture set), with false-clear count first. A rung with any false CLEAR on a known "no" stays in shadow.

For each ask type, look up the judge's (and each shadow rung's) match rate on the ledger:

• Go-live gate: at least 30 shadow cases of that declared type with zero misses, plus the owner's yes for the rule change. Below that, it stays in shadow.
• Earned autonomy, per ask type (principle 17). Keep an autonomy level for each ask type in the state file: shadow → live-sampled (acts, owner sees a sample plus every disagreement) → live. Promotion uses the go-live gate above. The weekly pass lists every ask type that met the bar in one block with one yes line (the owner can strike any type), never one yes line per type.
• Demotion is automatic. Each live rung carries a built-in tripwire: one miss on an ask type (an owner override, a false CLEAR, or a no_change on a decided yes) drops that type back to shadow at once and logs it. This only tightens, so it needs no ask. Recommend the tripwire as an internal check; never edit a routine to add it.
• The bot must declare the ask type from a fixed list. No free text.
• Never auto-approve these: retries or "continue" (a retry can re-fire a send), changes that loosen a gate, and every hard-gate class.
• Changes that only tighten a gate may skip the ask only when a test proves the change only tightens. Otherwise they stay human.
• Feedback: every owner override and every no_change outcome goes back into the judge's principles before the next weekly backtest.
• Name the kill switch (one per rung; for the judge and its second-opinion pre-pass, judge/KILL).

Continuous-stream layer (runs inside steps 1, 4 and 5)

A lane is a drop lane when its work waits for a batch, a clock or a person before it moves. For each bot, read these from files (receipts, queue timestamps, yes-queue, routine schedule) and mark each one drop or stream:

Measure each stream lane on three numbers:

• Signal-to-shipped time: from the input landing (lead, draft, reply, error) to the outcome receipt. Report the median and the slowest, and show the math.
• Throughput and batch wait: items shipped per day, plus the share of item-hours spent waiting on a batch, a clock or a person.
• Cost per changed outcome (principle 19): tokens from usage fields, plus dollars labeled estimate with the rate and its source, divided by outcomes graded changed. Read it on a clock (at least daily) from files; the owning agent reads its own number, and no human relays it.

Rules for the stream layer:

• A stream never removes a hard gate. Sends, spend, publishing, merges and gate changes still need the owner's yes. The stream form of a hard gate is a standing rule with a cap, a kill switch and a per-item log. The owner approves that rule once, and every change to it needs a new yes.
• Sampling review applies only to work inside an approved gate, or to internal and reversible work.
• Signal threshold. Each lane has one threshold for what counts as an actionable input (severity, value or confidence), stored in the state file. It covers internal, reversible work only; hard-gate classes ignore it and stay human. Raising it (doing less) only tightens and needs no ask. Lowering it (doing more, spending more) is a rule change and needs one yes. When cost per changed outcome rises, propose raising the threshold before proposing to cut the lane.
• Ratings never clear anything. A rating is read next to what_changed; a pleasant result that changed nothing still counts as no_change. A falling rating trend is a stall (principle 7) for the owning agent. Use ratings only where the owner already collects them, or from the owner's own sampled reviews. Adding a rating prompt to anything outside people see is a new send and a hard gate: propose it, never build it.
• Re-measure after each change (principle 14). A fix that moved the wait to the next step is a partial, not a win.

Classify each finding

Pick exactly one:

• delete: protects nothing.
• automate: deterministic, reversible, testable. The agent does it and logs a receipt.
• judge: needs taste, but the owner has answered this kind of question before. It climbs the ladder (deterministic, second-opinion model, judge). Each new rung goes through shadow first, then the go-live gate above.
• batch: must stay human, but goes in one digest per day or week, or becomes one standing rule with a hard cap.
• keep-human (hard gates): outside sends, posts and sequence enrollment (unless a written standing rule with a cap covers them), spending, publishing, legal and anything signed, hiring decisions, personal-data exposure, deletes, merges, and credential actions. When unsure, pick the safer class: keep-human > batch > judge > automate > delete.

Two structural checks the loop always runs

Per-bot ask cap. Each agent gets at most N asks a day (default 3) that show as their own yes line. Asks over the cap stay queued with their id but fold into one digest block without a yes line each. Report asks per bot per day and how many went over. A bot that keeps going over the cap is a finding: merge its asks, add a standing rule, or give it a judge type.

Outcome record. Every yes gets a what_changed field, filled from the existing check verdicts and never re-graded by the loop. The weekly pass reports the changed rate (changed / graded), the no_change and overdue ids, and which ask types produce yeses that change nothing (candidates for DELETE or for the judge's "no").

Redesign from zero

For each top candidate, answer these questions:

1. If we started today with agents that read every system directly, would this step exist at all?
2. What is it waiting on? Remove that, not the symptom.
3. Can agents coordinate through one shared record instead of messages?
4. Can the agent fix forward and roll back instead of asking first?
5. Where must a human stay? Make that gate small, dumb and hard-coded.
6. What would make it 10x better, not 10%?
7. What is the smallest single ask type this could start with, in shadow, this week? (principle 17) Name it in the redesign. Write the redesign in two or three sentences: what the agent does, what the human still does, and what the hard gate is.

Rank and score

Score = estimated minutes saved per instance x instances per week. Show the math. Break ties by wait time, then by the number of lanes unblocked. Drop anything under the bar (default 30 min/week).

Leverage score (0-100), reported weekly. It shows whether the loop itself improves:

• 25 points: share of last week's owner asks that a judge, standing rule or deterministic check settled without the owner (from the ledger)
• 15: median age of open asks, with full marks at 1 business day or less
• 10: stream share: share of active lanes with no drop sign in the stream check, scaled by how much median signal-to-shipped time fell week over week (full marks when every lane is stream and none got slower)
• 15: share of yeses with a graded outcome and a changed rate of 70% or more
• 10: no bot over the ask cap on more than 1 day
• 10: no duplicate owners left for any send or publish loop
• 10: no relay hops (owner answers that were retyped elsewhere)
• 5: last week's DELETE and 10x lines were answered Score only from files. If a part has no data, it scores 0 and is named as a gap.

Cold-start test (weekly)

Once per weekly pass, give a fresh agent with no memory and no prior context only a lane's entry point and its written instructions, and have it try the lane's job in shadow (read only, nothing acted on). Log every place it stalls, asks a human, or guesses. Each stall is a QUESTION finding (owner knowledge that lives nowhere written) and a principle 16 fix: put the answer in the shared skill, prompt or context file. Rotate lanes week to week. It touches no gate and sends nothing.

Outside reviewer (weekly)

Once per weekly pass, send the top 3 to 5 moves to a second strong model that had no part in writing them. Make one call and save the transcript. The reviewer returns DO / DO WITH CHANGE / DON'T for each move and names the biggest gap. Fold its changes in, or say why not. Never send it secrets, personal data, money amounts or deal names.

Modes and routine

• Weekly full pass (routine, for example Friday morning): all five steps, the outside reviewer, the leverage score, the judge shadow status by ask type, the outcome record summary, and the per-bot stream check (each bot marked drop or stream on the eight checks, with its signal-to-shipped median and the week-over-week change), cost per changed outcome by lane, the autonomy level by ask type (promotions and automatic demotions), each lane's signal threshold, and the cold-start test stalls. Output: top 3 moves, copy-paste yes lines (one per gated move), one DELETE line and one 10x ask for the owner's taste.
• Weekday incremental (routine): read only what changed since last_run_at, then surface at most one new finding that clears the bar, or stay silent and log why.
• On demand: a full pass whenever asked.

Output format

ONE recommendation: <the single change, one sentence>
Why: <evidence path + count + estimated minutes/week (estimate)>
Three options:
  A (recommended): <change>, shadow first, <how long>, <what decides go-live>
  B: <smaller or different change>
  C: <do nothing, and what that costs>
ONE ask: `<exact yes line>`   (only when it touches a hard gate or a rule change)

The weekly pass adds a top-10 table (process, evidence, class, redesign, min/week) and a "principles check": each principle above marked match, partial or miss, with evidence. It also adds a stream table (bot, drop signs, fix, signal-to-shipped now and target, whether it needs a yes).

State file (one per deployment)

{
  "schema_version": 3,
  "ladder_version": "3.3",
  "last_run_at": "ISO-8601 with offset",
  "last_full_scan_at": "ISO-8601 with offset",
  "bar_minutes_per_week": 30,
  "ask_cap_default": 3,
  "leverage_score_history": [{"week": "YYYY-Www", "score": 0, "parts": {}}],
  "cursors": {"<source path>": {"mtime": "", "lines": 0, "last_id": ""}},
  "stream": {"<bot>": {"week": "YYYY-Www", "drop_signs": [],
             "signal_to_shipped_median_min": null, "items_per_day": null,
             "cost_per_changed_outcome": null, "rating_trend": null}},
  "signal_threshold": {"<lane>": {"value": "", "set_by_owner_at": "", "note": ""}},
  "autonomy": {"<ask type>": {"level": "shadow|live-sampled|live",
               "shadow_cases": 0, "misses": 0, "promoted_at": null,
               "demoted_at": null, "demote_reason": null}},
  "cold_start": [{"week": "YYYY-Www", "lane": "", "stalls": 0, "finding_ids": []}],
  "findings": [{
    "fingerprint": "lane|step-kind|source-path",
    "title": "", "step": "question|delete|simplify|speed_up|automate",
    "classification": "delete|automate|judge|batch|keep-human",
    "first_seen": "", "last_seen": "",
    "evidence": [{"path": "", "count": 0, "window": ""}],
    "est_minutes_per_week": 0,
    "status": "candidate|surfaced|accepted|declined|shadow|live|retired",
    "surfaced_on": null, "owner_answer": null, "outcome_ref": null,
    "resurface_if": ""
  }],
  "runs": [{"at": "", "mode": "weekly|incremental|full", "new_rows_read": 0,
            "surfaced": null, "silent_reason": null, "reviewer": null}]
}

Each run: load the state (do a full pass and create it if it is missing) → read only changed sources → update counts → skip findings already surfaced, accepted, declined, shadow, live or retired unless resurface_if is true (never re-ask a declined finding without new evidence) → pick at most one finding at or above the bar → output it or stay silent → link accepted findings to their outcome row (outcome_ref) → keep the last 60 runs.

Done means

• Every finding has a path and a real count. Every time is labeled estimate with its math.
• Hard gates stayed human. Nothing was sent, posted, enrolled, spent, deleted, merged or changed outside the report, the state file and tested internal checks.
• The ask cap and outcome record were checked, and their numbers are in the report.
• The judge's go-live status is listed by ask type, against the 30 cases and zero misses bar, along with each shadow rung (second-opinion text, second-opinion images): items seen, CLEAR count, false CLEARs, tokens and estimated cost.
• The outside reviewer's verdicts are folded in (weekly pass).
• The leverage score is reported, along with what would raise it next week.
• Every active bot has a stream check row with its drop signs and its signal-to-shipped time, or a named data gap.
• Cost per changed outcome is reported per lane from files, or named as a gap.
• Autonomy level is listed per ask type, with every demotion and its reason.
• The weekly cold-start test ran on at least one lane, and its stalls are findings.