Ari’s Space*   est. 2026
Skip to content
ari*s space[ a. ]
← Libraryari os / 2026-06-15

What ARI-OS is

The orchestrator-first layer for Claude Code: the shift from doing to directing, the loop it runs, and the four pillars underneath.

5 parts / Hover to explore. Click to read.

The orchestrator-first layer for Claude Code: the shift from doing to directing, the loop it runs, and the four pillars underneath.

Outcome -> spec -> plan
                      |
                   dispatch
                      |
             monitor -> review
                      |
               human decision
Failed check -> another attempt
Unclear brief -> revise plan
Workers execute bounded tasks while the human holds judgement. A failed check or unclear requirement sends the work back through the loop.
Context Pack (for agents)

ARI-OS puts a working system around an agent session: write the brief, dispatch bounded work, watch its progress and review what returns.

The original June 2026 guide described version 2.0.0 on top of Claude Code. That is the setup explained here. The public repository has since moved on; the version checked for this revision declares 2.3.0 and adds other installer targets. The source repository is the place to check the version you intend to use.

The useful division of work stays simple. You shape the outcome and hold the judgement. Background workers do the execution. Moving a task away from your main conversation doesn't transfer your responsibility for the result.

The orchestrator sits in the chair while background workers carry out defined tasks.
Keep the outcome and judgement with the human. Give workers a defined result to return.

Run a loop you can inspect

Begin by explaining the intended outcome. Turn it into a written specification and a plan. Dispatch the work, monitor it, review the result and ship only after the human decision.

The orchestrator loop as a ring of six stages: brainstorm, plan, dispatch, monitor, review, ship.
Brainstorm, plan, dispatch, monitor, review, ship. A review can send the work back.

These steps aren't a one-way conveyor belt. A failed check sends a task back for another attempt. A result that exposes an unclear requirement sends you back to the plan.

The same structure can help a quick fix or a longer build. Larger jobs still need more careful boundaries and checks. Familiarity with the loop doesn't make their complexity disappear.

Keep four supports underneath it

  • Spec-firstpillarWrite the intended outcome and acceptance conditions before implementation.
  • Background dispatchpillarRun bounded tasks in detached workers while the main session stays available.
  • Handoff continuitypillarPreserve decisions, evidence and the next step so another session can resume.
  • Live local Cortex brainpillarStore memory locally and retrieve relevant prior work for the current task.

Spec-first gives the work a target. If the brief is vague, faster execution can deliver the wrong thing sooner. Use the working guide to turn the result you want into a task someone can check.

Background dispatch keeps implementation from consuming the whole advisor conversation. A worker can carry out a defined slice while you think about the next decision. Its returned work still needs review.

Handoff continuity keeps a long job from depending on one chat staying open. Save the actual decisions, relevant files, evidence and next step. The next session needs enough information to resume; the existence of a handoff file alone doesn't prove that it has enough.

The local Cortex brain gives the system durable memory. It stores material on your machine and retrieves useful prior context. Local storage is distinct from the processing backend: an optional API-backed configuration can send material to that provider. The brain guide explains the memory layer.

Choose a first piece of work

A one-off task needs a bounded dispatch and a way to check the result. A workflow you expect to repeat deserves a reusable structure: inputs, stages, outputs and review points.

Start with the smaller of those that actually serves the job. More workers won't repair an unclear acceptance condition.

Check the version and the installation path

This Claude Code walkthrough assumes Claude Code is installed, alongside the Python package and its dependencies. Optional capabilities have their own backend requirements. It is not a claim that Claude Code is the only dependency or the only target supported by newer versions.

The source is available under the PolyForm Noncommercial licence. Check the repository's licence for its terms; source availability should not be confused with an unrestricted-use promise.

You direct and review. The workers execute.

The install guide is the next step. Read what it will change, choose the features you need and verify the resulting setup before delegating a larger job.

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 7