A Working Agent Is Not a Working Factory

The previous post made a design decision: a solo developer building serious SaaS work may need separate layers for direction, coordination, execution, and implementation.

That decision is not proof.

A diagram can show Hermes, CAO, an agent-aware terminal backend, and coding workers connected in a clean chain. A demo can show several agents starting and finishing. Neither tells me whether the architecture is worth the cost of operating it.

The pilot exists to answer that question.

I will compare the planned layered workflow with the workflow I use today: Herdr, one Claude Code supervisor pane, and worker panes running Codex CLI or Claude Code for individual SDLC phases. The comparison does not need laboratory precision. It does need the same kind of representative work, the same definition of done, and a record of what the operator had to do in each path. A simpler single-agent baseline can remain a secondary reference, but the primary question is whether the new architecture improves on a workflow that already works.

Start with a task that crosses a boundary

A useful pilot task cannot be a toy edit chosen to make delegation look successful.

It should be a real SaaS change that crosses at least one meaningful boundary: request context, tenant scope, authorization, persistence, an existing workflow, or a review-sensitive integration.

The task should require the system to preserve more than code. It should preserve the reason for the change, the constraints that must remain true, the files or components affected, and the evidence required before accepting the result.

For each run, I want a small record containing:

• the original objective and constraints;
• the delegated work items;
• the worker outputs and changed files;
• review findings and verification commands;
• unresolved assumptions;
• the final decision and its owner.

If the layered path completes the code but loses the reasoning, it has not improved the workflow enough.

Process state is not software quality

An execution runtime can tell me that a worker is idle or done. That is useful, but incomplete.

A worker may be idle because it finished the implementation. It may also be waiting for credentials, paused after a failed command, or finished coding without running verification.

The pilot must therefore keep two kinds of evidence separate:

• lifecycle evidence — what the process is doing;
• quality evidence — what the produced software proves.

A status event can tell the coordinator when to inspect a worker. It cannot tell the reviewer that the authorization boundary is correct.

The acceptance record should therefore answer a stricter question: what did the worker produce, what was verified, and what remains uncertain? This is the same distinction developed in Working Is Not a Quality Metric: successful execution is evidence of behavior under conditions, not proof that the surrounding boundary is sound.

That distinction is one of the reasons to separate execution from review. Better process visibility should make review easier. It should not impersonate review.

Recovery is where the design becomes operational

The happy path is not enough.

I want the pilot to include at least one controlled interruption: a worker receives incomplete context, a verification command fails, a review finds a boundary problem, or a session has to be restarted.

The recovery record should answer three questions:

1. What is definitely complete?
2. What is uncertain or invalid?
3. Who owns the next action?

A fresh context should be able to resume without replaying the entire original conversation. It should receive the objective, the current state, the evidence already produced, and the unresolved decision. Otherwise the failure is the same one described in The Problem Is Not Prompting. It Is Context Decay.: the code survives, but the reasoning needed to continue safely disappears.

If recovery depends on the operator reading terminal history and reconstructing the story from memory, the system has moved work around without creating continuity.

The success condition is not that no worker fails. It is that a failure becomes local, visible, and recoverable.

Measure three costs, not just throughput

A multi-agent workflow can complete more actions while making the solo developer less able to understand what is happening.

I will group the cost of the factory into three categories.

Direct cost includes model and infrastructure spend, delegation latency, and the time required to configure or maintain the runtime. This is the operating counterpart of AI Makes Building Cheaper Before It Makes Running Cheaper: cheaper execution does not automatically mean cheaper ownership.

Continuity cost includes reconstructing context, repairing handoffs, restarting sessions, and determining what has already been done.

Trust cost includes redundant work, ambiguous status, difficult failure diagnosis, and the time required to gain confidence in the final result.

The baseline matters here. If the layered workflow takes longer but produces a clearer recovery record and a more independent review, that may be a good trade. If it merely adds waiting and supervision around the same unverified patch, it is not.

The decisive measure is not raw throughput. It is whether the total operating cost buys better continuity and stronger verification.

Define the decision before running the task

The pilot should not be interpreted only after the result is known. I need criteria before the comparison starts.

Keep the architecture if it produces reviewable artifacts, makes handoffs clearer, allows a fresh context to recover bounded work, and does so at an operating cost I can sustain.

Modify a layer if its responsibility is useful but its implementation creates unnecessary friction.

Replace or remove a layer if it increases configuration, supervision, or recovery work without improving continuity, trust, or quality evidence.

Add a control-plane layer only when tool access, credentials, MCP servers, policy, or observability have become an actual operational problem.

This gives the architecture an exit condition. Choosing it is not a promise to defend every component indefinitely.

The result I am looking for

I am not trying to prove that more agents are better.

I am testing whether a deliberate division of responsibility helps a solo developer carry software work across contexts and interruptions without losing the objective, the evidence, or the next decision.

A working agent can produce a patch.

A working factory should preserve enough of the work around that patch for another step—or another context—to continue without archaeology.

That is the standard I will use. The pilot may confirm the architecture, change one of its boundaries, or show that a simpler workflow is better for some classes of work.