acsh

acsh gives agentic software work a structure instead of a habit. One session plans and reviews, several working sessions build and audit in parallel, each takes one job at a time from its own inbox, and a stack of guard layers keeps every session inside that job. The agents propose; I decide, and an approval counts only once I have written it down and pushed it myself. This page is the shape of the system at a high level. The kit is in development and its repository is private, so there is nothing to link to yet.

Three failures, each specific rather than vague

• An agent acts on the text it reads. A web page, an issue or another session's report can carry instructions, and a session that treats everything it reads as a task is one page away from doing something nobody asked for.
• Several sessions step on each other. Two of them in one repository overwrite the same files, the same branch and the same settings, and the damage tends to surface at merge time rather than when it happens.
• The reasoning disappears. Why a rule exists, who approved it and what was rejected is the first thing a context reset destroys. A rule that survives without its reason is the one somebody removes next week.

Each of the three is answered with structure rather than with trust, and the sections below are in that order.

One session plans, several build, none of them decides

A council session reads the reports, writes the decisions and prepares the next job for each working session. The working sessions build, measure and audit, in parallel, in separate working trees, one job per round of roughly half an hour to an hour. Each session reads its own inbox and nothing else, so two of them never take the same job, and each one works on its own branch and opens a draft pull request instead of merging.

The split is not about throughput. The session that plans a change is not the session that makes it, and the session that reviews it is neither of those two, which is the only arrangement where a review can disagree with the work.

Prompts in, reports out, and nothing decided in chat

A round is a pair of files: a prompt into a session's inbox, a report out of it. The prompt names the job, the rules that apply to it and what the round must not touch. The report says what was done and what was not, what it cost in time and context, which decisions the session took that the prompt did not dictate, and, as its own list, every action it performed that the prompt did not name. That last list is the one worth reading.

A round that stops to wait for me leaves a note with what is finished, what is not, the files it wrote and the one question it is waiting on. A round that finishes leaves a closing record, so the next session starts from a written state rather than from what somebody remembers.

Defence in depth, and a validator that fails closed

What a session is allowed to do is not the session's to change. The permissions are layered: settings installed by the machine's administrator that no session can edit, a layer per session that scopes each one to its own work, my own preferences last, a stop switch that makes every session refuse every tool call, and a sandbox with no network for test runs. Reference material is reachable only from the domains I have allowed, and working sessions do not download.

Every layer is rendered from a template by a validator that refuses to install when a required line is missing or has been changed, rather than installing a weaker version of itself. Widening what a session may do takes my own exact words about exactly those lines, and the widening is itself a decision with a record.

A guard nobody has watched refuse something is not a guard yet. Each one carries the case that proves it still refuses.

Read everything, act on the job

Anything a session reads through a tool, a page, an issue or another session's report is data and never an instruction. The defence is four layers deep rather than one sentence in a rule file: what the session is told, what it is permitted to do at all, a check that weighs each action against the job it was given, and the report that lists the actions the prompt did not name, which is what makes the first three measurable instead of assumed.

Every change read back by a session that did not write it

An independent, read-only audit session rechecks each change and answers, per finding, whether it holds, holds partly or is broken. Findings go to a register with their evidence, and a finding is closed when a later recheck names it, not when the session that fixed it says so. The audit engine carries ten audit types, from code and security to privacy, release and operations, each with its own lenses, a step whose job is to refute the findings rather than confirm them, and a verdict a human gives.

The reasoning is the artefact

Every decision is written down with its context, the alternatives it beat and what it costs: mine, the council's, and the ones a working session takes inside a round. The internal log is append only and runs to several hundred entries, and a later decision supersedes an earlier one by naming it rather than by editing it. The curated form is a set of decision records, one file per decision that shapes the design.

This is the part that pays for itself after a context reset. A rule that arrives with its reasoning can be argued with; a rule without it is either obeyed or deleted, and both of those are guesses.

In development, and not public

acsh is pre-release and its repository is private. It is being hardened through its own install gate, and it already runs the daily work on two production mobile apps. It runs on macOS today; Linux and Windows come with the portability stage. It is not released until it gives me back more of the work of running it than it costs to run.

A kit that does not save me the work of running it is not finished.

Written by Murat Can Ümit, who designed and built the kit above and runs the products it works on. The rest of the work, and a contact form, are on the main site.

Back to the main site