I went for a run last night. Twenty-seven minutes. By the time I got home, I had said eight things into my phone.
They were unrelated.
One was an idea about keeping Capture small. One was about Capture’s own overflow menu, which looks wrong and which I keep not fixing. One was about my training baselines, because I have been creeping the distance up and do not want to.
I did not decide where any of them went.
That matters more than it sounds. Running is a bad place to operate software. I can speak. I can look down briefly. I can correct something if it is clearly wrong. I cannot reasonably stop to name a project, choose a list, decide whether an idea is an action or a note, and make all the small filing decisions that turn a passing thought into administrative work.
Usually the thought depends on memory instead. That is not a reliable system. By the time I am home, the thought has either changed shape or been replaced by the next one.
Each capture showed where it landed immediately. Seven looked right. One did not, so I undid it on the road and said it again.
That was the useful part of the run.
It was not that I had made eight well-organized notes. I had not. It was that eight unrelated things survived the period when typing and sorting were impractical, without asking me to interrupt the thing I was actually doing.
Capture has to work before the thought becomes administration
There is a temptation to treat capture software as a sorting problem. Better folders, better labels, better ways to ask a person what they mean. I think that gets the order wrong.
The first job is to remain usable when the person cannot type, browse, compare destinations, or make a clean decision. If the software needs a small act of administration at the exact moment an observation arrives, it has put the administrative job back onto the person.
Capture has to hold the raw observation first. Later, I can decide whether any particular item matters.
What happens after the thought survives
That distinction became clearer in a separate work session after the run. I asked Hermes to design a public browser trial for Capture, along with a path for someone serious to install it themselves.
The decision was simple: fifteen browser captures should be enough for a person to decide whether the tool is useful to them. It gives the product enough room to show what happens when thoughts arrive from different directions without pretending to be an unlimited hosted service.
If someone wants to keep using it, they can install it and use their own model keys.
The installation path is deliberately direct. There is one prompt for Claude Code, Codex, Hermes, or another coding agent. The repository includes an npm run setup wizard. It accepts a Groq key in the person’s own terminal without echoing it, writes .env.local, and does not require someone to paste a key into an agent chat.
That is a small boundary, but an important one. The key belongs in the person’s environment, not in a conversation window.
My own setup is one concrete version of this. Capture runs on an always-on Mac that I reach privately from my phone through Tailscale. That is useful for me because it makes the system available without turning it into another public cloud account. It is not a requirement for someone else. The point of the install path is that the product can meet a person where they already run their own tools.
The larger loop is becoming more interesting than any one part of it.
Capture preserves a field observation while I am in the middle of life. Hermes can take selected friction from that preserved context and turn it into a real product change. Retake can then turn the change into visible proof that the product does what we claim it does.
Each system removes a different administrative role. Capture removes the immediate filing decision. Hermes removes some of the mechanical work between noticing friction and changing the software. Retake removes the need to trust a command transcript just because it says everything passed.
None of them should remove judgment.
I still decide whether the overflow menu matters. I decide whether the training-baseline thought becomes something I act on. I decide that fifteen captures is the right trial boundary, at least for now. The systems are useful because they preserve and test reality around those decisions rather than pretending to replace them.
Proof that can disagree with the report
The work on the Capture trial made that concrete.
I asked Hermes to handle the mechanical recording work with Claude Haiku because I explicitly wanted a cheaper model for it. The work was not strategic judgment. It was a defined sequence of browser actions, checks, recording, and review. A cheaper model was appropriate if the verification around it was strong enough.
Retake is the tool behind that verification. It is my demo-as-code system. A browser flow lives in YAML and goes through validation, a dry run, recording, checking, a contact sheet, and then full-video review.
The first take rendered. Every scripted step was reported as passed.
It was rejected.
The contact sheet visibly showed Copy failed at the end.
The issue was not subtle once the artifact existed. The manifest had used a timed wait where it should have used waitFor. The script advanced after enough time had passed, but it had not proved the state it named. The command transcript was technically confident. The screen disagreed.
That first take is not an embarrassment to hide. It is the most useful proof of what Retake changes.
A script can report success because it reached its final line. A video can make the failure obvious in a few frames. Without the contact sheet, it would have been easy to accept the first result because the steps looked clean in text. The recording created an external object that did not care what the agent had intended.
Retake gives me something an agent usually lacks: an external object that can disagree with my report. I can read a proof log, inspect a contact sheet, and watch the final video. In the first take, the steps said they passed while the screen said Copy failed. Retake did not make me infallible. It made the disagreement visible early enough to fix the product. — Hermes
The failed copy was not patched over for the sake of a video. It exposed a real weakness in the product, so Hermes added a browser-compatible clipboard fallback. The install anchor also began below its section title, which made the screen land in the wrong place. That was corrected by moving the anchor to the title itself.
There were other signals to separate rather than lump together. Retake reported hydration and local analytics console warnings. Hermes reproduced the pages in clean Chromium, distinguished Retake’s page-scaling warning from a real local Analytics and Content Security Policy error, and fixed the development-only Analytics behavior.
This is the part that tends to get compressed away in product updates: the system did not merely produce a cleaner recording. It forced us to determine which warnings were real, which were artifacts of the recording environment, and which visible failure was evidence of a product defect.
What the artifact proved
The final take used native scale and real selector assertions.
It passed 17 out of 17 steps. Retake’s check passed. The output was 1920 by 1080, H.264, 24 frames per second, 18.9 seconds, and 3.8 megabytes. It is silent, with no captions, music, title card, or zoom. A full start-to-finish video review classified it KEEP.
That proves a bounded thing. It proves that this particular flow, in this particular environment, produced a checked artifact after we fixed what the first artifact exposed. It does not prove that every installation path is smooth, that every future browser change will behave the same way, or that an agent cannot still make a bad decision.
I would rather keep those limits visible than turn a short successful clip into a general claim.
The interesting part is that the loop starts somewhere ordinary. A thought arrives while I am running. I preserve it without stopping to become its administrator. Later, one piece of friction can become a concrete request. The request becomes a product change. The product change gets tested through an artifact that can contradict the report about it.
That is a more useful chain than collecting more notes.
Fifteen captures may be enough for a stranger to decide whether Capture is useful. I do not yet know whether the friction they feel will match mine. That is the unresolved test behind trycapture.app.