← Corpus / augment-it / issue
The search column holds stale results — a new agent search doesn't reload it
The team crawl bypasses the Search & Add envelope, so the column sits frozen on the last search's candidates, masquerading as current.
- Path
- issues/Search-Column-Holds-Stale-Results-New-Agent-Searches-Dont-Reload-It.md
- Authors
- Michael Staton
- Augmented with
- Claude Code on Claude Fable 5
- Tags
- Issue · Usability · Augment-It · Search-And-Add · Didi-Crawl · Org-Workbench
The search column doesn’t follow the latest search
The symptom (operator-reported, 2026-07-24 evening)
- 🤖 crawl on identity links → the Search & Add column opens with candidates. Good — that column is where results belong.
- Fire the next agent search — the people/team crawl — and the column keeps the old identity-links results. Nothing tells the operator they’re looking at a previous search; the new search’s activity isn’t reflected there at all.
Why (two designs colliding)
- The links/streams crawls ride the Search & Add envelope
(
augment-it:search-request), so a NEW envelope does reload the column — but only those targets send one. - The team crawl deliberately bypasses the column: its candidates stage
on the workbench’s People section (
StagedPeople), per the accept-gate design. Nothing clears or re-labels the Search & Add pane, so it sits frozen on the last envelope — stale results masquerading as current.
The operator’s mental model is simpler and better: the third column is THE results surface; whatever agent search ran last is what it shows.
Direction (jotted)
- Either route team-crawl results into the column too (person-shaped rows with the same accept gate the staged section has — the column becomes the one home for every crawl’s candidates), or
- Keep the split but make the column state honest: a new agent action anywhere (team crawl included) clears or visibly supersedes the pane (“results from a previous search — re-crawl to refresh”), and the pane header always names the search that produced what’s shown (target + org + when).
- Either way, results want a timestamp/provenance line — “identity links · Quell Foundation · 5:35pm” — so stale can never impersonate fresh (the day’s recurring stale-state theme; [[Crawl-Progress-Is-A-Black-Box-Needs-Traces-The-Operator-Can-Watch]] is the sibling on the same pane).
Open questions
- Do person-shaped candidates belong in ResultRow (url-centric today) or does the column grow a second row type? (The component-library issue looms here.)
- Should the column auto-clear when its launching org card changes (roster click elsewhere), independent of new searches?