Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Librarytools and plugins / 2026-06-02

The setup I use to ship while I sleep

The June account of moving prepared work into background sessions: one advisor seat, bounded workers, saved context and a human review before anything ships.

7 parts / Hover to explore. Click to read.

The June account of moving prepared work into background sessions: one advisor seat, bounded workers, saved context and a human review before anything ships.

Human: outcome + decisions
             | plan
             v
       background worker
             |
     progress + returned work
             |
       human review
             |
     separate release decision
Prepared execution can proceed while the main seat is elsewhere. The reported overnight result does not remove review or authorise workers to publish their output.
A loop showing brainstorm, plan, dispatch, watch, review, ship
One loop, six steps. Background work returns to human review before shipping.

Everything queued behind me

For a long time, I was the slowest part of my own work. One window, one conversation, one me. Three ideas could be ready, but they all waited behind whatever I was typing.

I changed the shape of the job. I kept one seat for thinking and deciding, and sent defined work to background workers. They could build while I was doing something else, including sleeping. I would review what came back.

The claim is specific. This was not a measured tenfold speed-up, and it did not replace the people making decisions. It removed some of the waiting caused by making every piece of execution pass through my active conversation.

I packaged the setup as ARI-OS. This is the June 2026 account of the workflow that led to it. The public implementation has particular dependencies and limits, covered in the linked guides below.

Give the model a working setup

The model matters. So do the brief, tools, saved context and the way a result returns for review.

A good model with no system is a brilliant person you interrupt every thirty seconds.

That is an analogy for the repeated restart. If every new conversation has to reconstruct the goal, the decisions and the state of the work, you keep paying for the same orientation.

The setup had six pieces:

  • Advisor seat: the main conversation stayed available for thinking and decisions.
  • Background dispatch: a defined task could run with another worker, using a cheaper model where it was suitable.
  • Handoff: a saved record let the next session recover the thread.
  • Memory: relevant past context could be retrieved instead of re-explained.
  • Spec-first brainstorming: the outcome was shaped before code began.
  • Dashboard: a small view showed running, finished and waiting work.

None of those removes the need to check the output. Together, they make it possible for execution to continue without requiring the person directing it to stay in the same window.

Relevant briefs and past decisions can improve an answer. They can also be stale, wrong or irrelevant. The amount of context is not a score for the quality of the answer.

the evidence dig

Toggle the example layers, then play the illustration. No model or source check runs.

This is an illustration of supplying context. Its animation does not measure a model's thinking time, verify a source or prove that more selected layers produce a better answer.

Keep the useful context between sessions

The original setup forgot too much when a session ended. I wanted a small store I could write to, retrieve from and keep on my machine.

The intended working habit was narrow retrieval: start close to the current job, and ask before expanding the scope. A separate wandering behaviour could offer one memory from outside the current focus. The point was to offer a useful thread without taking over the task.

That intention needs separating from the public implementation. The brain guide describes the inspected retrieval paths: automatic context selection can resolve to global, and related-memory retrieval can cross a workspace boundary. The original statement that it never widens on its own is not a reliable access-control guarantee. Retrieval scope needs checking in the version you run.

The daily rhythm mattered too. At the start, recover the unfinished work and open questions. At the end, save the decisions and a useful starting point for tomorrow. In the June account, I described opening the laptop already oriented instead of spending the first twenty minutes remembering where I had left off. That was my experience with the setup, not a timing guarantee for every installation.

Recordings and footage can supply material for that memory. Producing a transcript or observation is one step; storing and indexing it is another. In the inspected public version, a media command printing output does not mean that output was automatically remembered. Processing may also use configured model services even when the store itself is local.

The system can retrieve and suggest. I still decide what the material means and whether it belongs in the current job.

The overnight result

I built part of ARI-OS using ARI-OS.

I specified a tool, handed it to a background worker and went to bed. In the morning the tool existed, its tests were green and one naming question was waiting for me. I answered it. That was my contribution during the overnight run.

This was one observed result. It showed that the prepared task could advance without me in the chair. It did not show that every future task would finish correctly, or that a worker should publish its own output without review.

Six steps, with the decisions still visible

  1. Brainstorm: turn the idea into a clear outcome.
  2. Plan: divide it into ordered steps.
  3. Dispatch: give a bounded step to a background worker.
  4. Watch: follow progress and notice blocked work.
  5. Review: inspect the result; accept it or return it with notes.
  6. Ship: merge or release the work that has passed the required decision.

The human owns steps one, five and six. The system carries three and four. Planning, step two, is shared. The dashboard can report state; judgement about that state stays with the person directing the work.

Some tasks can run in parallel. Others need an earlier result. Make that dependency explicit and check the upstream work before allowing dependent work to rely on it.

one prompt, fanned out

An animated example: five parallel workers, then two dependent workers. No jobs or checks run here.

The five parallel workers and two following workers are an animated example. They are not live jobs, timing measurements or evidence that a result has passed review.

Start with one bounded task

If the bottleneck sounds familiar, read the ARI-OS overview and inspect the public repository. The install guide covers the current pinned source, prerequisites and target-specific setup.

The original article described a one-command installation and clean removal. The inspected installer has more conditions: Python and package prerequisites, separate model dependencies, best-effort backups and a manifest-based revert that does not cover every later change or stored credential. Read those boundaries before using it on a working setup.

Choose a task with a clear result and a check you can run. Let it return something you can inspect. The useful change is that prepared work can move while you are elsewhere, and the decision to accept it is still yours.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 9