A standby is not yet a successor

Work demonstrated September 25–26, 2026 (UTC)

A clean spare agent is useful only if the system knows when it may become a replacement. In Cold Fortress’s multi-agent pool, that decision depends on confirmed cleanup of the retired instance. A controlled trial tested the boundary by making destruction temporarily unavailable: spare capacity existed, but the system withheld a successor until cleanup could be completed.

The pool milestone, completed on September 26 within its prototype scope, extends the earlier single-agent workflow to two assigned agents and two clean standby containers. A standby has no task, assigned identity, conversation, or network access. It is prepared capacity, not an agent already authorized to act. The trusted controller separately manages assignment and admission to the communication interface.

For the destruction-outage trial, two real reading requests were active. One concerned the stated purpose of example.com; the other asked whether example.org could be registered. The test deliberately forced one instance to contact the handler early and temporarily caused its destruction operation to be rejected. These were injected test faults, not evidence that the model spontaneously attempted an attack.

Only the targeted instance was permanently disqualified. Its old connections were denied, and the controller did not create its successor while destruction remained unavailable. Once the destruction service was restored, the recorded sequence showed confirmed cleanup before fresh provisioning. The other reading retained its original identity and rendezvous schedule. Both requests subsequently produced admitted results, and the protected answers were reviewed against the actual source snapshots.

That sequence tests a different property from simply demonstrating that a spare can start. A controller that treats an attempted cleanup as a completed cleanup can release capacity too early. Here, uncertainty about destruction kept the affected assignment waiting. The observation supports the narrower claim that this tested failure path preserved the cleanup prerequisite while leaving the sibling’s authority unchanged.

The trial also exposed a distinction in the evaluation itself. The original agents had overlapping rendezvous windows, but the replacement’s window did not overlap the sibling’s. A strict pairing check therefore failed. The later review established the individual recovery outcomes without rewriting that original assertion as a pass. Concurrent starting conditions and completion after replacement are related observations, but they are not interchangeable.

The broader pool completion review also records successful empty-pool queueing, interrupted-assignment recovery, and rollback to the earlier implementation followed by restoration of the pool. Its final audit found two clean standbys and no active test agents or pending cleanup at that time. Those are dated milestone observations; subsequent experiments have continued. Unexpected management failures remain unexplained, and the containers still share a host and its failure domain.

The contribution is a more explicit separation between readiness and authority. Preparing a spare can happen ahead of demand. Authorizing it to inherit an assignment must wait for evidence that the previous instance has been removed. In this trial, the system preserved that ordering even when doing so delayed recovery.