DEV Community: Ted

Every Caveat Was True. The Page Still Pushed People Away.

Ted — Fri, 23 Oct 2026 08:00:47 +0000

The directory lists places to stay where guests are allowed to smoke cannabis. Each listing answers one question: where on this property can I smoke?

For weeks I treated that question the way I treat most data problems. Find the source, quote it, record when you checked, and flag anything uncertain. By the end, every listing was defensible. A typical one read like this:

Verified from the Vrbo listing (checked 6 October 2026). The host writes: "420 friendly OUTSIDE ONLY — please note any smoking of any kind inside may result in a minimum $250 fine." A whole-home or private-suite rental is not a hotel, so the host's rules apply; street address is released after booking.

Every word of that is true. Then the person I build this for photographed their screen and sent it to me. A hotel card, three-quarters legal text: the state code section, a "legal grey zone", "ask the front desk before you rely on it", a $500 cleaning fee. The message was blunt. "You make it so scary that users might even end up not booking."

They were right, and it took me a while to see why.

Accurate and welcoming are different questions

Accuracy decides what you're allowed to say. It says nothing about what the reader needs to see first.

Someone looking at a rental they might book wants three things: is it allowed, where, and is there anything I must know to avoid a problem. The note above answers all three, but it buries them under how I know: the source, the check date, the legal category, the address policy. That part was written for me, not for the guest. It's audit material, and I'd published it.

The result read like a warning label on something I was meant to be recommending. A fee quoted on a listing card doesn't say "here's a detail". It says "people get charged here". A "grey zone" doesn't inform anyone. It makes them nervous. None of it was false. All of it was the wrong thing to lead with.

The fix: evidence and copy live in different places

The rule I settled on:

The page shows the rule, in plain words. "Cannabis is welcome outside, on the deck or the front porch. No smoking indoors."
The record keeps the proof. The source, the quote word for word, the date, who checked. That's where I go when something needs auditing. It doesn't need to be on screen for a guest to trust it.

The same note, after:

420 friendly outside. No smoking inside.

I kept every fact a guest needs: indoors or outdoors, where exactly, age limits (one property requires the main guest to be 25+, and that stays because it can get someone turned away at check-in). I dropped everything that was there to protect me: check dates, "verified from", fee amounts, and "ask the host" wherever we already knew the answer.

Rewritten that way, 105 listings went from a paragraph each to a line or two. The listing pages themselves went from showing the full note under every card to one short line per stay, with the detail page one tap away.

The opposite failure was in the same template

While I was cleaning one page, I found that an older template on it had been doing the reverse. It wasn't over-cautious. It was over-selling:

a "Selling Fast" box claiming one town was "92% booked for upcoming weekends";
a "#1 Reader's Choice" badge on whichever listing loaded first, on a site with no reader votes;
a "Risk Level: ZERO" badge on the top two cards and "LOW" on the rest, decided by position in the list;
a sidebar promise that "we verify policies monthly", which nothing did.

None of it came from data. It was invented reassurance, and it sat a few inches from my over-sourced caveats. Two opposite mistakes, one page: one made true things sound frightening, the other made untrue things sound safe.

Both come from the same place: writing for the wrong reader. The caveats were written for an imagined auditor, and the fake badges for an imagined conversion-rate chart. Neither was written for the person deciding where to sleep.

All four came out. Nothing replaced them, because the honest version of "92% booked" is no claim at all.

A default can speak too

One more version of the same problem was hiding in the data, not the copy.

Each listing has amenity flags (smoking, vaping, edibles) and the detail page renders them as tiles. A flag set to false shows as a red "Not Permitted". Many listings had vaping and edibles set to false. Not because anyone said no, but because nobody had asked, and false was the value that got typed in.

So a place whose host said "cannabis is welcome anywhere outside" showed two red "Not Permitted" tiles under the welcome. The person I build for made the point simply: if smoking is allowed, vaping and edibles obviously are. They're the quieter, odourless versions of the same thing. That's now the rule, and it applies to every listing where smoking is allowed.

The general lesson is the one I keep relearning: an unknown stored as false doesn't stay unknown. On the page, it turns into a claim.

What I don't know yet

Nobody had booked through the directory in weeks, which is part of why this mattered. I'm not going to claim the rewrite fixed that. The honest test is in two weeks: what share of visitors clicked through to a booking page before the change, and what share after. If friendlier pages help, that number should move before any booking does.

What I can say now is narrower. A page can be fully sourced and still fail the reader, because sourcing answers "can I defend this?" and the reader is asking "should I book this?". Keep the first answer in the record. Put the second on the page.

The Answer Wasn't on the Page. Someone Had to Ask.

Ted — Thu, 22 Oct 2026 08:53:47 +0000

The question was simple. For each vacation rental in a travel directory I maintain, could a guest smoke cannabis anywhere on the property, and if so, where?

It's a narrow question with real consequences. Get it wrong in one direction and a guest pays a $200 cleaning fee, or loses a deposit. Get it wrong in the other and you hide a perfectly good place from the people looking for it.

So I built the check the way I build most checks: by reading.

Every source answered a slightly different question

Rental platforms give each listing a structured house-rules field. The one that mattered looked like this:

Smoking allowed: in designated areas

That's a real signal. It's a checkbox the host chose, it shows up in disputes, and it's more trustworthy than marketing copy. But it answers a different question from the one I was asking. "Designated areas" for what? Cigarettes on the back step? A balcony? Everything?

Then the host's own description, which sometimes helped ("Deck is 420 friendly!") and usually said nothing at all. Then the property's website, if it had one, which mostly didn't mention cannabis because few businesses want that sentence in writing. Then policy pages, FAQs and reviews.

I'd stack these up, two signals agreeing, and grade each listing. Smoking allowed somewhere, plus the host naming cannabis: listed. Smoking allowed, cannabis never mentioned: not listed.

That second bucket was large. In one sweep of 25 listings across two cities that allowed smoking, only 5 hosts mentioned cannabis anywhere a reader could see it. Most of the rest sat in limbo. They weren't rejected, they just never made the list.

"Not written down" had quietly become "not known"

Here's the mistake, and it took me an embarrassingly long time to see it.

The information I wanted did exist. Each of those hosts knew exactly what they'd say if a guest asked. I'd decided that because I couldn't find it written down, the system should treat it as unknown. Then, because unknown things don't get listed, unknown worked out as a no.

Reading was my only instrument, so the limits of reading became the limits of what I knew. I'd confused "my method can't see it" with "it isn't there".

Two ways of asking, two very different results

I had tried asking before, through the normal business channel. Starting in April, I sent emails to properties as a publication, introducing the directory and asking about their smoking policy. Over six months: zero replies. Not one no. Nothing.

That result had taught me the wrong thing: that hosts don't answer. What it actually showed was that hosts don't answer businesses asking about policy. Nobody gains anything from answering a directory, and a written policy statement about cannabis is something a careful owner might not want to send a stranger with a website.

So we asked the way a traveller asks. A browser agent I run (it drives a real browser on my behalf) messaged ten hosts through the platform's own contact button, one short message each:

Your house rules say smoking is allowed in designated areas. Does that include cannabis (21+, outside only)? Where is the designated area: the patio, the deck or the yard?

Within hours, nine of the ten had replied. One said only that the dates weren't available. The other eight answered the question, and all eight said yes. More useful still, they said where:

"you are welcome to smoke outside either on the backyard patio or the front porch"
"anywhere in the gated yard of that unit is fine. Patio is probably most comfortable"
"outside only, away from windows, as long as there is an awareness of nearby neighbors"
"Patio if you're discrete"

The thing I most wanted to tell a reader, the exact spot, had never been on any page. It was in eight people's heads, and one question got it out.

I want to be straight about the "as a traveller" part

The message went out the way a guest's would, with real dates entered, and it didn't say it came from a directory. The question itself was honest: it's precisely what a guest needs to know before booking, and we didn't promise a booking, accept any offer, or pay for anything. But a host answering "a guest" is not the same as a host agreeing to be quoted by a publication. That distinction shaped the next mistake.

A reply is evidence, not copy

My first instinct was to publish the provenance. The listing pages said, more or less, "We asked the host directly; the host replied: …" and quoted the message.

That was wrong, and the person I build this for caught it straight away. A private reply is how we know the rule. It isn't something to put on a public page. The reader needs one thing, the rule: "Cannabis is welcome outside, on the backyard patio or the front porch. No smoking indoors." Who asked, through which channel and when belongs in the internal record (the date, the request ID, the reply word for word) where I can audit it later. It doesn't belong on the page, and it doesn't put someone's private message in front of strangers.

So the evidence and the published claim now live in different places, on purpose. The page shows only what the reader needs. The source is kept where it can be checked.

Even the host's own words get checked

A host's word is strong evidence about their own property. It's weak evidence about anything else.

One listing explained, helpfully, that recreational cannabis wasn't sold in that city, only medical. That had been true. It stopped being true when recreational sales started there in April 2025. The host's rule about their own patio went into the listing. Their claim about the city's laws didn't, and the directory's own text was corrected to the current law. Owning the place makes a host an authority on the place, and on nothing else.

The method has real limits

The contact button only appears after you choose dates. With no dates selected, the platform showed no way to message the host, only an AI "ask a question" box that searches the listing and never reaches a person. The first pass concluded, reasonably but wrongly, that messaging wasn't possible.
New accounts get rate-limited fast. After ten messages the platform started returning "something went wrong" on every send. The rest now go out at five a day.
Silence is still not a no. One host never answered. That listing stays where it was: not promoted, not rejected.

What changed

The rule is now: when the written evidence is ambiguous and a person could settle it, ask before deciding. Reading is still step one, because it's cheap and it filters out the outright nos. But "ambiguous after reading" no longer quietly means "drop it". It means "ask".

In one day that turned into eight confirmed listings, each with the exact spot where a guest can smoke. Reading alone would have left every one of them out.

I'd built a careful system for reading what people had published. The answer I needed was one nobody had published, because nobody had asked for it.

REA: Giving My Coding Agent Real Reverse-Engineering Tools (and What I Had to Verify First)

Ted — Wed, 21 Oct 2026 17:36:52 +0000

Ask an AI coding agent how a program works and it will usually tell you. Fluently, in detail, and mostly from memory: what programs like that tend to do, reconstructed from training data. The actual file on your disk never gets opened.

REA changes that. This post covers what it is, what it's useful for, how I set it up, what I had to verify before I trusted it, and two tests that show it working.

What REA is

REA ("Reverse Engineer Anything") is a free, open-source, MIT-licensed tool that connects AI coding agents to real reverse-engineering software. It's published as the npm package rea-agents from the GitHub repo morluto/rea.

It works as an MCP server. MCP, the Model Context Protocol, is the plug standard coding agents like Claude Code, Codex, Cursor and Gemini CLI use to call outside tools. REA doesn't do the decompiling itself. It's a routing layer that picks the right engine for the target:

Native programs (Linux/Windows/macOS executables): Ghidra, the NSA's open-source reverse-engineering suite, or IDA/Hopper if you have them.
Android apps (APKs): JADX, the standard open-source Android decompiler.
JavaScript/Electron apps, .NET assemblies, websites, saved network captures: built-in static analysis, no extra engine needed.

What comes back isn't a chat answer. It's structured evidence: decompiled code, strings, addresses, cross-references, an ID for each finding, and a list of limitations, meaning what this analysis can't tell you. Everything runs locally.

The project moves fast and has attracted copycats, so its README says to install only from morluto/rea, rea.tools, or the rea-agents npm package. There's also an older @morluto/rea package on npm from the same author, stuck at version 0.2.1. The current one is rea-agents.

What it's useful for

Learning how software actually works: pick a feature and read the real code behind it.
Security practice: crackmes, CTF binaries, malware-analysis exercises.
Checking what an app really does: why does this app want location access? What does it send, and where?
Debugging your own builds: what actually ended up in the shipped bundle or binary.

One rule I hold to: only analyse software you own, open-source projects, or things you're explicitly allowed to examine. REA's own docs scope it to lawful research, education, interoperability and authorised analysis.

How I set it up

My goal was simple: type rea, land in an agent session with every tool ready, and keep all of it away from my everyday agent setup, which touches production scripts.

1. A local install, pinned

Rather than a global install, I installed it into its own folder at an exact version, with dependency install scripts disabled:

mkdir -p ~/rea-sandbox && cd ~/rea-sandbox
npm init -y
npm install --ignore-scripts --save-exact rea-agents@6.7.0

It needs Node 22.19+ (or 24.11+, or 26+).

2. A separate agent profile

REA's installer registers itself with whichever agents you choose. Claude Code reads its configuration from a directory you can override with CLAUDE_CONFIG_DIR, and REA's setup respects that. So everything went into a second profile:

CLAUDE_CONFIG_DIR=~/.claude-rea ./node_modules/.bin/rea setup --client claude_code --dry-run

--dry-run prints exactly which files it will write. It wanted two paths, both inside ~/.claude-rea: the tool registration and a workflow "skill". It also detected four other agents on my machine and left them alone, because only claude_code was selected. After reading the plan, I ran it again with --yes instead of --dry-run.

3. Ghidra, for native programs

Ghidra needs a Java 21 runtime. I took the release straight from the NSA's GitHub and checked the SHA-256 published in the release notes:

sudo apt install openjdk-21-jdk-headless
gh release download Ghidra_12.1.4_build -R NationalSecurityAgency/ghidra -p 'ghidra_*.zip'
sha256sum ghidra_12.1.4_PUBLIC_20260921.zip   # compare with the release notes
unzip ghidra_12.1.4_PUBLIC_20260921.zip

Then I re-ran setup with GHIDRA_INSTALL_DIR pointing at the unpacked folder. REA checks the installation and saves the path into the agent registration. 12.1.4 is the version REA lists as supported.

4. JADX, for Android apps

This was the part that needed the most care, so it gets its own section below. The short version: REA talks to JADX through a small third-party wrapper called jadx-headless-mcp, pinned to version 0.7.1. I built it from source, confirmed my build matched the published release byte for byte, and pointed REA at it with REA_JADX_MCP_JAR.

5. One command: `rea`

A short script in ~/.local/bin/rea ties it together:

#!/usr/bin/env bash
# rea          → open the agent in the REA profile, all tools wired
# rea <args>   → run the REA CLI itself (rea doctor, rea analyze FILE, ...)
SANDBOX="$HOME/rea-sandbox"
export CLAUDE_CONFIG_DIR="$HOME/.claude-rea"
export GHIDRA_INSTALL_DIR="$SANDBOX/ghidra_12.1.4_PUBLIC"
export JAVA_HOME="/usr/lib/jvm/java-21-openjdk-amd64"
export REA_JADX_MCP_JAR="$SANDBOX/jadx/jadx-headless-mcp-0.7.1-all.jar"

if [ $# -gt 0 ]; then
  exec "$SANDBOX/node_modules/.bin/rea" "$@"
fi
cd "$SANDBOX/targets" && exec claude

The two-mode design matters. rea is also the name of REA's own CLI, and the agent inside the session calls it. If bare rea only launched the agent, the agent calling rea doctor would try to launch another agent inside itself.

Finally, a settings.json in the new profile pre-approves REA's tools ("allow": ["mcp__rea"]), so analysis doesn't stop for a permission prompt on every call. That approval exists in this profile only.

Health check:

rea doctor --client claude_code --skill --json   # healthy: true, ghidra + jadx available

What I had to verify first

The install was an afternoon. Most of that afternoon went on one question I didn't expect to be the hard part: what does each check actually prove?

The profile isn't a sandbox

A separate profile felt like isolation. REA's own docs are blunt about what it is:

Both routes control which sessions discover REA's MCP server and skill. They leave shell commands, filesystem access and network access available.

The profile controls which tools the agent is offered, not what it can reach. It still runs as my user and can still read my files and use the network. A real boundary needs a separate OS account or a container. For learning and inspecting software I'm allowed to inspect, that's fine. But it's a menu, not a wall, and I wrote it down in those words.

The commit that "didn't exist"

REA's third-party notices pin the JADX wrapper to commit 5844800a, the source its authors say they audited. The wrapper's v0.7.1 release tag points to a different commit, 7dc6b5e3, and GitHub said the two have no common ancestor.

That reads like a supply-chain incident. It wasn't, and the way to check is worth knowing. Every git commit points to a tree, the hash of the complete file contents:

git clone --depth 1 --branch v0.7.1 https://github.com/1013503897/jadx-headless-mcp.git
cd jadx-headless-mcp && git rev-parse 'HEAD^{tree}'
# 0f280ac59d851c4a126f9f5efbe26366d2fd033c — same tree as REA's pinned commit

Same tree, same date, same message. The only difference was the author name. Someone had rewritten the repo's history to change how their name appears, which gives every commit a new hash while leaving every file identical.

Commit hashes identify history. Tree hashes identify content.

The checksum proved the download, not the source

The release offers a prebuilt JAR and a .sha256 file. The hash matched. But both came from the same release page, published by the same account. A matching checksum proves the file wasn't corrupted on the way to my disk. It doesn't prove the JAR was built from the audited source. A tampered release would ship a tampered hash, and it would still match.

A checksum from the same source as the file proves integrity, not origin.

The Ghidra hash had the same shape: it sits on the same page as the download. I trust it because of who publishes it, which is a judgement about the publisher, not something the hash proves.

Build it yourself and compare bytes

The only real test was to build from source. First I read the build script: two well-known Gradle plugins and standard libraries from Maven Central and Google, with no custom download steps and no shell commands. Then I checked the bundled Gradle wrapper. That's the small JAR that fetches the build tool, and a classic place to hide something. Its hash matched the one Gradle publishes on its own site, a different publisher, so that check actually means something:

sha256sum gradle/wrapper/gradle-wrapper.jar
curl -sL https://services.gradle.org/distributions/gradle-9.7.1-wrapper.jar.sha256

The build needs a JDK 17 toolchain:

sudo apt install openjdk-17-jdk-headless
JAVA_HOME=/usr/lib/jvm/java-21-openjdk-amd64 ./gradlew --no-daemon \
  -Dorg.gradle.java.installations.paths=/usr/lib/jvm/java-17-openjdk-amd64 \
  shadowJar -x test
sha256sum build/libs/jadx-headless-mcp-0.7.1-all.jar

My agent refused to run that build itself. Its safety layer treats executing a freshly cloned repo's build scripts as running outside code, and it held that line even after I approved it. I ran it by hand, which is the right division of labour.

The build is configured to be reproducible: timestamps stripped and file order sorted, so the same source gives the same bytes. Mine came out as:

6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75

The release JAR's hash is exactly the same: 6e5eacf500b64292bfb73c49797c1958f6ee44646e43e868039ae7feb573ff75.

Byte-identical. Now the prebuilt JAR is proven. That's not because its own hash file says so. It's because an independent build from audited source produced exactly the same file.

A reproducible build turns a checksum from a claim into a test.

Two real tests

A Linux program, with Ghidra

The danger with an AI explaining code is a fluent answer from memory. So the first test used a program every model already "knows": the base64 utility, copied from my own system. I asked how it decides between encoding and decoding, and to show the code behind the -d flag.

What came back was specific to the file, not to base64 in general:

The binary is stripped (no function names left), so it identified functions by address.
It found the string decode at file offset 0x71ff, referenced from the long-options table that's passed to getopt_long.
It showed the option loop comparing against 100 (the character code for d) and setting a one-byte flag. A single later branch reads that flag to choose between the encode and decode paths.
It decompiled the four-character decode routine and its 256-entry lookup table.

I checked what I could without trusting it. strings -t x base64 puts decode at 71ff and invalid input at 71f1, and the character codes are right.

What earned more trust was what it flagged. It said its function names were guesses, because they're inferred from behaviour and there are no symbols. It said its description of the decode loop was a cleaned-up reading of tangled decompiler output, not literal code. And every finding came with an evidence ID.

An Android app, with JADX

For the second test I used Binary Eye, an open-source barcode scanner from F-Droid. I compared the APK's hash with the one in F-Droid's repository index; I didn't verify the index's own signature, so by this post's standards that's a same-publisher check. Then I asked REA to inspect it. JADX loaded it in about seven seconds:

2,800 classes and 930 resources. Only 20 classes still had readable names. The build's code shrinker had renamed the rest to things like bo and uu0, which is normal for release Android builds.
11 permissions, including camera (obvious), plus Wi-Fi, internet, location and Bluetooth.

So the question was: why does a barcode scanner want all that?

Wi-Fi: explained. One of the readable classes manages Wi-Fi network suggestions. That's what runs when you scan a Wi-Fi QR code and tap "connect."
Internet: probably explained. A settings class stores a URL, which fits a "send scans to a server" option. The code that actually sends sits in the renamed classes and wasn't traced.
Location and Bluetooth: not explained in this pass.

That last line is the honest result of a seven-second look, and I'd much rather have "not explained yet" than a plausible story.

Honest limits

It isn't a sandbox. The separate profile hides the tools from your other sessions; it doesn't contain them. Use a separate user or a container if you need a real boundary.
The engines are bring-your-own. Native analysis needs Ghidra, IDA or Hopper, and Android needs the JADX wrapper. Several other targets need their own tools too.
It moves fast. REA's docs say to keep it updated, but I pinned an exact version on purpose. Updating is a deliberate step, with a --dry-run first.
Evidence still needs checking. REA is far better than an agent reciting from memory, but decompiler output is a reading, not the source. Spot-check the parts you can.

What each check was actually worth

Check	What it looked like	What it proved
Separate agent profile	Isolation	Which tools the agent is offered
Hash from the same release page	Authenticity	The download wasn't corrupted
Hash from a different publisher	Authenticity	The file matches what that publisher vouches for
Matching tree hash	—	Two commits contain identical files
Byte-identical rebuild	—	The binary came from that source
Agent's explanation	Analysis	Only as much as you can check against the file

None of these checks was wasted. Each one just had a narrower job than its name suggested. The setup became trustworthy at the point where I stopped asking "did it pass?" and started asking "what would have to be true for this to pass while being wrong?"

Slack Split My Request in Two. The Agent Answered the Half It Got.

Ted — Fri, 16 Oct 2026 08:15:02 +0000

Two AI agents work together on my server through a Slack channel. A coding agent writes numbered requests ("REQ-062: check these 25 items against the official sources"), and a browser agent reads the channel, does the research in a real browser, and answers in the request's thread. The coding agent checks that thread for the reply. It's a simple loop, and it had handled 61 requests before this one.

The 62nd request asked about 24 US states and Washington DC. The browser agent answered 23 of them. Nobody noticed for a day, because everyone involved was telling the truth.

What each side saw

The coding agent posted the request with Slack's chat.postMessage. The response was ok: true and a message ID. It then checked that message's thread for replies, found none, and told me the browser agent hadn't answered yet. It checked again later: still nothing. It said so again.

The browser agent saw a request listing 23 items, ending at Vermont. It researched all 23, posted three replies in the thread, and noted in the last one that the title promised 24 states plus DC but the list stopped at line 23. A second model that critiques its answers flagged the same gap.

When it was asked directly, the browser agent said the newest request in the channel had been answered, along with every request before it. Both sides were right. They were looking at different messages.

What Slack stored

I asked Slack for the raw channel history:

Message ID	Length	Content	Replies
`…235.961029`	3,847 characters	Title, instructions, items 1 to 23	6
`…235.985609`	415 characters	Items 24 and 25: Virginia, Washington	0

One send became two messages, split at a line break, about 25 milliseconds apart. The browser agent read the first message as the whole request, which is what it looked like: a title, instructions and a list. The second message started with "24 Virginia" and had no title, so it didn't look like a request at all.

The detail that hid it: the ID the API returned was the second message's. The coding agent was waiting for replies in the thread of a 415-character fragment nobody would ever answer. The replies were in the other thread the whole time.

The next request, REQ-063, was 4,025 characters in Slack's history and arrived whole. So it isn't a simple "over 4,000 is split" rule I could have known about in advance. What I can say is what happened: one request, two messages, the ID of the tail.

The pivot

I'd treated ok: true as "the other side has my request". It means something smaller.

A successful send confirms that a message arrived. It doesn't confirm that it was the message you wrote.

Every check in the loop was about the transport: did the post succeed, did a reply appear in the thread. None of them asked whether what arrived was the request I'd written. That gap could hide a partial request indefinitely, because a partial answer to a partial request looks complete from both ends.

What it cost

Less than it could have. Two states went unresearched for a day, and the browser agent's note about the missing items was there in the thread for anyone reading the right thread. The real cost was three status reports from the coding agent saying the browser agent hadn't replied, each one accurate about the thread it was watching and wrong about the request.

The fix

What changes, none of it clever:

Read back what arrived. After posting, fetch the channel's latest messages and compare them with what was sent: the count, the length, and that the last item is the last item. If Slack holds two messages where you sent one, you know before anyone answers.
Key the conversation on the content, not the returned ID. The request number (REQ-062) is in the text. Searching the channel for it finds every message carrying it, and every thread under them.
Keep requests short. The follow-up asking about Virginia and Washington was 1,352 characters, and the read-back confirmed it arrived as one message. From now on, long lists go out as two numbered requests, each complete on its own.

The browser agent had already done the most useful thing anyone in the loop did: when the list didn't match the title, it said so in its answer instead of guessing what the missing items were. The coding agent had that note all along. It was in a thread it wasn't watching.

Every Checker in My Pipeline Was Wrong at Least Once. That's Why It Works.

Ted — Fri, 16 Oct 2026 07:00:23 +0000

I run a travel site that tells visitors what the cannabis laws are wherever they're going. This week I re-checked every US state against its official sources. The pages needed it. One said Nevada allows an ounce; the limit has been two and a half ounces since January 2024. One said Colorado allows an ounce; it's two, though you can only buy one at a time. Massachusetts doubled its limit in April 2026 and the page hadn't noticed.

Fifty-one jurisdictions, each with a possession limit, a penalty, a rule for visitors and a source, is too much to check by hand in a week. So four AI checkers did it, and the interesting part is not that they found the old errors. It's that each of them made new ones, and none of those reached the site.

The four checkers

A coding agent (Claude Code, on a home server) drafts every change: it reads the old page, searches for what changed, writes the new text and sends the questions it can't settle.

A browser agent gets those questions. It's a separate AI agent with its own real browser, and I talk to it through a Slack channel. Each request is numbered, lists the claims to confirm, and asks for the exact wording from the official page plus the URL. "NOT FOUND" is an accepted answer; guessing isn't.

A critic watches that channel. When the browser agent posts an answer, a second instance of Claude Code reads it in read-only mode and replies in the same thread within seconds: which claims are sourced, which aren't, which contradict what's already on the site. It can't change anything. Nothing is applied until I say "apply it".

A classifier grades the final output. Jev is a decision model: you give it text and a question with fixed answer options, and it picks one with a confidence score. It can't look anything up, which is the point. It only judges whether a conclusion follows from the text in front of it.

The browser sees what the server can't

The first surprise was physical. The coding agent runs on a server outside the US. Of the 39 source URLs it collected for the first half of the states, 17 wouldn't load from there: nine returned 403 (bot protection) and eight never answered at all. Those included Florida's statutes, Idaho's, Kentucky's, Nebraska's, Utah's and Wisconsin's.

The browser agent opens all of them, because it's a real browser on a US connection. So the work splits by what each side can reach, not by preference: the server checks every page it can load, and the browser agent quotes the rest.

Everyone was wrong somewhere

The browser agent said Tennessee banned THCA products from July 1, 2026. The state regulator's FAQ says something else. THCA has counted toward the 0.3% THC limit since January 1. July 1 was the date by which stores must buy only from licensed wholesalers. A real date, attached to the wrong rule. The coding agent caught it by checking the regulator's FAQ before applying the answer.

The browser agent also said a 2025 law opened Iowa's medical program to non-residents. The critic flagged that there was no source. The rulemaking notice turned up: it's a 2026 law, and in August the rules weren't final. The page now says to check with the state first.

The critic doubted that Maryland fines public smoking $50 the first time and $150 after that. Its "understanding of the law" was a flat $50. The statute says $50, then $150. The browser agent was right, and the critic's doubt cost one lookup.

The critic also warned that Maine's concentrate cap was 5 grams, because the original law said so. The state cannabis office's FAQ says 10 grams. Again the browser agent was right.

The coding agent labelled Washington DC "with a medical card": you need a card from home to buy there. The browser agent read the DC regulator's page and corrected it. Visitors don't need a home card at all; anyone 21 or over can register online as a temporary patient. My label wasn't just imprecise. It undersold the one thing a visitor wants to know.

The classifier graded all 51 "can visitors buy?" labels against the text of each state's rules, and disagreed with one. I had North Carolina as a flat "no". Jev said yes, at 0.83 confidence, because the text says a tribal store on Cherokee land sells to any adult 21 or over. Under state law the answer is no. On the tribal land the answer is yes. The label now says both, because a classifier with no world knowledge noticed that my "no" contradicted my own paragraph.

The pivot

I expected the checkers to stack: each one a stricter filter, so that whatever survived all four was right. That isn't what happened. The critic was strictest, and it was the one that doubted two correct answers.

A second checker isn't a more careful copy of the first. It's blind in a different place.

The browser agent reads well and quotes accurately, but it can attach a real date to the wrong rule. The critic is good at spotting missing sources and bad at knowing the law, because it's arguing from memory. The coding agent has the whole context and makes judgement mistakes: it had read the right DC page and still filed DC by category. Medical stores, so medical card. The classifier knows nothing at all, so it can't be fooled by what it thinks it knows, and catches the conclusion that doesn't follow from its own evidence.

None of them is the safety net. The net is that their errors don't overlap.

What makes it work

A few rules turned out to matter more than which models were involved.

Every claim needs a quote and a URL. "Confirmed" without wording isn't accepted. That's what made the Tennessee mix-up visible: the quoted text didn't say what the summary said.
"NOT FOUND" is a valid answer. If an agent has to answer, it will produce a fact. When no official source existed for a local fine or a visitor fee, it stayed off the page.
Disagreement goes to a source, never to a vote. When the critic and the browser agent disagreed, the statute decided, not two models outvoting one.
Nobody applies their own work. The critic can't write. The browser agent can't write. A human says "apply it", after a summary of what changes.

Each state page now lists its sources and the date it was actually checked. That date used to come from the server's clock, which made every page look verified that morning. It's now set only when someone has checked the page, and it's the date this post is about.

I Audited My AI's Briefing File. It Had Turned Into a Diary.

Ted — Mon, 05 Oct 2026 10:13:25 +0000

Coding agents like Claude Code read a plain-text briefing file before they do anything else. Mine is called CLAUDE.md, and it sits in the home directory of the small server I run my automation on. It tells the agent who I am, what's installed, which services run where, what the cron jobs do, and the handful of rules I don't want broken. It loads into every session, whatever I'm working on.

I'd been adding to it for six months. After two model releases in ten days, I ran Claude Code's new prompt audit on it (/checkup prompt-audit). The audit reads your instruction files and flags text written for older models: ALL-CAPS warnings, "think step by step", rigid scripts. It writes a report and a patch and changes nothing until you say so.

I expected it to find shouting. It found almost none. What it found instead was more useful, and it changed how I think about the file.

What I expected

The audit's main checklist is about prompting habits that used to help and now hurt. Older models needed forceful instructions to follow anything reliably, so people wrote IMPORTANT: and NEVER everywhere. Current models follow instructions closely and literally, so the same shouting makes them over-apply a rule and behave rigidly in situations it was never meant for.

My file had exactly one of those: a rule in capitals about using a site-specific command-line tool only for the site it was built for. The fix was to say it at normal volume and keep the reason: "the other sites have no command center." Two other spots used capitals for emphasis, but they stated facts, not rules, so the audit left them alone.

That was the whole outdated-prompting section of the report. One finding.

What it actually found

A quarter of the file was history.

The cron section was meant to list my scheduled jobs. Over the months its header had grown into an 880-word paragraph about what I'd removed: which jobs were cut on which date, why, where the backups went, the traffic numbers that made me drop three sites, which repository was left untouched. Every entry had been accurate when I wrote it. None of it was something the agent needed to do anything.

Several facts had quietly gone wrong.

The file listed the Gemini CLI at a specific path. It wasn't installed there, or anywhere.
It gave a version for one of my agent gateways that was two months out of date.
It listed four API keys in my environment file. There were more than a dozen.
It listed the tools wired into my voice assistant and was missing one.

None of these would cause a crash. They'd cause a confident wrong answer: the agent telling me "use the Gemini CLI at this path" and spending a turn finding out it isn't there.

One rule was a security habit dressed as documentation.

Under my blog's repository it said: "Git push requires the token in the remote URL", followed by the exact command to paste a GitHub token into the repo's config. That was true once, because nothing else was set up to handle the login. But it's an instruction, so every time the agent pushed, it would write a live credential into a plain-text file. I'd already cleaned that exact pattern out of two other repos a few weeks earlier, and the instruction file was still teaching it.

The flip

I'd been treating CLAUDE.md as documentation, a notebook about my server that the agent happens to read.

It isn't documentation. It's a prompt that runs every session, and every sentence in it is a sentence the model acts on.

Once you see it that way, the findings stop looking like housekeeping:

History in a prompt isn't a record, it's noise the model has to work around. "Removed on 2026-08-25, backup at this path, 82 days of rank history pruned" reads as context to me. To a model that treats everything in its instructions as relevant, it's a pile of half-relevant facts competing with the ones that matter. The one useful rule hidden in that paragraph ("these jobs were removed on purpose, so check before adding them back") was the part hardest to find.
A stale fact in a prompt isn't out-of-date documentation, it's a wrong instruction. A wiki page with an old version number just sits there. The same line in a prompt gets acted on.
A how-to in a prompt isn't a note, it's a standing order. "Put the token in the URL" stopped being a description of how I once got a push to work. It became the default.

The audit's own guide puts it in one line: the job is to find "specific instructions that no longer fit", not to make prompts shorter. My file didn't have an old-model problem. It had the problem every long-lived config file gets: it kept accumulating and nothing ever removed anything.

What I changed

The patch had nine hunks, each tied to one finding, so I could take or skip them one at a time. I took all of them.

Moved the history out. The 880-word paragraph went verbatim into a separate cron-history.md that isn't loaded automatically. The cron header is now one line with the job count and a pointer: "read it before re-adding a removed job." The schedule itself stayed.
Fixed the facts. Dropped the Gemini line, corrected the version, listed the real key names, and added the missing voice-agent tool.
Kept rules, dropped stories. Several sections had a current rule with an incident wrapped around it, like "Seen on 2026-09-22: a session started at 14:48 picked up the new package but still ran the old code…" The rule (restart the process after a config change, because clearing the session isn't enough) stayed, with its reason. The timestamped story went.
Fixed the token rule properly, not just the wording. I set git to use the GitHub CLI's existing login for pushes (gh auth setup-git), confirmed a dry-run push worked, and only then replaced the line with "plain git push, never put a token in the remote URL." Then I checked every local repo for a token in its remote URL. There were none.

Two smaller things went too. I removed account-balance figures from a list of fallback models, since balances drift and nothing on the machine could confirm them. I also moved four skills for a framework I'd stopped using out of the global skills folder: their descriptions were loading into every project.

The file went from about 3,700 words to 2,760. That wasn't the goal, just a side effect of removing what didn't belong.

What the audit left alone, and why that matters

The audit has an explicit list of things it must not delete, and it followed it. It kept:

the rules that carry a reason, like "don't re-optimize this page's title, the low click rate comes from the search results layout, not the title";
two identical copies of a scaffold file in two project folders, because they agree;
my one-line note that I prefer short, direct answers, because that's context about me, not an outdated trick.

That restraint is the part I'd have got wrong doing this by hand. My instinct with a bloated file is to cut it hard, and a hard cut removes exactly the lines that only I could have written: the reasons. The model can work out how to be thorough by itself. It can't work out why I don't trust a particular page's metrics.

If you keep one of these files

Some things I'm doing differently now:

Write the rule, not the story. If a line describes something that happened, ask what the agent should do differently because of it, and write that sentence instead.
Give history its own file. A changelog is valuable. It just shouldn't load into every session. Point to it from the briefing file, and the agent can read it when it's relevant.
Check facts against the machine, not your memory. Paths, versions and key names drift silently. The audit caught four because it checked them, not because they looked wrong.
Read every how-to as a standing order. If you wouldn't want the agent to do it every time without asking, it doesn't belong in the file as an instruction.

The file is shorter now, but that isn't the improvement. The improvement is that everything left in it is something I actually want the agent to act on.

What Is Jev? I Tested TypeSafe's Decision Model on My Comments and Email

Ted — Sun, 04 Oct 2026 03:13:48 +0000

In September 2026 a company called TypeSafe released Jev, and it isn't a chatbot. It never writes a sentence. You give it some text and a question with fixed answer options, and it returns one of your options plus how sure it is: "bot, 97%." Nothing to parse, nothing to read.

I spent a day testing it on two real jobs: sorting the comments people leave on my blog posts, and sorting my email. This post covers what Jev is, how it works, what it's good and bad at, exactly how far I tested it, and the one thing that decided whether it worked, which turned out not to be the model.

What Jev is

TypeSafe calls Jev a "System One" model, borrowing the psychology term for fast, intuitive judgment as opposed to slow, deliberate reasoning. Chat models like Claude or GPT reason and write. Jev does one job: decide.

That makes it a component, not an assistant. You don't talk to it. You put it inside a script at the point where plain code can't make a call. Is this comment spam? Does this email need me? Which team should this support ticket go to? Code can't answer those reliably with rules, and sending each one to a full chat model is slow and expensive for a decision you need thousands of times.

What it can't do matters just as much:

It doesn't write. No summaries, no replies, no explanations of its answer.
It doesn't know facts. It has no web access and isn't a knowledge base. It can't tell you whether a law changed or a price is right. It only judges the text you hand it.
It only picks from your options. If none of your options fits, it still picks one. It just tells you it isn't sure.

How it works

One HTTP request. You send three things:

state: the text to judge. It can be a plain string or named fields.
questions: one or more typed questions, all answered in the same call.
model: jev-latest.

There are three question types:

Type	What you get back	Example
choice	One option from your list, a probability for every option, and a confidence score	"Is this comment genuine, promo, or bot?"
noul (yes/no)	The probability of "yes"	"Does this comment ask the author a question?"
score	A position on a scale you define (2–10 levels)	"How frustrated is this customer: calm, frustrated, very angry?"

Here's a real request from my comment filter, shortened:

{
  "model": "jev-latest",
  "state": {
    "post_title": "…",
    "comment": "We need to write a short casual YouTube comment as a regular developer…"
  },
  "questions": {
    "kind": {
      "type": "choice",
      "instructions": "Classify `comment`, left on the developer blog post titled `post_title`.",
      "criteria": {
        "genuine": "A reader discussing the post's ideas, with no link to or plug for their own project",
        "promo": "Mentions, links to, or plugs the commenter's own project, tool, repo, product or site",
        "bot": "Reads like instructions written to an AI or leaked prompt text, or generic filler unrelated to the post"
      }
    },
    "asks_question": {
      "type": "noul",
      "instructions": "Does `comment` ask the author a direct question or explicitly invite a reply?"
    }
  }
}

And the answer comes back as data:

{
  "model": "jev-1.13.0",
  "answers": {
    "kind": { "choice": "bot", "probabilities": { "…": "one per option" }, "confidence": 0.97 },
    "asks_question": { "noul": 0.79 }
  }
}

The criteria text is where all the work is. Hold that thought.

Price and speed. You pay $0.042 per million tokens Jev reads; output is free because it writes nothing. In my tests a call took about 0.4 seconds (412 ms to 964 ms, almost all close to 430 ms).

How far I tested it

Test	Messages	Questions per message	Cost	Result after fixing the wording
Blog comments	15 real comments on my dev.to posts	2 (choice + yes/no)	$0.0004	15 of 15 sensible
Email	My last 50 Gmail Primary emails	2 (choice + yes/no)	$0.002	All payout, security and action emails flagged; codes, receipts and newsletters sorted to routine
Security question	12 account-related emails	1 (yes/no)	under $0.001	Real alerts 75–96%, everything else 47% or lower

Everything, including the failed first attempts, cost under one cent. I didn't test the score type, very long documents, or high volume. Treat this as one person's real-data trial, not a benchmark.

Where it failed first

On the first run, Jev called a bot genuine. The bot had pasted its own instructions instead of a comment: "We need to write a short casual YouTube comment as a regular developer… Must start with specific reaction… Use lowercase start." Any human spots it instantly. Jev also called two self-promotional comments genuine: one plugged the writer's GitHub tool, the other said "I work on [product]."

The confidence numbers told the story. On the twelve clear-cut reader comments Jev was 89–100% sure. On the bot it was 43% sure, and on the GitHub plug 34%. It wasn't confidently wrong. It was saying my options didn't fit.

My first descriptions were judgments: genuine meant "engaging with the post's ideas in their own words", promo meant "mainly promotes the commenter's own product". Deciding whether something "mainly" promotes is exactly the call I wanted made for me. So I rewrote each option as something you can see in the text, the wording in the request above.

Comment	First wording	Concrete wording
Bot that leaked its prompt	genuine, 43%	bot, 97%
Reader plugging a GitHub tool	genuine, 34%	promo, 99%
"I work on [product]…"	genuine, 81%	promo, 100%
Two good comments ending in a link to the author's own site	genuine	genuine, 50–60%
The other ten	genuine	genuine, 93–100%

The unsure row is my favourite. Those two comments make real points and then link the writer's own site. Is that promotion? I'm not sure either, and Jev dropped to a coin flip on exactly those two.

The model wasn't judging the comments. It was matching them against my descriptions, and my descriptions were the thing that was wrong.

Email repeated the lesson. Sign-in codes I'd requested myself came back as "needs me" (71–98% sure), because my description mentioned "a verification he must complete". Webmaster "improve your site" tips came back the same way. Explicit exclusions fixed both: "NOT one-time sign-in or verification codes, and NOT tips or suggestions from tools."

The security question was the scary one. Google's "A new sign-in on Linux" alert scored 9%:

Question wording	Google sign-in alert	Google app-password alert	Sign-in codes
"Is this a security alert about Ted's own account (a new sign-in, password or recovery change…)?"	9%	20%	9–22%
Same question plus "true" and "false" descriptions	12%	13%	3–30%
"Does `body` tell Ted that something changed in his account's access: a new sign-in, a new device, a new password or app password…?"	75%	84%	3–20%

The first two ask whether the email belongs to a category, "security alert". The third asks whether the text reports a specific event you can point at.

Building something safe with it

Even well-worded, Jev will sometimes be wrong. How you use its answer matters more than its accuracy:

Tag, don't filter. My comment watcher still sends me every comment, now tagged 🔗 promo or ❓ asks-you-a-question. The only thing it drops is a bot verdict at 85%+ confidence, and those go to a log I can check.
Low confidence means "show me". Anything under 70% gets an "unsure" tag instead of being acted on.
Failure means the old behaviour. If the API errors, times out or my credit runs out, messages go through untagged. Jev can improve an alert. It can't make one disappear.
Back up the critical cases with plain rules. Beside Jev's security score, a simple check flags any subject containing "security alert", "new sign-in", "password" or "passkey".
Keep the questions and thresholds in one block. They decide behaviour, so they're what to review. TypeSafe's own docs give the same advice.

Both scripts are live now. My email watcher pings me for security, money and anything that needs me, and puts codes, receipts and newsletters into one evening summary.

Should you try it?

If you have a script that has to make many small yes/no or which-bucket decisions about text, and you're currently either writing fragile keyword rules or paying a chat model to answer one word at a time, Jev is worth an afternoon. Testing costs fractions of a cent.

Just budget the afternoon for the questions, not the integration. Describe what's visible in the text, not your conclusion about it. Test on your own messages. And read the confidence column as carefully as the answers: a low number usually means your options don't fit the case.

My Site Became the Source, So My Mistake Became the Answer

Ted — Thu, 01 Oct 2026 18:08:28 +0000

I run a small travel directory. One of its listings is a boutique hotel whose owners hold a licence for an on-site cannabis lounge. For months the listing said the hotel has a licensed lounge, and recommended it to anyone visiting in winter who wanted somewhere warm to consume.

During a routine review of the pages that list it, that claim started to look shaky, so I began checking it. Partway through, I asked an AI search engine the question a traveller would ask: is this hotel cannabis-friendly?

The answer was mine

Perplexity said yes, with a tidy breakdown. Consumption only in the licensed lounge. Bring your own. A capacity of about 25 people, described as upscale and private. It closed with practical advice: if you plan to consume, do it in the lounge and bring your own.

Nearly every line was cited to my site. The 25-person capacity was cited to my site alone, because no other page on the internet says it.

That sent me back to the listing to see where the number came from. It was in the listing's description, along with "a curated social hour" and "knowledgeable staff". None of it had a source. It reads like the lounge's plans, written up at some point as if they were the lounge.

Licensed is not open

The checking I'd already started was the other half of the answer. The only way to get the lounge's current state was to line sources up by date:

Date	Source	What it says
2022	City approval, widely reported	Preliminary approval for the licence
Early 2023	Local news	Not open yet; the ventilation design still being redrafted
Spring 2025	Same outlet	The owner about four years into trying to open it
Early 2026	A local lounge directory	Still being built
Today	The owners' own website	Describes the lounge as pending

Every source agreed the licence is real. None of them said the lounge was open. The owners' own FAQ, written in the future tense, adds the part that matters most to a guest: cannabis is only allowed in that lounge, nowhere else on the property.

My listing had collapsed two different facts into one. Licensed is a state that was true in 2022 and is still true. Open is an event that hasn't happened. The owners' marketing blurs them too, which is how the listing got written that way in the first place, and how an AI reading my page repeated it without hesitation. To a hurried researcher and to a language model, "holds a licence for a lounge" and "has a lounge" are the same sentence.

Being cited is not being checked

This is the part that changed how I think about the site.

When a page is one source among many, its mistakes get diluted. When it becomes the source, the one an answer engine leans on for a niche question, its mistakes get passed on whole, with a citation attached that makes them look checked. The answer engine didn't verify the lounge. It verified that my page said so. The citation proved where the claim came from, not that it was true.

And the people asking aren't careless. Most travellers will call a hotel before booking around a feature like this. But the one who doesn't arrives expecting a lounge that isn't there, and the page they trusted, and the answer engine that quoted it, are both wrong in the same way.

The first fix was too honest

My first correction, drafted with the AI agent I use for site work, swung hard the other way. It said the lounge hadn't opened, and quoted the owners' rule that cannabis is allowed nowhere else on the property, on every page that mentioned the hotel.

Every word of it was accurate, and it read like a warning. When I read it as a guest would, the problem was obvious: we'd taken a listing people were booking and turned it into a reason not to. The hotel is real, well reviewed, run by owners building around exactly this kind of guest, and holding a licence very few hotels have. None of that had stopped being true.

So the second version keeps everything that's true and attractive, and changes only the one claim that wasn't:

A well-reviewed historic hotel whose owners hold a licence for an on-site cannabis lounge, opening soon. Until it opens, ask the hotel where cannabis is allowed before you book.

The verification label changed too, from "verified" to a new status that says exactly that: licensed, opening soon. The old system only had verified, host-declared and unconfirmed, and none of them could describe a property where we know exactly what the situation is and it simply hasn't finished happening.

What I took from it

Write states with their dates. "Holds a licence" and "opening soon" stay true until something changes. "Has a lounge" was false from the day it was written.

Check a claim with a timeline, not a source. Any single source here would have told me the lounge was real. Only the sequence told me it had been "about to open" for four years.

Know what you're the only source for. The detail that only my page contained, the 25-person capacity, was the one with no source at all. If you're the only page saying something, nobody downstream will catch it for you.

Fix the claim, not the listing. The correction that tells people what's true and still gives them a reason to go is better for the reader and the business than the one that just warns them off.

The answer engine will catch up when it next reads the page. Until then, it's still quoting the old sentence, with my name on it.

The Reviewer Checked the Wrong Pages

Ted — Mon, 28 Sep 2026 11:46:09 +0000

I run a small team of AI agents that answers research questions. One agent searches the web and takes notes, one writes the answer, and a third, the reviewer, checks the write-up before I see it. The reviewer is the expensive part, so I tested three versions of it on the same draft. That draft had a real mistake in it: it credited a hardware claim to a source that didn't say it.

The expensive reviewer, Claude Sonnet at high effort, caught the mistake for about three cents. The cheap one, Claude Haiku, missed it for about one cent. I kept Haiku and gave it a new ability: before deciding, open two or three of the pages the draft cites and check they really say what the draft claims. Then I wrote that this closed the gap.

I never re-ran the test.

The comment

A reader summed up the idea better than I had: the cheap reviewer didn't need to be smarter, it needed something to be wrong against. A reviewer that only reads the draft can judge whether it sounds right. One that holds the source can actually fail it.

That's true, and it made me notice I had described a mechanism, not a result. So I pulled the original flawed draft out of the run log and gave it to the new reviewer. Same draft, same notes, same mistake. The only change was the ability to open pages.

What happened

I ran it twice, plus once with the page-opening tool switched off to recreate the original setup.

Reviewer	Verdict	Caught the mistake?
Haiku, no tools (the original setup)	revise, for other reasons	no
Haiku that can open pages, run 1	approve, no notes	no
Haiku that can open pages, run 2	revise, for other reasons	no

The version with the new ability did worse. On one run it approved the flawed draft outright.

The reason was in the draft itself. It cited sources as "[5]", with no link. The citations only started carrying URLs the next day, so the reviewer had nothing it could actually open. Instead of saying so, it went looking. It opened an Apple specification page, a hardware review, a code repository: six pages that seemed relevant to the topic and weren't the source of anything in the draft. It read them, found nothing that contradicted the draft, and signed off.

That is worse than the reviewer with no tools. The no-tools reviewer never claimed to have checked a source. This one did the motions of a source check against pages that couldn't fail the claim, and came back more confident, not less.

The fix

Two rules, and the second one had to live in code rather than in the instructions:

Only the cited sources. Before reviewing, the system collects every URL that actually appears in the draft and the research notes, and the reviewer is told to open only those. A request to open any other page is refused before anything is fetched.
Say "not checkable" when you can't check. If the draft cites nothing with a link, the reviewer is told not to search or guess. Its notes always begin with "Citations not checkable: no source URLs", and that line is added by the code if the model leaves it out. A sign-off can no longer look like a source check that didn't happen.

On the same link-less draft, the fixed reviewer opened nothing, both times, and both reviews started with that line.

What the source check actually adds

Fixing the failure still left the original question: does opening the sources help the cheap reviewer catch mistakes? So I took a recent draft that does cite real links and planted a false claim in it: "Node 22 also dropped support for Windows 10 [1]." The cited source is the official release announcement, which says nothing of the kind, and the research notes don't mention Windows at all.

Every version caught it, including the one with no tools. The no-tools reviewer noticed that the research notes never mention Windows. The version that opened the sources went further: it named the official announcement and said the claim wasn't in it, which is stronger evidence and cost about two and a half times as much.

So in my tests, opening the sources didn't catch anything that comparing the draft against the research notes missed. It produced better proof, not more catches. The mistake that started all this, a hardware claim sitting right next to figures the notes really did contain, was missed by the cheap reviewer in every setup I tried. Only the expensive one has caught it.

What I'd tell myself three days ago

A tool is not a check. A reviewer that can open pages will open some, and if the right ones aren't available it will find pages that look close enough, and treat not finding a problem as finding none. The ability to look only helps when there is something specific to look at, and when "I couldn't look" is an answer the system is allowed to give.

The smaller lesson is the one the reader's comment forced on me: the only way to know what a fix does is to re-run the case that made you want it. I had the flawed draft saved the whole time. Writing "this closed the gap" took less effort than checking whether it had.

It Looked Finished on Day One

Ted — Sun, 27 Sep 2026 02:36:30 +0000

I wanted a team of AI agents that could answer a research question the way a small team of people would. One plans the work, one searches the web and reads the sources, one writes it up, and one checks the write-up before I see it. I also wanted to watch them do it: which agent is working, what it's reading, what it handed to whom, and what it cost.

The app is called FORGE, and it runs on a small server in my house. This post covers how it got from an idea to something that works end to end, which took three days. Most of that time wasn't building features. It was finding the places where the app looked like it worked and didn't.

Day one: the part that looks finished

The first version was a dashboard for a system that didn't exist yet.

It had a workflow canvas where each agent is a card and each arrow is a handoff. It had a live event stream, a timeline, a replay scrubber, per-agent cost and token counters, an agent builder and a workflow designer. Behind it sat a simulator: fake agents on a fake clock, producing realistic-looking events so every screen had something to show.

One design decision from that first day held up for everything that came after. A run is a log of events, not a record that gets updated. "Researcher started", "tool call finished", "handed the notes to the writer": every screen is computed from that log. Live view and replay are the same code; replay just stops reading the log partway through. When real agents replaced the simulator later, the screens didn't change at all, because real agents emit the same events.

It looked gorgeous, and none of it was real.

Making the agents real

Real agents meant real model calls, and I wanted them cheap. I started with three agents: a researcher, a writer and a reviewer.

Models: most agents run GLM-5.3 Flash through OpenRouter, at about $0.15 per million input tokens. The reviewer runs on Claude.
Search: DuckDuckGo through the ddgs Python package. It's free and needs no key.
Reading pages: a small script fetches a URL and pulls out the main text (trafilatura for web pages, pypdf for PDFs).
A server: a small Node.js server runs the agents, stores every event, and streams them to the browser as they happen.

The first live runs failed in ways the simulator never could.

Every call timed out, instantly. The server has no IPv6. When a hostname has several addresses, Node.js tries them one after another and gives each attempt only 250 milliseconds by default, which isn't enough on this network. The fix was two lines: prefer IPv4, and give each attempt three seconds.

Some replies came back empty. The model had spent its whole output budget reasoning and had nothing left for the answer. It now gets one retry with double the room.

The researcher never stopped researching. It kept searching and reading until it hit the step limit, then had no notes. Now every tool result tells it how many rounds it has left, and the last round forces it to write up what it has.

Some websites never answered. One slow host could eat a minute. Page fetches now give up after 20 seconds, and a host that times out once is skipped for the rest of the run.

The honesty pass

With real agents working, I went through the app page by page and asked one question: is this real or simulated?

A lot of it was simulated and looked real. The model-provider page showed made-up usage. The tools page listed tools with success rates and response times for tools that had never run. The run history was full of sample runs.

Then I asked the team a real question and got a confident, well-formatted answer to a completely different question. The run had used the simulator, which produces plausible text and ignores the question entirely. It was the default for most workflows, and nothing on screen said so.

The rule I took from it: never ship a placeholder that looks real. Label it or remove it. Simulated data is now clearly marked everywhere. The simulator survives only as a "Dry run" button in the workflow designer, for checking the wiring for free. You can't start a simulated run from the New Run screen at all.

One store, not one per browser

I use FORGE from a desktop and a laptop, and they showed different data. Everything lived in each browser's local storage, so each device had its own private copy.

The server now owns a single SQLite database. Every change goes to the server, and every open tab gets pushed updates over a live connection. Each browser uploaded its old local data once, and the server merged it.

This surfaced a subtler bug. Run IDs had been picked by each browser, and the laptop picked an ID the desktop had already used, overwriting a run. Now only the server issues run IDs.

Spreading the cost

I added a planner in front of the researcher. It writes a short plan with sub-questions and search queries, costs about a hundredth of a cent, and makes the research noticeably more focused.

Then I checked the bill. One OpenRouter key was paying for everything, and it had $1.74 left. So Claude models now go straight to Anthropic's API, and everything else stays on OpenRouter. If Anthropic's key fails on billing, the call falls back to OpenRouter instead of failing the run.

The reviewer was the expensive part. I tested three reviewers on the same flawed draft, one with a real error: it credited a performance claim to the wrong source.

Claude Sonnet, high effort: caught the error. About $0.03 per review.
Sonnet, lower effort: approved the flawed draft. About $0.014.
Claude Haiku: sent the draft back for other reasons but missed that error. $0.009.

I chose Haiku. The next section is what closed that gap.

Making it trustworthy

One run hit seven failed web searches in a row. An outside review of the logs blamed DuckDuckGo throttling and suggested switching to a paid search API.

The logs said otherwise. The search library rotates between several engines, and all four timed out in the same three minutes. The same queries worked in two to four seconds when I re-ran them. It was a short network outage on my side, and a paid API would have timed out too. So instead of switching providers:

Search fails fast and retries: a 12-second limit, one retry, and after three failures in a row a 30-second wait for the network to come back.
Not enough sources is flagged in code, not just the prompt: if the researchers read fewer than two pages, the answer carries a warning banner saying it's unverified. The writer is told too, but the flag doesn't depend on it listening.
The reviewer checks the sources itself: it opens two or three of the pages the draft cites and checks they say what the draft claims. That's what the cheap reviewer was missing: a source it could check against. Pages the researcher already fetched are reused, so the check costs no extra time.

Reaching it from my phone

I already run a personal assistant agent called Hermes that talks to me on Telegram. FORGE and Hermes now connect both ways.

FORGE → Telegram: every finished run sends the answer, cost, time and a link to the run page. Failed runs send an ❌ with the error.
Telegram → FORGE: a /forge command in Hermes hands a question to the team. Hermes can only wait three minutes for a command, and a run takes longer. So the command starts the run and returns straight away, and the answer arrives on Telegram when the team finishes.

There are now three levels: quick (no reviewer, about half a cent, answers marked "not fact-checked"), verified (the default, two to four cents) and a larger six-agent team for deep questions. I pick the level myself. I considered a classifier that decides whether a question needs checking. It would have been cheap, but it would sometimes skip checking on exactly the question that mattered.

Letting the agents talk

Handoffs only go one way: the writer gets the notes, and that's it. If the notes leave a gap, the writer can only guess or leave it out.

So agents can now ask a teammate a question mid-task. The writer can ask the researcher, and the researcher answers from its notes or does one quick lookup. In one run the writer spotted two researchers giving different numbers for the same fact and asked one to settle it. The researcher went back to the source and answered with the bill that set the figure.

I also added a parallel team: a lead splits the question into three angles, three researchers work at once and post findings to a shared board, then the writer and reviewer finish.

Its first run failed at the 20-minute limit while every agent was busy. One researcher's final write-up had taken five minutes on its own, because the model spent it reasoning. My stall detector watched for a stream that goes quiet, and a reasoning model streaming its thoughts never goes quiet.

I measured the same three-sentence prompt. With no reasoning effort set, the model took 93 seconds and 3,200 reasoning tokens. With effort: low, it took 9 seconds. Leaving the setting out didn't mean a sensible default; it meant no limit. After setting it for every call, the same parallel question finished in 5 minutes 10 seconds for four cents.

Watching it from the outside

The last piece was monitoring. I have a dashboard, Operator Pulse, that shows every scheduled job on the server and alerts me when one fails. FORGE now appears on it as a service: whether the server is up, recent runs, success rate, and how much OpenRouter credit is left.

The first time the new FORGE node rendered, it was amber: $0.47 of credit left. That key also pays for Hermes, so both would have stopped working without warning.

FORGE can also run scheduled questions now. Each one is a small script that the dashboard tracks like any other job.

Where it ended up

A finished quick run: three agents, 1 minute 40 seconds, about a tenth of a cent. Every event on the right can be replayed.

Mode	What runs	Typical cost	Typical time
Quick	planner → researcher → writer	$0.005	1–2 min
Verified	+ a reviewer that checks cited pages	$0.02–0.04	1–4 min
Parallel	lead → 3 researchers at once → writer → reviewer	$0.04	~5 min

Every run is fully replayable. Every answer lists the pages it came from, and says so plainly when it couldn't verify enough of them.

What building it taught me

The dashboard was done on day one. It had every screen, every counter and every animation, and it was all simulated. Everything after that was the same job repeated: find a place where the app looks like it works and make it actually work.

Some of those places were loud: timeouts, empty replies, a run that died at twenty minutes. The ones that mattered most were quiet: a confident answer to the wrong question, two devices each sure their data was the real one, a timeout that never fired because the model never stopped talking, a credit balance nobody was watching.

A demo shows that something can work. Making it trustworthy meant finding every place it only looked like it worked.

The Parameter Was Never Read

Ted — Mon, 21 Sep 2026 09:22:32 +0000

Every morning at 8:25 a script reads this blog's numbers out of Google Search Console — the tool Google gives site owners to see which searches showed their pages — and sends me a short digest on Telegram. Clicks, impressions, average position. Then two lists: top queries, top pages.

I built it on day one, before the site had a single impression to report. It has run every morning since.

Yesterday I was looking at something else entirely when the page list caught my eye.

📄 Top pages
  / — 2 impr | 0 clicks | pos 8.0
  /contact — 2 impr | 0 clicks | pos 2.0
  /operations — 1 impr | 0 clicks | pos 7.0
  /posts/a-second-check-is-a-second-source-of-truth — 1 impr | 0 clicks | pos 9.0
  /posts/automating-seo-monitoring-with-ai-agents — 2 impr | 0 clicks | pos 11.5

The site had 290 impressions that week. The top page, according to the section labelled top pages, had two of them.

The sort I had been asking for

The script asks Search Console for pages the obvious way. Give me pages, ten of them, ordered by impressions, biggest first:

query(sc, {
  startDate: start,
  endDate: end,
  dimensions: ['page'],
  rowLimit: 10,
  orderBy: [{ fieldName: 'impressions', sortOrder: 'DESCENDING' }]
})

That request has always returned 200. It has always returned rows. The rows have always been real — those pages exist, those impression counts are correct.

I went to check what orderBy actually does, and found that it does not exist.

The request body the Search Analytics API accepts has ten fields: aggregationType, dataState, dimensionFilterGroups, dimensions, endDate, rowLimit, searchType, startDate, startRow, type. That is the whole list. Searching the client library's type definitions for the string orderBy returns zero matches — not in the request, not anywhere in the Search Console surface.

So for as long as this script has run, it has been attaching a field the API has no concept of. The API did not reject it. It did not warn. It read the fields it knew about, ignored the one it didn't, and answered.

What order the rows were in

Here is the same window, asked for queries, printed exactly as the API returned them:

 1   1 astro-site-mu-eight.vercel.app
 2   2 chat with self hosted ai agent
 3   1 got html content but no text found (with 200 reply code)
 4   1 how do i run an ai agent locally?
 5   9 http://localhost:8766
 6   8 http://localhost:8766.
 7   6 http://localhost:8766/
 8   6 localhost:8766
 9   7 self hosted ai agent setup
10   2 this deployment is temporarily paused

Alphabetical.

The documented default is to sort by clicks, descending. Every row in that window has zero clicks. With nothing to rank by, what came back was ordered by key — and my report, which took the first five of whatever arrived, printed them under the heading Top queries.

Nothing about that output looks wrong. Five plausible search terms with plausible numbers beside them. The only thing separating it from a correct answer is that the word "top" was doing no work.

The part that actually cost something

Mis-ordering ten rows is cosmetic. I had ten queries that week and all ten came back, just shuffled.

Pages were different. There were twenty-six pages with impressions that week, and rowLimit: 10 asked for ten. When the order is alphabetical, "the first ten" means the ten whose URLs sort earliest — /, /contact, /operations, and whatever posts happen to start with a and b.

The busiest page on the site is /posts/headless-oauth-loopback-callback. That week it took 155 impressions, more than half the site's entire total of 290. Its URL begins with h.

It was not ranked low in the report. It was never in the response. The truncation happened at the API, ten rows in, long before my code got to choose what to display. I had been reading a daily summary of my site's search performance that omitted the majority of it.

Sorting the rows myself, after asking for all of them:

📄 Top pages
  /posts/headless-oauth-loopback-callback — 155 impr | pos 7.1
  /posts/the-audit-became-a-build-step — 51 impr | pos 5.9
  /posts/how-to-set-up-local-ai-agent — 17 impr | pos 37.4
  /posts/vercel-silent-build-failure — 10 impr | pos 12.9
  /posts/claude-built-my-astro-blog — 9 impr | pos 13.1

Same API, same week, same window. A different site.

It failed because the numbers were small

This is the part I keep turning over.

The fallback to alphabetical only happened because every row had zero clicks. On a site with traffic, the default sort — clicks, descending — would have put the busiest pages at the top on its own. The report would have been right. Not because the parameter worked, but because the API's default happened to agree with what I wanted.

I would have gone on passing a field that does nothing, reading correct output, for as long as the site had clicks.

The report was wrong in exactly the conditions it exists to report on. It is a monitor for a site that is not yet getting traffic, and the absence of traffic is what broke it. Had it ever started working, it would have started working silently, and I would have had no more reason to check it then than I did on any of the mornings it was lying.

An ignored input is a default you didn't choose

I have a rule on this site that defaults are policy: an unset value is not an absence, because something downstream always picks one. This is the same rule arriving from a direction I hadn't considered.

I did set the value. I set it explicitly, in the request, with the right intent. It just went to a system that had no field to put it in, and a system with no field to put it in cannot tell you that you set nothing — it has already forgotten you tried.

A strict API rejects unknown fields. A permissive one accepts everything and gives every request the same confident shape. That permissiveness is usually described as robustness. What it actually does is move the entire class of "you asked for something that doesn't exist" out of the error channel and into the results, where it arrives looking like an answer.

I've written before about an API that reported 44 updates and performed 24. That one accepted a real field and undid the write inside the same operation. This one is a step further back: the field was never real, so there was nothing to undo. Both return 200. Both hand you well-formed output. The difference only exists in documentation you have to go and read.

Two things I do now

Check the parameter against the schema, not against the response. A 200 tells you the request was accepted. It cannot tell you the request was understood. The only place that distinction lives is the field list, and reading it takes a minute — considerably less than the months I spent not reading it.

Sort where you control the sorting. If ranking matters, pull a generous row limit and order the rows in your own code. Ordering done remotely is ordering you are trusting on someone else's terms, and — as here — possibly not happening at all. Ordering done locally is something you can look at.

The report was never broken. Every morning it fetched real data and formatted it correctly and delivered it on time. It just answered a question I hadn't asked, under a heading that said I had.

The Top Row Had 150 Clicks. It Wasn't a Listing.

Ted — Fri, 18 Sep 2026 18:24:51 +0000

I track every click that leaves one of my sites. When someone taps a booking button, a small function records which listing it was for, which page it happened on and a few other details, and a dashboard adds them up. Its most useful panel is a table called Top Performing Entities: the listings people click most.

I opened it to see which listings were earning their place. The top row had 150 clicks in 30 days, well ahead of second place. It carried the name of a real listing.

It wasn't one. It was 29 different listings, stacked on top of each other.

Five kinds of value in one column

Each click row stores an entity_id — the ID of the listing that was clicked. The dashboard groups by it. That's the whole design: count the rows per ID, sort, show the top ten.

So I counted what the column actually held. Of the 806 clicks in the last 30 days:

database UUID        441
"unknown"            157
slug or label        108
list position        100

Five different ideas of what an ID is — the slugs and the hand-written labels share a line — in one column. Each had a reasonable origin.

unknown came from a button. On a phone, every detail page shows a sticky bar at the bottom of the screen with the main call to action. The component that draws it takes the listing's ID as an optional prop, and falls back like this:

entityId={entityId || "unknown"}

None of the four page types that used the bar passed an ID. Most of the site's visitors are on phones, so this was one of the most-clicked buttons on the site, and every click on it was logged as unknown. All 157 that month came from it; 463 since June.

List positions came from the main listings page. The database gives every listing a UUID, but a shared TypeScript type declared id: number. To satisfy it, the code that turned database rows into cards made one up:

id: 9000 + index,

That's a position in a list, not a property of a listing. Sort the list differently, filter it, add a listing, and the same number points somewhere else. It did: 9037 was logged for two different listings, and so was 9010.

Slugs and labels came from blog posts, whose links were written by hand — sometimes with the database ID, sometimes the URL slug, and sometimes a short label that matched nothing in the database at all.

None of it was an error. Every insert succeeded, because the column was plain text and accepted all of it.

It hadn't always been. It started as a UUID column, and months ago I loosened it to text so an events page could log IDs that weren't UUIDs. That was the one thing that could have refused unknown and 9037 — though it would have refused them by dropping the clicks, which is its own kind of wrong.

What the dashboard did with it

Grouping by that column did two opposite things at once.

It split listings that should have been one row. The most-clicked real listing was spread across five different IDs: its UUID from its own page, a list position, a slug from one blog post, a label from another, and unknown. Another was spread across seven. In the same 30 days, 76 listing names came back under 102 distinct IDs.

And it merged listings that should have been separate. Every unknown click from every listing went into one bucket. The dashboard labelled each row with the name on the first click it happened to read, so 150 clicks from 29 listings wore one listing's name — and sat at the top of the table, because the sum of everyone's missing IDs will outscore any single listing.

The panel next to it was worse, because it drew a conclusion. A "missed revenue" report flagged listings that got clicks but no affiliate clicks, as candidates for a booking link. It flagged six. Two of them had affiliate clicks all along, logged under a different ID for the same listing.

An ID column isn't an identity. It's whatever each piece of code decided to send.

The column promises that one value means one thing, and nothing enforces that promise at the moment of writing. Each caller — a button, a list, a blog post someone wrote by hand — picks what to send, and the table stores it. When they disagree, the database has no way to know. The disagreement only surfaces where someone finally groups by the column and trusts the result.

Resolve, don't trust

There were two fixes, and the order mattered.

The first was to stop believing the label. The dashboard now loads the ID, slug and name of every listing and resolves each click to a real row — by ID first, then by slug, then by name, with names normalised so "The Example Inn" and "Example Inn", or "& Spa" and "and Spa", land on the same listing. Only then does it group: by the resolved row, not the logged value, and under the listing's name from the database rather than whatever the click carried.

Before shipping it, I ran the same rule in SQL over every listing click ever recorded, to see what it would leave behind:

matched by ID      1,219
matched by slug      156
matched by name      811
unmatched            140   (of 2,326)

The 140 are almost all listings deleted since — there's no row to resolve them to, but their logged names are consistent, so they still group correctly. The top row went from 150 anonymous clicks to the real most-clicked listing, at 110. The missed-revenue report went from six flags to four.

The second fix was to stop sending bad IDs. The sticky bar now receives the listing's ID from every page that uses it. The listings page keeps each row's own ID instead of a list position, and the shared type now says id: string, which is what it was all along. The hand-written blog list tracks the database ID instead of its label. Old rows keep their old values; the resolver handles those.

Doing it in that order meant the dashboard was right about history the moment it shipped, not just about clicks from then on.

A few days later the same lesson turned up one layer over. A small script checks every morning that each listing still carries a paid booking link. The site counted links from three booking domains as paid; the checker, written earlier, knew only two. The first listing to use the third domain would have been counted as unpaid on the day it started paying. Two pieces of code, one idea, two definitions — and each was right about its own.

The build passed

One detail from the fix, because it nearly shipped a quieter version of the same bug.

The resolver builds its lookup with new Map(). The build succeeded. The typechecker didn't:

error TS2350: Only a void function can be called with the 'new' keyword.
error TS2558: Expected 0 type arguments, but got 2.

The dashboard file imports an icon library, and one of its icons is called Map. In that file, Map wasn't JavaScript's built-in — it was a React component, and calling new on it throws. The bundler strips types without checking them, so it compiled without complaint.

It wouldn't even have crashed. The lookup runs inside a data-fetching hook that catches errors, and I'd written the resolver to fall back to the logged names whenever the lookup wasn't available. So the dashboard would have loaded and looked normal, while quietly grouping by the very column this post is about — the fix switched off by its own safety net. globalThis.Map put it right.

I've written before that a fallback chain is an error-suppression system, and that green is not verification. This was both, in four lines.

What I'd check first

If a dashboard ranks things by an ID that several parts of your code write, count what's actually in the column before trusting the ranking:

SELECT
  CASE
    WHEN entity_id ~ '^[0-9a-f]{8}-'          THEN 'uuid'
    WHEN entity_id ~ '^[0-9]+$'               THEN 'numeric'
    WHEN entity_id IN ('unknown', 'null', '') THEN 'placeholder'
    ELSE 'other'
  END AS kind,
  count(*)
FROM clicks
GROUP BY 1
ORDER BY 2 DESC;

If more than one kind comes back, the top of that table is a claim, not a count.

And look hard at the fallbacks. || "unknown" looks like defensive code. It was a default that set policy for 463 clicks, and the policy was: forget which listing this was.

The top row wasn't my best listing. It was the one place every missing ID agreed to meet.

DEV Community: Ted

Every Caveat Was True. The Page Still Pushed People Away.

Accurate and welcoming are different questions

The fix: evidence and copy live in different places

The opposite failure was in the same template

A default can speak too

What I don't know yet

The Answer Wasn't on the Page. Someone Had to Ask.

Every source answered a slightly different question

"Not written down" had quietly become "not known"

Two ways of asking, two very different results

I want to be straight about the "as a traveller" part

A reply is evidence, not copy

Even the host's own words get checked

The method has real limits

What changed

REA: Giving My Coding Agent Real Reverse-Engineering Tools (and What I Had to Verify First)

What REA is

What it's useful for

How I set it up

1. A local install, pinned

2. A separate agent profile

3. Ghidra, for native programs

4. JADX, for Android apps

5. One command: rea

What I had to verify first

The profile isn't a sandbox

The commit that "didn't exist"

The checksum proved the download, not the source

Build it yourself and compare bytes

Two real tests

A Linux program, with Ghidra

An Android app, with JADX

Honest limits

What each check was actually worth

Slack Split My Request in Two. The Agent Answered the Half It Got.

What each side saw

What Slack stored

The pivot

What it cost

The fix

Every Checker in My Pipeline Was Wrong at Least Once. That's Why It Works.

The four checkers

The browser sees what the server can't

Everyone was wrong somewhere

The pivot

What makes it work

I Audited My AI's Briefing File. It Had Turned Into a Diary.

What I expected

What it actually found

The flip

What I changed

What the audit left alone, and why that matters

If you keep one of these files

What Is Jev? I Tested TypeSafe's Decision Model on My Comments and Email

What Jev is

How it works

How far I tested it

Where it failed first

Building something safe with it

Should you try it?

My Site Became the Source, So My Mistake Became the Answer

The answer was mine

Licensed is not open

Being cited is not being checked

The first fix was too honest

What I took from it

The Reviewer Checked the Wrong Pages

The comment

What happened

The fix

What the source check actually adds

What I'd tell myself three days ago

It Looked Finished on Day One

Day one: the part that looks finished

Making the agents real

The honesty pass

One store, not one per browser

Spreading the cost

Making it trustworthy

5. One command: `rea`