https://raidz.netNotes by Andrew Proctorhttps://raidz.net/notes/independent-ai-review/https://raidz.net/notes/independent-ai-review/Fri, 11 Sep 2026 00:00:00 +0000I designed Switchyard to assign development tasks to AI models and send changes to independent reviewers. Routing to another provider is useful when one becomes unavailable. An authoring failure needs more care: the first model may already have changed files. The next attempt needs a known starting point. In Switchyard, fallback stops when the first author changed files or the file state is uncertain. I can then inspect the work that exists before deciding how to continue. That leaves room for useful partial work. A failed run does not tell me that its edits are worthless, and it does not establish that they are complete. The files and the task’s requirements determine what can be kept. I give reviewers the requirements and relevant code, including what the author actually changed. Reviewers come from other model families. Different models can still share a mistaken assumption, so I want a finding to identify the condition that causes a defect and a way to reproduce it. The author should not supply its own independent verdict. Nor should a summary replace inspection of the changed files. I keep review findings and test results with the work so the next decision has evidence behind it. After review and any fixes, I compare the result with the intended change and check the important behavior through its real interface. A generated file can exist while the application still serves an older version. A command can exit successfully without producing the required output. When the environment prevents a check, I record what remains untested. I make the decisions about the workflow and what evidence is enough to proceed.https://raidz.net/notes/verify-tool-actions/https://raidz.net/notes/verify-tool-actions/Fri, 11 Sep 2026 00:00:00 +0000A music service can accept a play request while the stream fails. That distinction matters when an agent tells someone that music is playing: the response may only establish that the service received the command. I work on integrations around Hermes, an open-source agent framework, for the services and devices I use. An action response and a subsequent status reading answer different questions. I choose the check according to what the agent is about to claim. For a changed setting, I want a fresh reading of that setting. After restarting a service, I check that the service responds through the interface I need. For this website, I compare the content served at the public URL with the intended release. Those checks also have limits. A playback status does not prove that someone heard sound. A thermostat’s new target temperature does not establish that the room has reached it. An origin server returning a new page does not tell me which version a cache serves to visitors. If the confirming read fails, the agent should say that it sent the request but could not confirm the result. If it used an older reading or a fallback, the reply needs to make that clear as well. The project does not automatically verify every possible action. The useful distinction is specific: what did the tool accept, what did the next observation establish, and what is still unknown?https://raidz.net/notes/repeated-reports-and-evidence/https://raidz.net/notes/repeated-reports-and-evidence/Fri, 11 Sep 2026 00:00:00 +0000I built my OSINT workflow to follow developing events without repeatedly reading the same report. Grouping related coverage helps, but the number of posts in a group cannot tell me how many independent accounts support its claims. A report can spread through quotations, screenshots and rewritten summaries. Each post may add another place where the claim appears without adding another source for what happened. My collection workflow retains references to the material it gathers. Those references matter when assessing whether two reports depend on the same original account. A different headline or publisher does not settle that question. A separate account can add evidence, but it still needs examination. I want to know when its material was recorded and whether it describes the same event. A later publication date does not necessarily mean the material is newer. Grouping organizes related reports for a reader. It does not establish that a claim is true. A summary needs to preserve a disagreement or unresolved detail when the supporting material does not settle it. The website shows a limited public feed with posts and available media from the last hour. Source references remain in the private workflow; the public view does not expose the full evidence record. Its collection boundary and demonstration labels should make that limitation clear.https://raidz.net/notes/cache-request-limits/https://raidz.net/notes/cache-request-limits/Mon, 14 Sep 2026 00:00:00 +0000While developing Webmind, my web-search service for AI agents, I corrected an extraction-cache bug. The service let callers request different amounts of text from a page, but the cache originally identified its entries by URL alone. That made two different requests look like the same request. A caller asking for a short extract could receive a longer cached response. In the other direction, an earlier short extract could be reused when the next caller had asked for more of the page. Clipping every cached response to the latest limit would handle only one direction. Once the cache holds a short extract, clipping cannot supply the additional material a later request needs. The repair includes the requested character limit in the cache key, alongside the canonical URL. The service also clips the text at the response boundary. Those checks serve different purposes: choosing the appropriate cached representation and enforcing the caller’s output limit. The regression tests cover both request orders. A short request followed by a long one exercises a different failure from a long request followed by a short one. This was a response-length problem. Expiring old entries more often would not change the fact that the cache treated different requests as identical. For an agent consuming the text, the requested limit is part of the interface and needs to survive a cache hit.https://raidz.net/notes/agent-memory-retrieval/https://raidz.net/notes/agent-memory-retrieval/Mon, 14 Sep 2026 00:00:00 +0000I investigated how much stored context my personal agent retrieved for a question. Removing duplicate memories seemed like a possible way to reduce the amount, but the tests pointed elsewhere: most of the retrieved entries were distinct. Deleting duplicates would therefore have done little to address the problem I was investigating. I needed to examine how much the agent retrieved, rather than assume the stored collection needed cleaning up. I chose a lower retrieval limit without deleting memories. That kept the change focused on the context supplied for a question. It also left a way to reverse the decision if the smaller result set omitted information I needed. We checked a small set of questions to see whether the required answers remained available. They did for that test set. That was useful evidence for the adjustment, with a clear limit: it did not establish that a smaller retrieval set would suit every future question. In this case, distinguishing duplicate entries from excessive retrieval changed the proposed fix. I could reduce the context being returned while preserving the information already stored.https://raidz.net/notes/recovery-checks/https://raidz.net/notes/recovery-checks/Mon, 14 Sep 2026 00:00:00 +0000A recurring network problem had required a manual route repair. I replaced that repair with a check that follows the current gateway. Restoring the route was one requirement. The check also needed to leave a correct route alone. Otherwise, something intended to restore connectivity could make unnecessary changes during normal operation. We deliberately removed the route and confirmed that the check restored it. A second run confirmed that it left the working route unchanged. Those observations answered two different questions about the repair. Seeing that a scheduled task exists would not have established either behavior. The test needed an actual missing route, followed by a state in which no repair was required. The result was a checked recovery path for that recurring problem. It was not evidence that the network could recover from every failure. I kept the check tied to the condition it was intended to handle. This small repair shows one place where the healthy state belongs in the acceptance criteria alongside the failure.