The system around the agent

In the last article, I wrote about teaching Hermes to absorb more of my judgment so that routine decisions stop returning to me. I left most of the machinery out because the implementation was still changing, and because a list of files and schemas would have hidden the part I found useful.

Since then, a problem with unattended coding agents forced me to look at the whole structure as one connected system. I wanted several agents to work on the same project at the same time, sometimes from a laptop, without letting one process overwrite another or quietly complete work that could no longer be reconstructed. Solving that exposed the relationship between memory, execution, repositories, permissions, and verification more clearly than any abstract design exercise had.

An agent can look autonomous when it runs for a long time without asking a question. The harder test begins when the work needs to be resumed, challenged, or corrected. At that point, the surrounding system has to know what the agent believed, which limits applied, what changed, how the result was checked, and whether the check itself remained trustworthy.

The easiest place to start is the agent in the middle. Hermes receives a request, gathers context, uses tools, and produces a result. That description covers the visible activity while leaving out most of the reasons I can let the activity happen quietly.

Human judgment becomes a durable operating context made from policies, project-specific constraints, and lessons that remain useful beyond the task that produced them. A distinct authority boundary handles protected actions at runtime. The cognition layer selects the relevant context before work begins, and the execution protocol applies it while turning the request into a bounded unit with explicit expectations, evidence, and stopping conditions.

Hermes coordinates two execution routes below that protocol. Some work is carried out directly through approved tools and services, while coding tasks can be assigned to delegated agents working inside isolated copies of a repository. Both routes produce evidence that can be inspected later, and both can return to the protocol when verification finds a problem.

Hermes runs as the always-on orchestrator, carrying project context across research, scheduled processes, publishing preparation, and operational work. It can coordinate an approved tool or service action directly, or assign a bounded coding task to an agent on a laptop. Several delegated tasks may be active in the same source project, and each needs to remain safe when another process crashes or loses connectivity.

Both routes use the same contract. Every meaningful task carries an identity, a record of what it expected to do, a link to the work it changed, and a lifecycle that can end in completion, recovery, or another pass. The laptop route adds stronger isolation because several writers may touch the same source project at the same time.

Each delegated task receives its own branch, isolated working copy, Git index, and activity record before the coding agent starts. The source checkout stays stable, and one task cannot switch, close, or clean another task’s work. A clean verified task may remove its temporary workspace later, while anything dirty, offline, interrupted, or uncertain remains available for recovery.

Every meaningful task begins by stating what would count as a misleading success. That may be a report without a working artifact, a green test suite whose criteria changed during the work, or a clean workspace that lost the activity record needed to explain what happened. Writing those conditions down before execution makes them available to the later review, where they remain independent from the conversation that produced the result.

The task then passes through a small execution loop. It checks its authority, loads context, records expectations, performs a bounded unit of work, compares the result against the intended outcome, and sends the evidence to a separate verifier. At consequential decision points, the protocol adds an independent comparison of viable options before execution. A failed check can trigger another pass, although the number of replans is deliberately limited so that an agent cannot disguise confusion as persistence.

Most work stays inside the automatic lane. Publishing, protected configuration, credentials, spending, and difficult-to-reverse actions require approval from outside the agent process. This keeps routine execution quiet while preserving a clear boundary around the decisions that still belong to a person.

The most useful test arrived after the new laptop system appeared complete. The automated suite was green, the integration tests were green, and a separate model had reviewed the artifact against the written requirements without raising an objection.

I had recently seen a simple suggestion in a tweet: when an agent says the work is finished, give the result to a fresh reviewer whose job is to disprove that claim. I added that pass before using the system on the laptop. The reviewer found four problems that the existing checks had missed, including an approval boundary that could not prove human presence, a missing work record that could be mistaken for successful completion, an update that could leave mixed versions after an interruption, and a migration that could remove unrelated configuration.

The completion claim was withdrawn and the task returned to execution. Each finding became an adversarial regression test before the fix was accepted. Once the changes passed the full suite, the result went back to the same reviewer, who reran the original attacks and changed the verdict from fail to pass.

That sequence matters because verification can become another source of reassurance when every reviewer receives the same framing and checks the same happy path. An adversarial reviewer changes the question from whether the work satisfies its own report to whether the report can survive an attempt to break it.

The useful output from that failure extended beyond the repaired code. The system gained new tests, a safer lifecycle, a transactional update process, and a standing policy that requires protected actions to receive authority from outside the agent process. Those changes now apply before the next agent reaches the same category of decision.

This is where cognition and execution meet. The execution loop handles the current task, records its evidence, and exposes a correction. The cognition layer decides whether that correction belongs only to this project or should become durable judgment. Independent review helps prevent an isolated mistake or an over-broad lesson from turning into a permanent rule.

Over time, the system should need fewer repeated corrections because the consequences of earlier work remain available in a form that changes later behavior. Some details decay when they stop affecting decisions, while recurring failures become easier to retrieve. The measure I care about remains the same as in the previous article: how much judgment the system can carry forward without assigning a new review task back to me.