Feynman kept finished research alive after a crash. Agent reliability is getting less glamorous

THE SIGNAL IN ONE SENTENCE

The most comforting sentence in software is not "the agent is autonomous." It is "your finished work is still here." Feynman, an open-source AI research agent maintained by Companion, released version 0.5.50 on October 18 with a small set of maintenance changes. One of them alters what happens when a research workflow loses its main process: subagents that already completed their work keep their results instead of being marked failed. That sounds like a modest line in a changelog because it is one. It is also a clean example of the reliability work that agent products need once the demo ends and people start letting them run for an hour. Feynman coordinates research workflows that can search academic services and the web, read local documents, split work across researcher, verifier, reviewer and writer roles, and save outputs plus provenance files. Its documented commands include literature reviews, deep research, paper audits, replication plans, source comparisons and bounded experiments. A workflow like that is not one model call. It is a small production system. Several tasks may be running. Each task can contact a provider or source. Some return quickly. Others time out, refuse, hit a rate limit or discover that a paper cannot be fetched. The parent process has to keep track of who is working, who finished, what evidence came back and whether the final synthesis is still allowed to proceed. When the parent dies, the naive thing is to paint the whole run red. That is easy to implement and terrible for the person waiting on the work. A researcher may have already found the relevant papers. A verifier may have checked the central claim. A reviewer may have produced a useful critique. If those completed results are relabeled as failures merely because the coordinator disappeared, the system loses both time and evidence. Version 0.5.50 changes that outcome for completed research subagents. Their work stays completed. The plain signal is this: reliable agents need durable state transitions more than they need another adjective. Completed should mean completed. Failed should mean failed. Unknown should mean the system does not know. Those states should survive the death of whatever process happened to be watching them. The release note does not claim that every active subagent resumes, that every tool call is replayed safely or that an entire research workflow can be restored from any interruption. It says finished research subagents keep their results when the main process dies. That boundary matters. Preserving a completed result is recovery of evidence. Resuming unfinished execution is a larger problem. A task may have been halfway through a search, waiting on a model response or preparing to write a file. Restarting it could duplicate a paid request, overwrite an output, send the same query twice or produce a result from a different model version. A mature workflow needs to distinguish three questions. First, what finished before the failure? Second, what was in progress? Third, what can be retried without creating a second side effect? Research agents are friendlier than purchasing agents because many actions are read-only. Searching Crossref twice is annoying. Charging a card twice is a different category of bad day. Even in research, duplication is not free. It spends tokens, uses rate limits and can muddle provenance when two retries return different source sets. That makes the preserved result more than a convenience. It is a unit the system does not have to buy again. The same release trims prompt overhead. Sessions that have not delegated work no longer send the definitions for the background-wait and subagent-supervisor tools with every request. The project estimates that this saves about 1,500 characters per request. Characters are not tokens, and saved prompt text does not translate into one universal cost number. Tokenizers differ. Providers charge differently. Cache behavior matters. A request that never uses a supervisor should not repeatedly pay to describe one, though. That is the right instinct: capability should carry an operating cost only when the capability is available and relevant. Version 0.5.49, released October 17, made the same layer less wasteful in two other ways. Forked research subagents reuse the parent's prompt cache, and subagent-cost reports no longer ride along in every later request. The project says parallel runs therefore use fewer tokens. Again, the release notes provide behavior changes, not an independent cost benchmark. To measure the savings honestly, a team would run the same frozen tasks before and after the update, with the same provider, model, cache policy, tools and source results. It would record input tokens, cache reads, output tokens, retries, wall time and whether the answer still passed the same checks. Cheaper prompts are not a win if the agent loses the instruction that prevents a bad action. In this case the removed tool definitions are described as unused in sessions that have not delegated, which gives the optimization a sensible boundary. Production testing still needs to verify that the tools appear when delegation begins and remain available after reloads. The project also improved visibility around the subagents themselves. Workflow lanes in the interface and the status command now show which model each subagent uses. That is observability, not decoration. If a researcher used one model and a verifier used another, the operator needs that context when comparing quality, latency and cost. If a provider deprecates a model, a run log should show which results came from the retiring version. If a cheap model handles source gathering but a stronger one writes the synthesis, that routing choice belongs in the receipt. The model name is only a start. A useful record should include the provider, stable model identifier, effort or reasoning setting, tool permissions, prompt or workflow revision, source timestamps and the application release that coordinated the run. Without that information, "the agent failed" is not a diagnosis. It is a shrug wearing a progress bar. Version 0.5.49 also changed how provider errors surface. When a provider stops a subagent with an error such as a content-filter refusal, Feynman now includes the provider's reply so the operator can distinguish a refusal from an outage. That distinction prevents stupid retries. A service outage might justify waiting and trying again. A policy refusal may require changing the task, removing unsafe material or routing it to a person. Treating both as a generic failure encourages the workflow to hammer the same provider until cost and confusion rise together. Good error messages are routing instructions. Version 0.5.51, released October 19, applies that principle to local configuration. A damaged authentication file previously produced a generic JSON parsing message. The updated program names the invalid file and tells the user to repair it or move it aside and sign in again. It also points users from obsolete command forms to their current equivalents. No model intelligence was required. The software simply tells the person which thing broke and what safe recovery looks like. This is the less glamorous future of agents. It has filenames. Configuration repair deserves the same caution as workflow recovery. An authentication file may contain access tokens or references to credentials. A support path should name the file without printing its secrets. Moving a damaged file aside is safer than silently deleting it because the person may need it for diagnosis, but the replacement process should also define permissions, backup handling and revocation if credentials might be exposed. Feynman's public README adds another operational detail. The project sends anonymous usage data to PostHog, including commands, workflows, tools, models, token counts and errors with their messages and stack traces. It says prompts, model output, paper content and tool arguments are not sent, and users can disable telemetry with an environment variable. That disclosure is useful. Error detail can improve debugging, but error messages and stack traces can still reveal local paths or unexpected context. The README says a user's home folder is represented as a tilde. Teams using the tool with sensitive research should review the telemetry description, test what leaves the environment and decide whether to turn it off. Open source makes those questions easier to investigate. The repository uses the MIT License, exposes its source, tests, release history and issue tracker, and publishes signed release commits through GitHub. That allows an operator to pin a version, inspect changes and run local tests before updating. It does not make the package automatically safe. An agent that can read local files, contact outside services and write research outputs has meaningful access. Installation instructions, dependency changes, model-provider credentials, search-provider keys and telemetry settings all belong in a deployment review. The correct permission set for a public literature folder is not automatically correct for private clinical notes or an unpublished patent draft. The release's recovery change also deserves adversarial testing. Kill the parent process at several points. Stop it before a subagent starts, while a request is in flight, after a result returns but before the interface updates, and after the result is written. Restart with the same session. Confirm which states survive. Confirm that a completed result is not duplicated. Confirm that an interrupted result is not presented as complete. Confirm that citations and provenance still point to the artifacts actually used. Then damage the recovery path itself. Remove write permission. Fill the disk. Corrupt the state file. Rotate a provider credential. Change a model identifier. Reload after an update. Make two recovery processes start at once. These are not edge cases once long workflows run unattended. A useful failure ledger would report the parent exit reason, each subagent's last durable state, finished artifact paths, incomplete tasks, retry eligibility, model identity, token spend and the exact command needed to resume or export what survived. The operator should never have to infer recovery from a spinner. This is where product design meets reliability engineering. The interface should let a person keep completed results, rerun only failed lanes, exclude a questionable result, swap a provider and regenerate the final synthesis without paying for the entire investigation again. It should also warn when the preserved evidence is stale. A subagent result can survive a crash and still become unusable if its temporary source link expires, its local file disappears or a later task depended on context that was not preserved. Durable status without durable artifacts is a painted door. Feynman's release notes do not claim to solve all of this. They expose a direction. Keep finished work. Remove repeated overhead. Show which model did what. Preserve the provider's actual error. Name the broken configuration file. Point to a recovery command. None of those features will headline a keynote. Together they decide whether a person trusts the agent with a second serious task. The next useful evidence should be measurable. How often do real workflows lose a parent process? What percentage recover every completed result? How many active tasks can safely resume? How much token use disappears after prompt and cache changes? Do clearer errors reduce abandoned runs or support requests? Which failure modes still require manual repair? An independent reliability suite could answer those questions with repeatable fault injection. Freeze the workflow and provider responses. Kill processes at known boundaries. Compare the final artifacts with an uninterrupted control. Record duplicates, missing results, false-complete states, cost and recovery time. Until then, the new behavior should be read as a targeted maintenance improvement described by its maintainers. That is enough to be worth covering. Agent reliability is finally getting less cinematic. The work is moving from "look, it can research" to "look, it did not throw away the research when its supervisor fell over." Good. The future can keep its flying robots. Give us the finished folder and an honest restart button.