[gabrielsayers1]

Three changes, all falling out of the 2026-08-21 batch of five prospect-research runs.

Run prospect-research on Opus

Via the manifest's phoenix block — the same per-workflow override ping already uses for Haiku. Cost x quality: the research agents don't need Fable.

PHOENIX_MODEL still defaults globally, so nothing else changes.

Measured on five runs: 5-6 minutes each, 20-23 tool calls against a ~30 call budget. Two runs discarded uncorroborated claims rather than using them — the Jobber agent rejected an unverifiable Super Bowl ad story and said so in its result.

Sharpen the first-party sweep

Step 2's first sweep goes from "search the blog" to "enumerate the blog index, sort by date, read the most recent."

This is the sweep that finds the best hooks, and enumeration is why. On the Wispr run, given only company, domain, contact name and title, the agent enumerated all six of Daniel McCallum's blog posts and took the newest — which became the run's best hook. That post is not indexed by search at all. Enumeration beat search outright.

Correct what the file says about Clay

It claimed Clay "confirms facts better than it discovers stories", which reads as though Clay discovers stories at all. Tested, it does not:

• Asked directly for a contact's recent LinkedIn posts, it reports needing session cookies.
• For a contact known to have posted weeks earlier, it returned "no recent posts found" — a false negative.
• Against the Wispr hook as a control, it returned three items and missed the one that mattered.

Clay stays where it is excellent: identity resolution, role history, verified email. The step now also says to call it whenever an email is missing — one draft in this batch was created with no recipient.

New: docs/research-sourcing-limits.md

Records the measurements behind the above, and sketches the agent-browser link harvester that would close the LinkedIn gap.

The design insight is that LinkedIn is a pointer layer, not a content layer — we need the outbound links from recent activity, not the post prose, because the substance lives on blogs and podcasts we can already fetch. That makes the harvester cheap and gracefully degrading.

It is design only. Automating a logged-in session is against LinkedIn's User Agreement and the exposure is a real account, so it's an operator decision rather than a technical one. The doc states the trade-off and stops.

Not included

Nothing here changes runtime behaviour beyond model selection. No new dependencies, no schema changes.

Note for whoever deploys: the live worker reads workflows from the ops-hub worktree, which currently carries the same manifest edit uncommitted so the flow keeps working. Once this merges, pull there and that edit becomes redundant.

🤖 Generated with Claude Code

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.}