The harness — where wadachi sits

A stack is forming under AI agents, and it has renamed itself roughly once a year:

prompt  →  context  →  harness  →  loop

Prompt engineering was wording one request well. Context engineering was curating what the model sees before each call. Both run into the same wall: the context window fills up, quality falls off a cliff — context rot — and the usual remedy, summarising the conversation to make room (compaction), buys that room by throwing away precision.

Harness engineering is the answer to that wall. A harness is scaffolding outside the model that re-initialises the agent step by step: every step opens with a fresh context, reads the durable state the previous step left on disk, and resumes exactly where the work stopped. Nothing gets summarised, because nothing had to fit.

Agent = Model + Harness. The model is the part you rent. The harness is the part you build — and it is the part that decides whether an agent is reliable or merely clever.

Wadachi is not a harness. It is the memory of one.

This is the boundary, and it is deliberate:

Wadachi never executes anything, and never decides when something starts.

No runner, no sandbox, no scheduler — and it will not grow one. Wadachi answers what is known and records what is learned. Running the agent, holding the cage, choosing the moment: that all belongs to whatever harness is driving your agent — your coding CLI, your agent framework, your own script.

That is a boundary, not a shortfall. A memory that also decided when to act would be two products fighting inside one process, and you could not swap either half.

The two layers

A harness needs memory over two very different horizons, and they are not the same thing:

The hippocampus — built

The durable half. Memories with versions, Decisions that keep their rationale and their rejected alternatives, Beliefs, staleness & decay that can go stale and be superseded, a typed The typed knowledge graph that connects them, and Sleep — consolidation, proposed to consolidate. It is what lets a new session know what the last one figured out.

get_context — start here, every session is the resume step for this layer: one call at the start of a session, and the knowledge is back without re-deriving it.

The desk — built

The working half: the plan for the task in flight, the steps already done, what was tried and failed, where the thread was dropped. Three tools carry it. desk opens one — a title, an objective, and a done_when that says how to recognise the finish, because a desk without a stopping condition is a diary, not a desk. desk_log records each attempt, especially the failures: it ticks off the step that landed and writes down what did not work, then hands back the next unfinished step — which is also how you ask "what now?". desk_read picks the thread back up in a session that knows nothing, and get_context — start here, every session surfaces it automatically, above the memories and within its own budget, so resuming needs no extra call at all.

A desk lives as one markdown file, <brain>/desks/<project>/<slug>.md — plain text, the same discipline as Memories. Closing it moves the file to <brain>/desks/<project>/archived/<slug>.md, and only when there is a lesson worth keeping does it distil into a single linked memory. The plan, the attempts, the failures along the way — the working noise — never enters recall.

Why the two must not be merged

Different lifetimes. What you learned should outlive everything; what you are doing right now should be distilled or discarded when the task closes. Tip the desk into the hippocampus and recall gets worse — the brain fills with the debris of finished work, and the ranking has more noise to beat.

Wadachi already has a documented case of exactly that failure mode: recency-ranked recall once hid the right rule and let the same mistake happen twice. That incident is why procedural memory exists (see Tool reference — all 37 → review_procedures). The lesson generalises: keep the layers apart.

What about the loop?

Wadachi has no agent loop, and is not getting one. reflect, sleep and consolidate look loop-shaped, but they are background maintenance of the brain: they propose, and you approve. Deciding that work should start, iterating until a goal is verified, capping the attempts — that is the loop, it lives in the harness, and it is not wadachi's job.

This is just rule 3 of the four rules applied to the stack: propose, never auto-edit. The software suggests; the human — or the harness the human chose — decides.