Reliability is usually described as the absence of failure. The service stays up. The function returns. The agent completes the task on its first attempt. That definition works for machinery whose correct behaviour is already known. It becomes dangerous when applied to research, design, strategy, debugging, or any work in which discovering that an approach is wrong is part of making progress.
A scientist who never records a failed hypothesis is not unusually reliable. A designer who never discards a composition is not unusually efficient. They may simply be hiding the search. Open-ended work contains attempts that should fail. The engineering question is whether failure destroys the work, contaminates future reasoning, or creates an expensive mystery for someone else.
Restless separates a durable responsibility called Work from the Attempts made to satisfy it. The distinction sounds administrative. In practice it changes what the system can risk, remember, recover, and learn.
First-pass success is a poor objective
Optimising an agent for first-pass completion rewards several bad behaviours. It encourages the model to narrow the task until its existing output appears sufficient. It makes uncertainty look like weakness. It favours superficial checks that confirm the chosen approach. And it turns a request for clarification into the safest possible escape whenever the work becomes ambiguous.
The result can be operationally smooth and intellectually brittle. A task moves from active to complete without an error, yet the central assumption was never challenged. A website builds, but nobody opens it. A market report contains citations, but the cited evidence does not support the recommendation. A migration succeeds locally, but the external effect that followed it cannot be reversed.
A better objective is not “fail often.” It is “make the cost and meaning of failure explicit.” Some attempts should be cheap probes. Some should be full production candidates. Some should stop before an irreversible boundary. Reliability comes from matching the attempt to what is known, then retaining enough evidence to choose the next move.
Work and attempt have different lifetimes
Work is one actor's durable responsibility for an outcome, an expected artifact, and an exact workspace. It survives a model call, a worker process, a restart, and a rejected draft. An Attempt is one atomically claimed execution against a specific revision of that Work. It can finish, fail, be interrupted, or be superseded.
Conflating them creates two failure modes. If the task disappears with the process, a crash erases responsibility and someone must reconstruct what was happening. If every retry mutates the same undifferentiated record, the accepted artifact loses its lineage: nobody can tell which evidence belongs to which revision or why a previous result was rejected.
The split gives failure an address. A failed attempt can retain its inputs, artifacts, logs, checks, and reason for rejection while the Work remains open. The next attempt receives the current outcome, the relevant failure evidence, remaining options, and any revised constraints. It continues the responsibility without pretending the earlier attempt never happened.
Negative evidence is still evidence
Teams often preserve the successful result and discard the path that failed. This produces an implausibly clean history. Future workers repeat the same weak search, reuse the same incompatible dependency, or revive a direction the owner already rejected because the organisation retained the artifact but not the reason.
A useful failed attempt records what claim was tested, what was observed, and what changed as a result. “The animation felt wrong” is hard to reuse. “At 390 pixels the pinned scene covered the next section, and reduced-motion left the explanatory state blank” is durable negative evidence. It says where the failure was visible and what a future implementation must preserve.
Negative evidence should not flood every future context packet. It needs provenance, relevance, and expiry. A failed approach against an old dependency may no longer matter. A rejected brand direction may remain important for years. Remembering well includes deciding what not to retrieve.
Recovery should continue from truth, not from theatre
When an attempt fails, the easiest recovery instruction is “try again.” That is usually too vague. If the new worker receives the same brief and the same hidden assumptions, a fresh model call may produce a cosmetically different version of the same defect. If it receives the entire transcript, the useful signal may be buried under abandoned reasoning and operational noise.
Restless recovery is meant to be focused. It can include the original outcome, the current accepted revision, attempted approaches, exact artifacts, failure evidence, dependencies, remaining budget, and authority limits. The recovery actor should propose the smallest credible repair rather than restart by default.
This is where durable state and model judgement meet. Deterministic machinery can identify that an artifact is missing, a gate failed, an attempt limit was reached, or a dependency changed. It cannot always decide whether to narrow the scope, replace the worker, change the approach, or return a trade-off to the owner. Recovery needs evidence compact enough for judgement and structure durable enough not to lose the result.
Interruption is not the same as failure
Processes stop for ordinary reasons: a machine restarts, a provider times out, a budget is exhausted, a credential expires, or the owner changes direction. Treating every interruption as proof that the work was wrong leads to waste. Treating it as proof that nothing happened is worse, especially when external systems are involved.
Internal work and external consequence recover differently. A workspace can be restored to a snapshot. An email cannot be unsent. If a network request times out after a provider may have accepted it, the correct state is unknown—not failed. A blind retry can duplicate the consequence. Recovery must reconcile with the external source of truth and attach the resulting receipt to the same durable intent.
This distinction is one reason Restless keeps authority history outside the mutable company runtime. The runtime can travel backward; the outside world cannot. A recovered attempt must begin from current organisational and external truth, even when its filesystem returns to an older state.
Failure budgets need consequence, not just counts
An attempt limit is useful because unbounded retries can consume money and time while creating the impression of persistence. But a flat retry count says little about the work. Three cheap local compilations are not equivalent to three public deployments. A failed search query is not equivalent to an ambiguous payment request.
A sensible failure budget considers reversibility, marginal information, resource cost, and consequence. Continue when another attempt tests a different hypothesis at acceptable cost. Stop when the approach is repeating, the next step needs new authority, the evidence exposes a strategic trade-off, or an external outcome cannot be reconciled safely.
The owner should not be summoned merely because a counter reached zero. The return should explain what was attempted, what was learned, what options remain, and why judgement is now required. A blocked task can still produce a valuable outcome if it compresses the decision.
- Retry when the next attempt changes a meaningful variable.
- Recover when the responsibility remains valid but the producing process failed.
- Revise when evidence changes the definition of done.
- Return when the remaining choice depends on authority, taste, or risk appetite.
A culture that cannot admit failure cannot learn
Agent systems inherit the incentives we encode around completion. If only accepted artifacts survive, workers learn that clean endings matter more than accurate accounts. If every failed check is treated as misconduct, the system learns to select weaker checks. The database schema may be neutral; the operational culture is not.
Restless treats observed outcomes as proposals for organisational change, not automatic rewrites. Repeated failure may justify a different model, better context, a new tool, a narrower role, or an independent reviewer. One failure may be noise. The system should retain enough structured evidence to see a pattern without turning every incident into permanent policy.
This restraint matters. A company that responds to each failure with a new gate becomes unable to move. A company that responds with no durable learning repeats itself. The productive middle is explicit evidence, accountable judgement, and reversible adaptation.
Reliability belongs to the whole loop
A worker can be unreliable while the company remains reliable. It can explore a weak path, expose why it failed, and hand back enough evidence for another attempt to succeed. Conversely, a worker can complete every assigned step while the company fails because the steps never added up to a useful outcome.
This is the shift from execution reliability to institutional reliability. The system preserves the outcome, names the responsible actor, binds evidence to exact attempts, controls irreversible effects, and returns unresolved judgement to the right person. Individual intelligence is allowed to be fallible because responsibility is not allowed to disappear.
Failure becomes a capability when it expands what the company can try without expanding the amount of chaos the owner must absorb. That is not tolerance for bad work. It is the machinery that makes ambitious work possible.