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

Loop Engineering + ICM aren't a duo. They're one machine.

A useful loop reads saved state, acts, verifies and updates the record. Numbered folders and a shared board make that cycle inspectable by both the worker and the human.

5 parts / Hover to explore. Click to read.

A useful loop reads saved state, acts, verifies and updates the record. Numbered folders and a shared board make that cycle inspectable by both the worker and the human.

Readable task + saved state
             |
           execute
             |
            verify
             |
       correct or continue
             |
     save evidence + next state
             -> next pass
The loop supplies repeated action and checking; the folder structure carries state between passes. Persistence does not make a check correct or grant permission to change the files.
Loop + ICM starter kit, three folders, two files and the four-step loopContext Pack (for agents)
A single mechanical flywheel whose teeth are labelled folder tabs. One continuous arrow loops around driving the wheel.
The cycle and its saved state work together.

Someone asked whether Loop Engineering and ICM belonged together or served completely different purposes. The question helped make the connection clear.

Loop Engineering describes how the agent acts: execute, verify, correct, repeat. ICM, as I'm using it here, is the readable arrangement of folders and Markdown that holds the context it acts on.

Think about the verification step. What can the next pass read to work out whether the previous one succeeded?

Give the next pass something to inspect

A conversation window has a limit. A restarted worker doesn't automatically inherit the previous worker's memory. If the task, decision and evidence exist only there, the loop has to reconstruct what happened.

Saved files give it a record to return to. It can read the state, act, then compare the result with the requirement. The record still needs to be accurate and available. Persistence makes checking possible; it doesn't make the check correct.

A loop can't verify what it can't read back.

That is why the folder structure matters to the loop. It carries the memory between passes, rather than merely giving finished work somewhere to sit.

Side by side comparison. Left: a faded loop arrow spinning in empty space, labelled blind loop. Right: the same loop arrow reading from and writing to markdown files, labelled stateful loop.
A saved record gives the next pass something to check before trying again.

Three ways to ask the question

Do they intertwine? Yes, through the state each pass reads and writes. The loop supplies the cycle; ICM supplies its readable working context. A messy record can make the next pass repeat a mistake faster, so the arrangement deserves the same care as the instructions.

Can Loop Engineering be the framework for ICM? Look at a file moving from 01_inbox to 02_doing. The folder tells you where the task stands. Moving it records a decision that the next pass can inspect. The structure is the loop's scoreboard.

Are they separate uses, automation and human-readable information? Both the worker and the person can read the same board. That shared surface is what lets you supervise the work without reconstructing every internal exchange.

I still read the board every time. Readable state helps me find and recover from mistakes; it doesn't remove my judgement from the system.

Start with three folders and two files

This is the small version you can build today:

01_inbox/      new work lands here
02_doing/      loop pulls ONE item here and works it
03_done/       loop moves it here once it verifies
_board.md      loop rewrites this every pass, status of everything
_needs_me.md   loop parks anything it's unsure about

The names here matter. This example uses 02_doing. The staged pipeline in Every stage its own folder uses a different arrangement for a different job. Pick the one that describes your work rather than blending the two by accident.

Five items in a folder with a 4-step loop arrow beside them: read board, pull top of inbox, do and verify and move, rewrite board.
The folders record task state. The loop reads and updates that record.

Give the loop four steps:

  1. Read _board.md.
  2. Pull the top item from 01_inbox into 02_doing. Work on one item.
  3. Do the work and verify it. Move the item to 03_done only when it passes; record uncertainty in _needs_me.md for human attention.
  4. Rewrite _board.md to reflect the result, then begin the next pass.

The board should let you see what changed, what is still in progress and what needs you. Read it instead of relying on a worker's reassuring account of how busy it has been.

watch the board breathe
01_inbox/
generate hero image
write alt text
compress assets
02_doing/
(empty)
03_done/
(empty)
_board.md (live)
# _board.md

status: 0/3 complete
loop_pass: 0

## 01_inbox (3)
- generate hero image
- write alt text
- compress assets

## 02_doing (0)
(empty)

## 03_done (0)
(empty)

Decide what the loop may change

Having a readable folder doesn't grant permission to edit everything inside it. Name what the loop can read, what it can write and which decisions must come back to you.

That boundary is where my loops earn or lose trust. A worker may be able to inspect a source file while needing approval to change it. It may produce a verified draft while leaving the release to a person.

The dial uses invented percentages to illustrate a permission trade-off. They are not measured trust scores or a calculation of risk.

read / write dial
write _board.md
read onlyfull autonomy

Illustrative percentages, not measured trust or risk.

trust85%
blast radius15%
loop rewrites its own scoreboard each pass

The rule I keep coming back to is this:

An autonomous loop is only as smart as the state it can read back between iterations.

Give it a clear record and a real verification step. Give yourself a board you can understand. Then the cycle and its context can work as one machine.

//A<3

The teaser below preserves the June 2026 plan for ARI-OS v3. It is an illustration of the intended pipeline, not a current release announcement.

ari-os v3: June 2026 plan
🔒
hover to peek
a loop you hand a whole plan to
historical concept, not a release status
↓Loop + ICM starter kit (markdown)

[ comments ]

guests welcome. members show first in the list

no comments yet. start the thread_

1 / 7