Follow-up to chat#1833 (task-email hallucination — closed 2026-07-02). While re-benchmarking Steph@OneRPM's 3 scheduled tasks against a fully corrected artist record, we found that headless runs receive the run's artistId but never surface it to the agent — so any task prompt that doesn't hand-embed the artist id sends the agent roster-guessing, where it nondeterministically lands on the org-scoped roster and can't find the artist at all.
Decision (2026-07-02, @sweetmantech): dropped the skills-side roster hardening (skills#71 closed unmerged). api#742's injected context already tells agents to use the given artist id; org and personal rosters are legitimately different sets (neither is authoritative), so "check personal before concluding absence" was a wrong assumption; and the API layer already resolves artist ids across both scopes (checkAccountArtistAccess: personal account_artist_ids OR shared org — no org_id needed for /api/artists/{id}/*).
Goal
Every headless agent run knows which artist it's running for. customer-prompt-task → POST /api/chat/runs already carries artistId on every scheduled run; the agent's system prompt must expose it (plus account_id) the same way the interactive chat does — so implicit-artist prompts ("Check if there are any new YouTube videos…") resolve deterministically instead of depending on prompt authors remembering to paste UUIDs. Surfaces: app/lib/workflows/runAgentStep.ts / lib/chat/buildAgentSystemPrompt.ts (headless prompt), lib/chat/buildRunAgentInput.ts (input threading), and the recoup-platform-api-access skill's roster-discovery guidance.
PRs (updated 2026-07-02)
| PR |
Item |
Base |
State |
| api#742 |
Thread artistId into the headless agent prompt — buildRunAgentInput + RunAgentWorkflowInput + runAgentStep → buildAgentSystemPrompt emits an IMPORTANT CONTEXT VALUES block (artist_account_id, account_id) like the interactive chat |
main |
✅ merged 2026-07-02 — see Done · primary fix |
| skills#71 |
Harden roster discovery in recoup-platform-api-access — prefer the run's artist context when present; never conclude "artist not found" from the org-scoped list alone (query the personal roster GET /api/artists before giving up) |
main (skills) |
❌ closed 2026-07-02 unmerged — superseded by api#742; see decision below |
Merge sequencing: the api prompt-injection fix is primary and independent; the skills hardening is defense-in-depth for runs with no artist context. Either can merge first.
Done
Open — thread artistId into the headless agent prompt
Open — roster-discovery hardening (skills)
Source references
- Parent: chat#1833 (closed) — the grounding/persistence fleet this rides on.
- Benchmark evidence: this issue's first comment (task prompts + round-1/round-2 email outcomes).
- Task→run plumbing:
tasks/src/tasks/customerPromptTask.ts (passes artistId from taskConfig on every scheduled run).
Follow-up to chat#1833 (task-email hallucination — closed 2026-07-02). While re-benchmarking Steph@OneRPM's 3 scheduled tasks against a fully corrected artist record, we found that headless runs receive the run's
artistIdbut never surface it to the agent — so any task prompt that doesn't hand-embed the artist id sends the agent roster-guessing, where it nondeterministically lands on the org-scoped roster and can't find the artist at all.Goal
Every headless agent run knows which artist it's running for.
customer-prompt-task→POST /api/chat/runsalready carriesartistIdon every scheduled run; the agent's system prompt must expose it (plusaccount_id) the same way the interactive chat does — so implicit-artist prompts ("Check if there are any new YouTube videos…") resolve deterministically instead of depending on prompt authors remembering to paste UUIDs. Surfaces:app/lib/workflows/runAgentStep.ts/lib/chat/buildAgentSystemPrompt.ts(headless prompt),lib/chat/buildRunAgentInput.ts(input threading), and therecoup-platform-api-accessskill's roster-discovery guidance.PRs (updated 2026-07-02)
artistIdinto the headless agent prompt —buildRunAgentInput+RunAgentWorkflowInput+runAgentStep→buildAgentSystemPromptemits anIMPORTANT CONTEXT VALUESblock (artist_account_id, account_id) like the interactive chatmainrecoup-platform-api-access— prefer the run's artist context when present; never conclude "artist not found" from the org-scoped list alone (query the personal rosterGET /api/artistsbefore giving up)main(skills)Done
artist_account_idin the agent system prompt.✅ Merged 2026-07-02 (squash to
main, commit80b1d500).buildAgentSystemPromptemits anIMPORTANT CONTEXT VALUESblock (artist_account_id + account_id) whenever the run carries them; threadedbuildRunAgentInput→RunAgentWorkflowInput→runAgentStep; headless passes the validatedartistId, interactive passessession.artist_id.Verified on preview (results): the implicit-artist Cosculluela prompt that went 0/2 on main passed first-run — 3 direct calls with the injected id, 0 org-scoped lookups, 0 "Rostrum Pacific", fresh scrape of the real 8.28M-sub channel, honest conditional no-op ("No new video in the last 24 hours").
Open — thread
artistIdinto the headless agent promptartist_account_idin the headless prompt — ✅ shipped api#742, see Done.Open — roster-discovery hardening (skills)
Dropped 2026-07-02 — superseded by api#742 (see decision callout above); skills#71 closed unmerged. The API already authorizes artist ids across personal + org scopes, and the injected context removes the discovery step entirely for runs that carry an artist.recoup-platform-api-access: never conclude "artist not found" from the org roster alone.Source references
tasks/src/tasks/customerPromptTask.ts(passesartistIdfromtaskConfigon every scheduled run).