← Context/ issues
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.
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?