Failure is a capability.
Reliable agent systems don't prevent every failure. They make attempts throwaway while keeping the responsibility, the evidence and the way forward.
We usually describe reliability as not failing. The server stays up, the function returns, the agent gets it right first time. That's fine for machines where we already know what correct looks like. It's a dangerous definition for research, design, strategy, debugging, or any work where finding out an approach is wrong is part of making progress.
A scientist who never writes down a failed hypothesis isn't unusually reliable. A designer who never throws away a sketch isn't unusually efficient. They're probably just hiding the search. Open-ended work is full of attempts that are supposed to fail. The real question is whether a failure wrecks the work, poisons future thinking, or leaves an expensive mystery for someone else to solve.
Restless splits a lasting responsibility, which we call Work, from the Attempts made to finish it. I know that sounds like admin. In practice it changes what the system can risk, remember, recover from and learn.
Getting it right first time is a bad goal
If you train an agent to optimise for finishing on the first pass, you reward some bad habits. It narrows the task until whatever it already has looks good enough. It treats uncertainty as weakness. It picks checks that confirm what it already did. And whenever things get ambiguous, "can you clarify?" becomes the safest escape hatch.
You end up with something that runs smoothly and thinks badly. The task goes from active to done with no errors, but nobody ever questioned the central assumption. The website builds, but nobody opens it. The market report has citations, but the citations don't support the recommendation. The migration works on my machine, but the thing it triggered out in the world can't be undone.
The fix isn't "fail more". It's "be clear about what a failure costs and what it means". Some attempts should be cheap probes. Some should be full production candidates. Some should stop before anything irreversible happens. Reliability comes from matching the attempt to what you actually know, then keeping enough evidence to choose the next move.
Work and attempts live for different amounts of time
Work is one actor's lasting responsibility for an outcome, an expected result and a specific workspace. It survives a model call, a worker process, a restart and a rejected draft. An Attempt is one claimed go at a specific version of that Work. It can finish, fail, get interrupted or get replaced.
Mix the two up and you get two kinds of mess. If the task dies with the process, a crash erases who was responsible, and someone has to piece together what was going on. If every retry scribbles over the same record, the accepted result loses its history. Nobody can tell which evidence belongs to which version, or why the last one got rejected.
Splitting them gives failure an address. A failed attempt keeps its inputs, outputs, logs, checks and the reason it was rejected, while the Work stays open. The next attempt gets the current goal, the relevant failure evidence, the remaining options and any new constraints. It carries on the responsibility without pretending the last attempt never happened.
What didn't work is still useful
Teams tend to keep the thing that worked and bin the path that didn't. That gives you a suspiciously clean history. Future workers repeat the same weak search, reuse the same broken dependency, or bring back a direction the owner already said no to, because the company kept the output but not the reason.
A useful failed attempt says what was being tested, what actually happened and what changed because of it. "The animation felt wrong" is hard to reuse. "At 390 pixels wide the pinned scene covered the next section, and reduced-motion mode left the explanation blank" is something a future attempt can actually work with. It says where it broke and what the next version has to keep.
That doesn't mean every failure should get stuffed into every future brief. Failures need a source, a reason to be relevant and an expiry date. A failed approach against an old library version probably doesn't matter any more. A rejected brand direction might matter for years. Remembering well includes knowing what not to bring up.
Recover from what's true, not from vibes
When an attempt fails, the lazy instruction is "try again". It's usually too vague. Give a new worker the same brief and the same hidden assumptions, and you'll often get a slightly different-looking version of the same bug. Give it the whole transcript, and the useful bit gets buried under abandoned reasoning and noise.
Recovery in Restless is meant to be focused. It can include the original goal, the current accepted version, what's been tried, the exact outputs, the failure evidence, dependencies, the remaining budget and what the worker is allowed to do. The recovering worker should propose the smallest repair that could work, not restart from scratch by default.
This is where solid state and model judgement meet. Plain software can tell that an output is missing, a check failed, an attempt limit was hit or a dependency changed. It can't always decide whether to narrow the scope, swap the worker, change approach or take a trade-off back to you. Recovery needs evidence small enough to think about and structure solid enough not to lose the result.
Getting interrupted isn't the same as failing
Processes stop for boring reasons. The machine restarts, the provider times out, the budget runs out, a login expires, or you change your mind. Treating every interruption as proof the work was wrong is wasteful. Treating it as proof nothing happened is worse, especially when something outside the company was involved.
Internal work and outside consequences recover differently. You can restore a workspace from a snapshot. You can't unsend an email. If a request times out after the provider might have accepted it, the honest state is "unknown", not "failed". A blind retry can do the thing twice. Recovery has to check with whatever holds the real answer and attach the result to the same original intent.
That's one reason Restless keeps its record of authority and outside actions separate from the company computer. The computer can roll back in time. The outside world can't. A recovered attempt has to start from what's currently true in the company and out in the world, even if its files went back to an older snapshot.
Failure budgets should count consequences, not just tries
Attempt limits are useful, because endless retries burn money and time while looking a lot like persistence. But a flat retry count says very little. Three cheap local builds aren't the same as three public deployments. A failed search isn't the same as a payment that might or might not have gone through.
A sensible budget thinks about whether it can be undone, what you'd learn from another try, what it costs and what's at stake. Keep going when the next attempt tests a genuinely different idea at a reasonable cost. Stop when it's going in circles, the next step needs new permission, the evidence has turned up a strategic trade-off, or something out in the world can't be safely reconciled.
You shouldn't get pinged just because a counter hit zero. When it comes back to you, it should say what was tried, what was learned, what options are left and why it now needs your judgement. A blocked task can still be a useful outcome if it boils the decision down for you.
- Retry when the next attempt changes something that matters.
- Recover when the responsibility still makes sense but the process doing it fell over.
- Revise when the evidence changes what done means.
- Bring it back when the remaining choice depends on authority, taste or appetite for risk.
If you can't admit failure, you can't learn
Agent systems pick up whatever incentives we build around finishing. If only accepted outputs survive, workers learn that a clean ending matters more than an honest account. If every failed check is treated like misconduct, the system learns to pick weaker checks. The database might be neutral. The culture around it isn't.
Restless treats what it observes as suggestions for how the company could change, not automatic rewrites. Repeated failure might mean you need a different model, better context, a new tool, a narrower role or an independent reviewer. One failure might just be noise. The system should keep enough structured evidence to spot a pattern without turning every incident into a permanent rule.
That restraint matters. A company that answers every failure with a new gate eventually can't move. A company that learns nothing repeats itself. The useful middle is clear evidence, someone accountable making the call, and changes you can undo.
Reliability belongs to the whole loop
A worker can be unreliable while the company stays reliable. It can explore a bad path, show why it failed, and hand back enough evidence for the next attempt to succeed. Flip it around and a worker can complete every step perfectly while the company fails, because the steps never added up to anything useful.
That's the shift from "did the task run" to "can the company be relied on". The system keeps the goal, names who's responsible, ties evidence to specific attempts, controls things that can't be undone, and brings unresolved calls back to the right person. Individual intelligence is allowed to be fallible because responsibility isn't allowed to disappear.
Failure becomes a capability when it lets the company try more without dumping more chaos on you. That's not tolerating bad work. It's the machinery that makes ambitious work possible.