LoopRelay

Software engineering was never syntax alone; code is one means of applying rigorous problem solving. As coding agents made implementation abundant, it stopped being my limiting resource. Engineering judgment became scarce: deciding what should exist, shaping the solution, and recognizing when a coherent implementation was moving toward the wrong result.

Manual implementation builds the engineer’s cognitive model through construction: every local choice reinforces an understanding already taking shape. Microscopic supervision of agent-written code reverses that process. To judge an unfamiliar choice, I must reconstruct the reasoning that produced it after the fact. At high throughput, repeated reconstruction creates fatigue and a subtle bias toward accepting the agent’s locally coherent solution, because challenging it requires rebuilding the system in my head.

LoopRelay began from the opposite premise: the engineer should remain the author of the solution. Autonomous implementation should be bounded by research, architecture, goals, invariants, constraints, and explicit non-goals the engineer has shaped. Preserving those inputs across execution keeps the cognitive model formed during design connected to the codebase taking shape. Intent remains a continuing constraint, not an aspiration left behind when implementation begins.

AI should commoditize implementation, not authorship.

That does not make the work automatically correct. The engineer must still evaluate, steer, and sometimes delete. Judgment should be applied at stable, bounded plateaus, where architecture, behavior, evidence, and trajectory can be assessed together—not through task-level supervision that continually demands reconstruction of the agent’s reasoning.

The manual relay had already shown this division of labor could work: I remained responsible for direction and architecture while focused agents implemented bounded tasks. Its failure was mechanical. Carrying context, decisions, and results between tools began consuming the attention the workflow was meant to preserve.

I kept a continuing ChatGPT conversation for research, prior-art analysis, architecture, and solution design, then used separate Codex sessions for bounded implementation. For each session I assembled the current plan, milestone, constraints, and handoff; afterward I carried changed repository facts and new questions back into the reasoning context.

The loop depended on three distinct roles:

• the continuing reasoning context preserved why the system should take a particular shape;
• the focused execution context made one bounded part of that shape real;
• I decided what mattered and transported it between them.

With three to five agents active across several repositories, prompt construction, artifact transport, session restoration, and handoff tracking displaced research and solution design. The reasoning and execution roles were useful; manually carrying state between them did not scale.

The workflow did not fail. It became productive enough that operating it interfered with the engineering it was meant to amplify.

Prompt-launching scripts reduced keystrokes, not the work. They could start another agent session, but they could not determine which artifacts were current, preserve the relationship between an attempt and its repository effects, carry newly learned context forward, or restore progression after an interruption. The missing capability was not another launcher. It was a restartable runtime for the relay.

That defined the automation boundary. I would still supply the problem, adopted architecture, constraints, non-goals, and course corrections. The runtime would restore state, assemble the next bounded context, record the attempt and available result, and stop where continuation, recovery, or judgment could begin from durable facts.

Implementation Inspect the implemented relay →

The authoring process may begin with deep research, a concept developed through many turns of discussion, or both. I use AI to ingest prior art, challenge assumptions, compare alternatives, expose missing questions, and keep the emerging solution connected to the problem that motivated it.

That conversation is not yet a specification. Once the reasoning is mature enough, I ask AI to extract a candidate artifact set from it: purpose, architecture, capability boundaries, goals, invariants, constraints, non-goals, evaluation criteria, known uncertainty, and the evidence that should distinguish progress from completion.

AI makes that externalization faster. It does not make the result authoritative.

Engineering concept

↓

Deep research and prior-art analysis

↓

Extended AI dialogue and challenge

↓

AI synthesizes candidate artifacts

↓

Engineer reviews, revises, rejects, and adopts

↓

Authoritative context enters LoopRelay

I review the candidate artifacts manually. I remove unsupported certainty, resolve contradictions, restore context that synthesis compressed away, reject additions that do not serve the intended outcome, and revise the language until the artifacts express a solution I can defend. Only then do I adopt them as the governing model for implementation.

Generated artifacts cannot authorize themselves.

Authorship is not a count of who typed each sentence. It is responsibility for the model that the implementation is allowed to realize. AI may propose, synthesize, and draft; I remain responsible for deciding what the system should become and for accepting the consequences of those decisions.

This adoption boundary matters because autonomous implementation will optimize against whatever context it receives. If the artifacts remain vague, contradictory, or merely plausible, the agent silently becomes the author of the actual system. If the engineer has reviewed and adopted a coherent model, LoopRelay can carry that model across bounded decisions and executions without pretending that the runtime invented the direction.

LoopRelay begins after this boundary. Once the artifacts are adopted, the runtime can separate them by consumer and lifecycle, carry them into bounded work, preserve newly learned information, and return the resulting trajectory for evaluation. That is the operating model described next.

The adopted artifacts are separated by consumer and lifecycle:

• the context contract under .agents/ctx/ carries durable purpose, capability boundaries, invariants, authority, evaluation criteria, drift risks, and shared vocabulary;
• the active epic, specifications, plan, details, and milestones bound the body of work currently being implemented;
• current decisions, handoffs, operational context, and operational deltas carry what the next bounded transition needs to know.

This keeps durable intent visible without making every transition inherit the project’s complete history.

Authority is separated as well. Human-facing collaboration products remain inspectable beside the work. Git and the filesystem establish source, branch, commit, cleanliness, and publication facts. SQLite preserves the causal record of runs, attempts, exact prompts, dispatches, accepted products, effects, recovery, and completion. Codex proposes work inside that system; its response does not replace any of those sources of truth.

LLM output is evidence, not truth. Only interpreted, validated, freshness-checked, promoted output can advance state.

At the beginning of each cycle, LoopRelay reconstructs the current state from durable records and repository reality. It selects one eligible transition, freezes the inputs that authorize it, and durably records the exact attempt, rendered prompt, provider profile, and dispatch intent before any outward call. That write-before-dispatch boundary gives an interrupted attempt a stable causal identity instead of reducing it to a missing console response.

In a representative provider-backed implementation transition, Codex may change the working tree during the authorized attempt. Those changed files—and the model’s account of what it completed—do not automatically become accepted workflow state. LoopRelay records the raw result, derives and validates candidate evidence, and rereads the inputs that authorized the attempt. If those inputs became stale, the candidate evidence is retained but product promotion is denied. Otherwise, accepted products and required effect intents are durably promoted together, the effects are settled against observed postconditions, and the repository is re-observed before progression.

One durable transition at a time

Observe and restore current state

↓

Select and authorize one transition

↓

Execute one causal attempt provider-backed implementation may change the working tree

↓

Interpret, validate, and promote accepted products

↓

Apply or reconcile recorded effects

↓

Re-observe and determine what is legal next

↙ More work Return to transition selection

↓ Wait, recover, or human action Stop at an explicit boundary

↘ Certified close Terminal evidence

Within execution, a durable decision context combines the accepted plan, current repository facts, and previous handoff into the next bounded decision. When provider identity and policy still match, that context can resume across separate CLI invocations without passing the entire accumulated history to the next attempt.

One transition is one eligible state change. A bounded traditional, eval, plan, or execute invocation advances at most one; a run invocation may advance several within the same durable root run before certified completion, its continuation limit, or another safe stop. A later process restores that run from durable state. One chain selects one epic, and certified closure does not automatically begin another.

Sustained first-party use exposed the judgments that manual supervision had previously resolved implicitly. Turning those judgments into explicit authority, recovery, effect, and evidence boundaries produced the architecture that followed.

Implementation Inspect current invocation and run behavior →

Context must survive without becoming permanent clutter

Task-only prompts encouraged local optimization and drift; the complete accumulating history made later work slow and incoherent. The correction was explicit consumers and lifecycles: .agents/ctx/ preserves long-lived intent, active epic artifacts bind current work, and decisions, handoffs, context, and deltas carry what the next transition learned. Permanent artifacts still cannot contradict repository reality.

A completion report is only a claim

An agent can change files, tick milestone boxes, report success, and exit while required state remains incomplete. Process completion proves only that an attempt ended. Checked boxes are a completion claim. Output remains a candidate until canonical promotion. None proves the implementation correct.

Where a boundary can be explicit, invariants, verifier version, negative controls, evidence, and freshness conditions are fixed before implementation. A versioned certification verifier inspects canonical state and binds its receipt to the repository commit plus build, catalog, schema, configuration, and exact-profile identities. Relevant change makes that proof stale.

Implementation Inspect the versioned certification verifier →

LoopRelay’s generic completion path still asks an LLM to judge semantic completion and drift. Parsing, policy checks, and routing are deterministic; that judgment is not. A second model adds diversity, not proof.

An agent may propose implementation and explain evidence. It cannot mint the receipt that authorizes completion.

Without explicit invariants and independent oracles, verification remains an engineering responsibility.

Three different questions

Canonical sources Collaboration files · Git facts · SQLite causal state

↓

Observe What does the current state actually say?

↓

Verify Does that exact state satisfy the declared invariants?

↓

Authorize progression Given the state and valid evidence, what may legally happen next?

↓

Continue

Wait

Recover · Human review

Model output contributes evidence; it is not another canonical source.

Canonical state is divided by fact type

No universal artifact overrides every source of truth. Collaboration files own their observed bytes. Git and the filesystem own repository and publication facts. SQLite owns causal orchestration facts. Provider output remains evidence until interpreted, validated, freshness-checked, and promoted.

Implementation Inspect canonical re-observation →

The runtime rereads those authorities around selection, execution, promotion, effects, and closure. A correct answer to an obsolete prompt cannot be promoted, and a file’s existence does not prove its producing transition completed. Observed state—not the agent’s narrative—supports continuation, waiting, recovery, or closure.

A lost response does not mean nothing happened

Provider idempotency protects the provider request, not local workspace semantics. A lost response may leave:

• some files updated while others remain untouched;
• partial file writes;
• renames without the corresponding metadata change;
• untracked files or Git-index mutations;
• commits or generated artifacts created before the disconnect;
• or a valid implementation whose provider response simply never arrived.

Blind replay could layer a second execution over unknown state. The runtime persists attempt identity, exact inputs, rendered prompt, provider profile, and dispatch intent before outward action. A missing final result makes the outcome unknown, not unchanged. Recovery preserves the causal record, observes repository reality, and reconciles effects before any new authority is granted.

Persist exact attempt and dispatch intent

↓

Authorize one outward attempt

↓

Final provider result unavailable

↓

Workspace outcome is unknown

↓

Blind replay is blocked

↓

Observe and reconcile existing effects

↓

Resume, reuse, or reconcilewhen a matching mechanism can resolve the state

New attemptonly after explicit authority and lineage

Human actionwhen ambiguity remains unresolved

LoopRelay preserves the attempt, exact prompt, dispatch, session, and effect identities needed to investigate an interruption, and an unknown outcome cannot silently become another provider call. Some bounded paths can resume an exact supported session, reuse already durable raw output, or reconcile a recorded effect against its observed postcondition. Those capabilities are specific rather than universal. When provider disposition, repository changes, effect state, or available evidence cannot be resolved by an implemented recovery path, the runtime stops for explicit human action instead of fabricating success or authorizing a blind retry.

In those cases, the operator may still need to correlate the recorded provider request, inspect Git and the working tree, check external-effect postconditions, and decide whether to wait, preserve or import existing work, revert it, or authorize a new attempt with explicit lineage. The runtime reduces reconstruction by retaining the causal record and narrowing the uncertainty; it does not eliminate the engineering judgment required to resolve every ambiguous outcome.

Implementation Inspect the unknown-outcome boundary →

External effects require receipts

Logical acceptance and external settlement are different boundaries. File promotion, commits, pushes, parent-and-child publication, archives, and completion materialization are recorded before execution and settled only after observed postconditions. Accepted work may still have pending, partial, or unknown effects; progression waits for receipts or reconciliation.

Nondeterministic implementation can still be surrounded by deterministic identity, authority, observation, and progression.

Proof must cross the boundary named by the claim

An internal component test may prove its contract without proving the published CLI reaches it. A generated completion artifact cannot be its own sole proof. Evidence must cross the boundary named by the claim.

The separate LoopRelay.Certification.exe harness invokes the built executable against disposable repositories, observes external state, applies claim-specific oracles, and retains evidence. Some cases are deterministic; others cross the live provider boundary.

Component contracts

↓

Replay and recorded-boundary evidence

↓

Published CLI transition evidence

↓

Live multi-boundary chain

↓

Claim-specific certification

Certification Inspect the full-chain certifier →

These controls do not establish universal correctness. They return repository state, causal history, and evidence coherent enough for engineering judgment to recognize convergence—or drift.

It could make the system accountable. It could not decide whether I was building the right product.

The backend needed several significant course corrections, so that was where I kept most of my attention. At the same time, I had already created and exported a high-fidelity React bundle in Claude Design that looked like the interaction model I wanted. I treated that bundle as evidence that the design problem was largely solved. I expected Codex to adapt the running application until it matched the design.

I put too much faith in that expectation.

A convincing design target did not mean the running implementation was converging toward it or that the interaction model would still make sense once connected to the rest of the system. Yet I let implementation accumulate without exercising the running product as an integrated system.

When I finally ran the integrated application, the implementation had not converged on the high-fidelity design I believed it was moving toward. Every individual segment of agent output appeared as a metadata-heavy card roughly twelve rows tall, making the primary execution log initially unreadable. Potentially useful detail had been exposed indiscriminately until it overwhelmed the execution flow the interface was supposed to make easier to follow.

That was the implementation failure.

The product failure was deeper.

The intended product was much narrower: automate the Decision Session → decisions.md → one human review or revision → Execute loop I had already been operating manually. The artifacts supporting that loop existed to carry durable intent, context, and decisions for the automated system. They were not meant to become a collection of products the engineer had to browse, interpret, and operate.

Instead, execution and narrow supporting capabilities became independent systems and interface surfaces. Execution, operational context, decisions, reasoning, governance, continuity, economics, and explainability each became a separate part of the product the engineer was expected to operate.

Each addition could be defended in isolation. Together, they changed the user’s job.

The product was supposed to remove coordination, not give coordination a richer interface.

AI did not impose that expansion on me. AI-assisted roadmaps proposed plausible additions, and I was too willing to accept them because each was presented as a helpful way to support the loop. I did not verify aggressively enough that the abstractions in those plans still implemented the behavior I had actually requested. Agent implementation choices then materialized the accumulated scope directly in the interface.

The result was increasingly complete according to its own architecture and increasingly incomplete according to its purpose.

How the failure formed and became visible

Backend corrections retained attention significant course corrections remained

↓

Claude Design target trusted high-fidelity exported React bundle

↓

Codex adaptation assumed running application expected to match the design

↓

Integrated application validation deferred the running product was not exercised early enough

↓

Running application reveals visual mismatch metadata-heavy cards overwhelm the execution log

↓

Accumulated surfaces reveal interaction-model failure execution · context · reasoning · governance · decisions · continuity · economics · explainability

↓

Simplification attempted local corrections do not change governing assumptions

↓

Salvage has lower expected return than retirement restore the CLI-first relay

Why steering it back did not work

I did not see the frontend and immediately decide to delete it.

I tried to reduce individual surfaces, push the application toward the simpler interaction model I wanted, and concentrate human attention on consequential judgment rather than routine operational detail.

Those corrections changed local details without changing the assumptions distributed throughout the product. The unwanted functionality, proliferating visual elements, metadata-heavy cards, and separate reasoning and governance machinery remained embedded in the interaction model. The existing frontend was not shaped for efficient simplification.

At that point, the choice was not between keeping a finished product and abandoning the vision. It was between continuing to accommodate an implementation whose assumptions conflicted with the workflow, or returning to the CLI as the more direct path to a functional product.

Continuing to repair the implementation offered lower return than dropping the frontend and returning to the CLI.

That reset was not a new direction. It restored the original automation target: the narrow relay derived from the manual workflow. I had let backend demands delay integrated validation, trusted the design bundle as evidence of progress, placed too much confidence in Codex’s adaptation, and accepted too much AI-proposed scope before seeing what it meant as a product. Repeated local correction did not undo those decisions.

The frontend was not retired merely because it looked bad. It was retired because it neither matched the intended design nor preserved the product boundary that had justified building it.

What survived the failure

The failure did not invalidate human-in-the-loop engineering.

Loop Relay began with an explicit opportunity to review and revise a generated decision before the next execution session. The current CLI does not provide that boundary as intended because execution proceeds immediately after decision formation. I accept that limitation for short-term productivity, but the current level of autonomy is not my finished answer to the relationship between judgment and execution.

What survived is the requirement for meaningful, dynamic, context-rich escalation. The system should interrupt when its available context is insufficient to preserve intent or converge on the actual goal, and when impact or uncertainty makes autonomous action unjustified. It should equip the human with enough relevant context to make a meaningful decision while keeping routine operation quiet.

The default surface should remain minimal. Deeper evidence should be available through progressive disclosure. Human attention should not require drinking from an information firehose or responding to a stream of binary approval prompts.

The intended experience survived. No interaction from the deleted application should be treated as proven.

The lesson

The failure changed how I evaluate AI-generated plans: internal coherence is not evidence of product convergence.

I had been too willing to accept plausible additions because each appeared to support the loop. The relevant question was not whether each idea made sense within the roadmap, but whether the roadmap still implemented the product I had requested.

The revised standard is not literal obedience to an initial design. Implementation should adapt to repository evidence and to what is learned during development. But it must remain recognizably connected to the purpose, constraints, and architectural direction that authorized it. It should land in the same ballpark as the design, not in a different galaxy.

The failure reinforced the need to test the integrated interaction model before supporting scope and architecture accumulate around unvalidated assumptions.

A useful addition that weakens convergence is still product drift.

The retirement commit removed 92,829 Git-counted text lines across the Command Center UI, backend, shell, middle, workflow, tests, and supporting generated or mock material. That number establishes the repository scope of one correction. It does not establish the effort, value, economics, or wisdom of either the implementation or its removal.

Immutable Git evidence Inspect the 92,829-line Command Center retirement →

The principal sacrifice was accepting that Loop Relay would have no human-in-the-loop interface in the short term even though meaningful HITL escalation remained part of the intended product. I still wanted the capability. I no longer believed this application was the highest-return path to it.

I deleted an interface I wanted because keeping it delayed the workflow I needed.

AI-assisted implementation changes the economics of accumulated code. It lowers the marginal cost of generating large implementation surfaces, but those surfaces are not free to understand, validate, integrate, maintain, or carry forward as context. Every retained artifact becomes another assumption that later work must understand, reconcile, avoid contradicting, or deliberately remove.

Cheap generation does not make preservation free.

Repeated attempts to simplify the application had not removed its unwanted functionality or changed the assumptions governing its interaction model. Continuing to repair it meant continuing to preserve the same architecture that had turned internal coordination machinery into a product the engineer had to operate.

Returning to the CLI restored the narrow automated relay more directly.

What deletion corrected

The reset re-established the intended distinction between the product and the machinery supporting it.

Workflow artifacts carry durable intent and context for automation; they are not routine user interfaces. Human attention belongs at meaningful judgment boundaries, not every operational transition. Internal explainability does not need to remain continuously visible. A capability does not justify itself merely by being useful in isolation if its combination with other capabilities changes the user’s job.

Most importantly, implementation remains subordinate to the purpose that authorized it.

The system was coherent. It was still the wrong system.

Deleting it restored agreement between the implementation and the narrower product intent. It returned Loop Relay to the workflow it had started to automate rather than asking the workflow to accommodate the product that had grown around it.

What deletion did not correct

Deletion did not make the preceding expansion economical or erase the failures described above. I accepted adjacent scope, overtrusted the design-to-implementation path, and delayed integrated validation. Retirement corrected the product boundary; it did not redeem the decisions that made retirement necessary.

Nor does this prove that large-scale deletion is generally better than adaptation. The threshold depends on the maturity of the product, whether it is already in production, what obligations it has to users, and whether the implementation is shaped for economical correction. Command Center was new, non-production, wrong for the intended outcome, and not shaped for economical adaptation.

Under those conditions, continued accommodation offered less value than removal. I prefer to cleave rather than chisel.

AI lowers the marginal cost of implementation. It should also lower our attachment to coherent work that no longer serves the goal.

What remains unfinished

The CLI-first correction restored the usable workflow while leaving an important human-authority boundary incomplete.

Loop Relay currently executes immediately after decision formation. Normal course correction happens between operations. If I need to intervene during an active operation, I can kill the CLI session, but that is an inelegant emergency path rather than the intended interaction model.

A future interface must be earned independently. It should not inherit the deleted application’s information architecture merely because that work once existed. It should evaluate context sufficiency, intent preservation, impact, and uncertainty, then ask for human judgment only when that judgment can materially change the trajectory.

The requirement remains:

Meaningful, dynamic, context-rich escalation through a minimal surface with progressive disclosure.

Deleting the wrong product did not abandon the vision. It separated the vision from an implementation that could no longer carry it.

The public telemetry bundle reproduces its summary from sanitized turn records, and the Luna R4 artifact reproduces its summary from retained TRX and certification evidence. Both publish manifests, derivation scripts, per-file checksums, limitations, and archive digests.

The telemetry export minimizes disclosure: exact timestamps and repository identities are pseudonymized, while prompts, responses, credentials, confidential content, and unnecessary local paths are excluded. Its derivation recomputes turn types, repository count, sessions, and effective-token totals from the published JSONL. It cannot prove that the private source telemetry was complete or authentic.

The Luna R4 result is bound to base commit 369f930773e316d8e52db101275aed09c0422d04, the included working-tree patch and three intentional untracked source files, and source fingerprint 4c47ccf5f2dc7bc5d6e473b899f5f746c320939050b7eedf4b48284f7bfab2a8. The campaign used .NET SDK 10.0.301, a Debug net10.0 build, Codex 0.144.5, and the gpt-5.6-luna medium profile. Those identities make the result reproducible and deliberately finite.

The public repository exposes orchestration behavior, authority boundaries, state persistence, recovery, certification code, and current limitations for direct inspection. The executable full-chain certification fixture invokes the assembled product against disposable repositories, observes external state, and applies claim-specific oracles, allowing a technically interested reader to exercise the configured workflow without preparing a real project corpus.

The fixture demonstrates that configured workflow and its oracles. It does not establish arbitrary semantic correctness, real-project usefulness, universal reliability, or favorable economics.

Certification fixture Inspect the executable full-chain fixture →

At the audited source revision, the CLI restores durable root runs, carries roadmap work into planning and bounded execution, records attempts before dispatch, promotes accepted products, settles recorded effects, and certifies closure. Those exercised paths make the runtime useful in my practice; they do not imply that every declared route or recovery action is complete.

The most important missing capability is dynamic, context-rich human escalation. The CLI proceeds from an accepted decision into execution without a general engineer-approval state. When judgment must change direction, the practical control is to stop the process, revise the governing context or handoff, and resume from newly observed state.

The current system preserves a place for judgment. It does not yet summon that judgment intelligently.

Verification remains bounded as well. Explicit domain invariants can be checked by versioned verifiers against exact repository and lifecycle revisions. The generic completion path, however, still uses an LLM for semantic completion and drift judgment before deterministic parsing and policy checks. Claims that cannot be reduced to independent invariants remain the engineer’s responsibility to evaluate.

Unknown outcomes are preserved rather than converted into retries, but generic recovery is not fully automated. LoopRelay can retain the exact causal record, classify the uncertainty, persist a recovery plan, and block blind replay. Exact session resume, durable raw-output reuse, and effect reconciliation exist only where their corresponding mechanisms are implemented. Broader cases can still require an operator to inspect provider history, repository state, and effect postconditions before choosing a safe disposition.

Current security boundary

The provider boundary is narrow for a separate reason. LoopRelay isolates provider-specific behavior from the orchestration model, but the exercised path remains Codex-focused. Architectural replaceability is not behavioral parity with another provider.

The autonomous horizon is one selected epic. Longer execution compounds stale context, unresolved effects, semantic drift, cost, and permission risk; multi-epic automation would require configurable budgets, mandatory review, fresh verification, risk-sensitive stops, and escalation.

Longer autonomy requires a stronger trust boundary

Current boundary One selected epic

↓

A longer horizon compounds context drift · unresolved effects · cost · permission risk

↓

Required before multi-epic automation budgets · mandatory review · fresh proof · risk-sensitive stops · escalation

The strongest external product test remains ahead: another engineer sustaining the workflow across real work, completing a bounded epic, and producing inspectable evidence without depending on my presence. Until then, the defensible claim remains first-party.