Based on a real day; names and selected personal details have been changed or omitted.

https://research.example.invalid/?view=assistant&sessionId=example-session-0001 If you look at this chat history , it asks me too much and expects me to know to much about the data IT has. For example , this response : Great—what do you want to do with ACS PUMS? Do you already have an ACS PUMS dataset in your workspace, or s

May 11 · 10:12 AM · User Source JSON

https://research.example.invalid/?view=assistant&sessionId=example-session-0001

If you look at this chat history , it asks me too much and expects me to know to much about the data IT has.

For example , this response :

Great—what do you want to do with ACS PUMS?

Do you already have an ACS PUMS dataset in your workspace, or should I register one? Which vintage (e.g., 2022 1-year or 5-year), geos/states, and file(s) (person, household)? What’s the goal (e.g., income by occupation, housing costs, commute patterns, demo slices)? Do you want a quick sample/summary first or to set up a full analysis run?

or this one (i had to hand hold it) :

I don’t see an ACS PUMS dataset in your workspace yet.

Want me to register and deploy ACS PUMS (2018–2022 5-year, New York; person + housing), filter to NYC PUMAs, and kick off a run to generate Census Reporter–style sections and charts broken out by race?

or this one :

You’re likely looking at a slimmed “core” slice (a projection) of the ACS data. Education, nativity/place of birth, etc. live in other ACS tables that weren’t included in that view.

Want me to pull the full schema and add the education/nativity fields? If so, share:

The dataset or view name/ID (or a link) Year(s) and geo level you want (e.g., 2022 ACS5, tract/county) Which topics to include (education attainment, place of birth/nativity, language, etc.) I can first list all available columns for your dataset, then expand the view.

Can you plan out what is necessary in order for this to be more hands off ?

May 11 · 10:13 AM · Assistant Source JSON

I’ll first inspect the existing assistant/data-intake flow and docs so the plan is grounded in how this repo actually models datasets and runs. I’ll keep this to non-mutating reads since we’re in planning mode.

May 11 · 10:13 AM · Assistant Source JSON

I found the assistant system prompt and tool layer in src/worker.ts. The current instructions already say not to ask generic menus and to inspect datasets when possible, so the likely gap is that the assistant lacks a concrete autonomous “resolve intent → inspect/register → propose/run default” policy for known public datasets like ACS PUMS.

May 11 · 10:13 AM · Assistant Source JSON

The dashboard docs say vague-intent journeys should produce a compact proposed plan before expensive work, while dataset-scoped asking should attach context automatically. That gives us a clear product direction: more autonomous discovery and defaults, with approval only when cost or data acquisition starts.

May 11 · 10:13 AM · Assistant Source JSON
<proposed_plan> # Hands-Off Research Assistant Plan

Summary

Make the dashboard assistant act less like a form and more like an operator: it should infer likely dataset context, inspect available state, choose safe defaults, and present one concrete next action instead of asking the user to supply dataset IDs, vintages, schemas, field names, or operational steps. Expensive work still needs approval, but discovery and lightweight inspection should happen automatically.

Key Changes

  • Update the assistant policy in src/worker.ts so vague dataset requests follow this default flow:
    • infer the likely public dataset/topic from the user’s words;
    • list/inspect existing datasets before asking;
    • if no matching dataset exists, propose a concrete default setup;
    • only ask the user when there are multiple materially different choices or a run/deploy needs approval.
  • Add a small “dataset intent resolver” layer for common public-data families, starting with ACS/PUMS:
    • recognize prompts like “ACS PUMS”, “Census microdata”, “NYC by race”, “education/nativity fields”;
    • map them to default acquisition/profile choices such as latest usable ACS 5-year, NY/NYC-focused geography, person + housing files, common demographic/economic topics;
    • produce a structured suggested action rather than a generic question list.
  • Add or expose a tool path that can retrieve dataset profile/schema/available fields before responding, so the assistant can say “I found these fields / this slice is missing education and nativity” instead of asking the user for a view ID.
  • Change response style for broad asks:
    • replace multi-question menus with a compact “I’ll use these defaults unless you change them” plan;
    • include one primary action such as “Prepare the ACS PUMS NYC profile” or “Draft the run prompt”;
    • ask at most one targeted question when needed.
  • Keep the existing approval gate:
    • lightweight list/inspect/schema checks can run automatically;
    • dataset deployment, public-data acquisition, and full remote analysis still produce an approval-ready plan/prompt before execution.

Example Target Behavior

For “ACS PUMS”, the assistant should respond along these lines:

I’ll check whether ACS PUMS is already available in your workspace. If it isn’t, I’ll prepare a default NYC ACS 5-year setup using person + housing records, with race, income, housing cost, education, nativity, language, commute, and household structure fields. Before starting the deploy/run, I’ll show you the exact plan for approval.

For “Where is education/nativity?”, it should inspect the dataset/profile first, then say:

This current slice does not include the education/nativity columns. I found the available schema and can prepare an expanded ACS PUMS view with those fields added. Defaulting to the same geography and vintage as this session unless you change it.

Tests And Validation

  • Add harness/unit checks that assert the assistant instructions contain the new autonomy rules and ACS/PUMS resolver behavior.
  • Add deterministic assistant journey coverage for:
    • user says only “ACS PUMS”;
    • no matching dataset exists;
    • matching dataset exists but is a slim schema;
    • user asks for a Census Reporter-style analysis by race;
    • user asks a dataset-scoped question from a dataset page.
  • Update docs/product/dashboard.md to document the hands-off assistant contract.
  • Run:
    • pnpm build
    • pnpm test
    • pnpm run qa:dashboard
    • pnpm run cf:deploy:preview if Worker routing/tool behavior changes.
  • After implementation, commit, push, and deploy according to the repository instructions.

Assumptions

  • The assistant should optimize for fewer questions, not zero questions; approval is still required before costly or persistent remote work.
  • ACS/PUMS is the first canonical resolver, but the design should support adding more public-data families later.
  • Default ACS behavior should prefer latest practical 5-year ACS for NYC-style analysis unless the user or existing session context specifies another year/geography.
  • The dashboard URL examples are symptoms; the first implementation should fix the assistant/tool behavior rather than only changing UI copy.</proposed_plan>
May 11 · 10:16 AM · User Source JSON

before you make any prompting changes , show me exactly what you are going to change to what. Also , let's add a function to "Add dataset contents to prompt" for the main agent. This function conditonally adds 1 or multiple briefing files contents to the prompt itself so it has it.

May 11 · 10:16 AM · Assistant Source JSON

I’ll inspect the current prompt construction and dataset briefing/artifact storage paths so I can specify exact before/after prompt text and where the “add dataset contents” function should sit. No edits yet.

May 11 · 10:16 AM · Assistant Source JSON

The control plane already persists briefingMarkdown and profile on dataset_profiles, and normal dataset inspection returns that profile. So the clean plan is a pure prompt-enrichment helper in the worker, not a new storage model.

May 11 · 10:16 AM · Assistant Source JSON
<proposed_plan> # Assistant Prompt Context Plan

Summary

Before changing assistant behavior, first add a prompt-context helper that injects known dataset briefing/profile content into the main assistant prompt when a session has dataset context. This gives the main agent the facts it already has, so it can stop asking the user to restate schema, dataset IDs, coverage, or existing limitations.

Exact Prompt Changes

Current RESEARCH_AGENT_INSTRUCTIONS in src/worker.ts includes:

'If the user input is gibberish, a greeting, or too vague to identify an action, do not call tools. Ask a concise clarifying question instead.',
'Do not inspect datasets or runs just to recover from unclear input.',
'Prefer lightweight dataset queries before launching heavy transforms or analyses when the user wants examples, top records, or simple slices.',
'Do not answer with generic numbered menus when you can inspect the user datasets or runs and propose one concrete next action.',

Planned replacement:

'If the user input is gibberish, a greeting, or too vague to identify a research/data action, do not call tools. Ask one concise clarifying question instead.',
'When a dataset is named, implied, or attached to the current page/session, use the provided dataset context first. Do not ask the user for dataset ids, schema, coverage, or briefing facts that are already present in the prompt.',
'If the request is underspecified but the dataset context supports a likely next step, propose one concrete default action with assumptions instead of asking a multi-question menu.',
'Prefer lightweight dataset queries before launching heavy transforms or analyses when the user wants examples, top records, simple slices, schema checks, or field availability.',
'Do not answer with generic numbered menus when you can inspect the user datasets or runs, use provided dataset context, and propose one concrete next action.',

No ACS/PUMS-specific prompting change will be made in this first step.

Add Dataset Contents Helper

Add a helper near the existing session/prompt helpers in src/worker.ts:

async function datasetContentsForPrompt(env: Env, datasetId: string) {
  // Fetch /datasets/:id/profile.
  // Return an empty string if there is no profile or no useful contents.
  // Include one or more bounded sections:
  // - Dataset briefing markdown
  // - Dataset profile JSON
  // - Schema JSON
  // - Sample rows JSON
  // - Notes
}

The helper will format content like:

Dataset context files:
<dataset_briefing_markdown>
...
</dataset_briefing_markdown>

<dataset_profile_json>
...
</dataset_profile_json>

<dataset_schema_json>
...
</dataset_schema_json>

<dataset_sample_rows_json>
...
</dataset_sample_rows_json>

It will be conditional:

  • Include briefingMarkdown when present.
  • Include profile when present.
  • Include schema and sampleRows when present.
  • Include notes when present.
  • Return nothing when none exist.
  • Apply size caps per section and total prompt budget so a large briefing cannot dominate the whole request.

Wire Into Main Agent Prompt

Current dataset-page prompt construction is:

assistantInput = [
  `Current dataset context: ${datasetName} (${datasetId}).`,
  datasetDescription ? `Dataset summary: ${datasetDescription}` : null,
  'The user started from this dataset page, so treat this dataset as the default context and do not ask them to restate the dataset id.',
  'If the request is broad or ambiguous, clarify scope before inspecting more data or starting an expensive run.',
  '',
  `User request: ${input}`,
].filter(Boolean).join('\n')

Planned replacement:

const datasetPromptContents = await datasetContentsForPrompt(env, datasetId)

assistantInput = [
  `Current dataset context: ${datasetName} (${datasetId}).`,
  datasetDescription ? `Dataset summary: ${datasetDescription}` : null,
  'The user started from this dataset page, so treat this dataset as the default context and do not ask them to restate the dataset id.',
  datasetPromptContents || null,
  'Use the dataset context above before asking the user for schema, coverage, field availability, briefing, or dataset identity details.',
  'If the request is broad or ambiguous, propose a concrete scoped next step with assumptions before asking for more information.',
  '',
  `User request: ${input}`,
].filter(Boolean).join('\n')

Fallback path when dataset fetch fails will stay mostly unchanged, except the ambiguity sentence becomes:

'If the request is broad or ambiguous, propose a concrete scoped next step with assumptions before asking for more information.',

Tests

Add harness validation in scripts/validate-harness.mjs to assert:

  • datasetContentsForPrompt exists.
  • Main assistant prompt includes dataset briefing/profile context.
  • Prompt text says not to ask for schema/coverage/field availability already present in prompt.
  • Existing plan_remote_run approval gate remains present.

Run:

  • pnpm build
  • pnpm test
  • pnpm run qa:dashboard

Assumptions

  • “Briefing files” means the persisted dataset profile fields already available from /datasets/:id/profile: briefingMarkdown, profile, schema, sampleRows, and notes.
  • This first change improves grounding without yet adding ACS/PUMS-specific resolver logic.
  • Prompt-injected dataset contents should be bounded, not full unbounded artifacts.</proposed_plan>
May 11 · 10:19 AM · User Source JSON

PLEASE IMPLEMENT THIS PLAN:

Assistant Prompt Context Plan

Summary

Before changing assistant behavior, first add a prompt-context helper that injects known dataset briefing/profile content into the main assistant prompt when a session has dataset context. This gives the main agent the facts it already has, so it can stop asking the user to restate schema, dataset IDs, coverage, or existing limitations.

Exact Prompt Changes

Current RESEARCH_AGENT_INSTRUCTIONS in src/worker.ts includes:

'If the user input is gibberish, a greeting, or too vague to identify an action, do not call tools. Ask a concise clarifying question instead.',
'Do not inspect datasets or runs just to recover from unclear input.',
'Prefer lightweight dataset queries before launching heavy transforms or analyses when the user wants examples, top records, or simple slices.',
'Do not answer with generic numbered menus when you can inspect the user datasets or runs and propose one concrete next action.',

Planned replacement:

'If the user input is gibberish, a greeting, or too vague to identify a research/data action, do not call tools. Ask one concise clarifying question instead.',
'When a dataset is named, implied, or attached to the current page/session, use the provided dataset context first. Do not ask the user for dataset ids, schema, coverage, or briefing facts that are already present in the prompt.',
'If the request is underspecified but the dataset context supports a likely next step, propose one concrete default action with assumptions instead of asking a multi-question menu.',
'Prefer lightweight dataset queries before launching heavy transforms or analyses when the user wants examples, top records, simple slices, schema checks, or field availability.',
'Do not answer with generic numbered menus when you can inspect the user datasets or runs, use provided dataset context, and propose one concrete next action.',

No ACS/PUMS-specific prompting change will be made in this first step.

Add Dataset Contents Helper

Add a helper near the existing session/prompt helpers in src/worker.ts:

async function datasetContentsForPrompt(env: Env, datasetId: string) {
  // Fetch /datasets/:id/profile.
  // Return an empty string if there is no profile or no useful contents.
  // Include one or more bounded sections:
  // - Dataset briefing markdown
  // - Dataset profile JSON
  // - Schema JSON
  // - Sample rows JSON
  // - Notes
}

The helper will format content like:

Dataset context files:
<dataset_briefing_markdown>
...
</dataset_briefing_markdown>

<dataset_profile_json>
...
</dataset_profile_json>

<dataset_schema_json>
...
</dataset_schema_json>

<dataset_sample_rows_json>
...
</dataset_sample_rows_json>

It will be conditional:

  • Include briefingMarkdown when present.
  • Include profile when present.
  • Include schema and sampleRows when present.
  • Include notes when present.
  • Return nothing when none exist.
  • Apply size caps per section and total prompt budget so a large briefing cannot dominate the whole request.

Wire Into Main Agent Prompt

Current dataset-page prompt construction is:

assistantInput = [
  `Current dataset context: ${datasetName} (${datasetId}).`,
  datasetDescription ? `Dataset summary: ${datasetDescription}` : null,
  'The user started from this dataset page, so treat this dataset as the default context and do not ask them to restate the dataset id.',
  'If the request is broad or ambiguous, clarify scope before inspecting more data or starting an expensive run.',
  '',
  `User request: ${input}`,
].filter(Boolean).join('\n')

Planned replacement:

const datasetPromptContents = await datasetContentsForPrompt(env, datasetId)

assistantInput = [
  `Current dataset context: ${datasetName} (${datasetId}).`,
  datasetDescription ? `Dataset summary: ${datasetDescription}` : null,
  'The user started from this dataset page, so treat this dataset as the default context and do not ask them to restate the dataset id.',
  datasetPromptContents || null,
  'Use the dataset context above before asking the user for schema, coverage, field availability, briefing, or dataset identity details.',
  'If the request is broad or ambiguous, propose a concrete scoped next step with assumptions before asking for more information.',
  '',
  `User request: ${input}`,
].filter(Boolean).join('\n')

Fallback path when dataset fetch fails will stay mostly unchanged, except the ambiguity sentence becomes:

'If the request is broad or ambiguous, propose a concrete scoped next step with assumptions before asking for more information.',

Tests

Add harness validation in scripts/validate-harness.mjs to assert:

  • datasetContentsForPrompt exists.
  • Main assistant prompt includes dataset briefing/profile context.
  • Prompt text says not to ask for schema/coverage/field availability already present in prompt.
  • Existing plan_remote_run approval gate remains present.

Run:

  • pnpm build
  • pnpm test
  • pnpm run qa:dashboard

Assumptions

  • “Briefing files” means the persisted dataset profile fields already available from /datasets/:id/profile: briefingMarkdown, profile, schema, sampleRows, and notes.
  • This first change improves grounding without yet adding ACS/PUMS-specific resolver logic.
  • Prompt-injected dataset contents should be bounded, not full unbounded artifacts.
May 11 · 10:19 AM · Assistant Source JSON

I’ll implement the scoped prompt-context helper and validation checks now. I’ll preserve the existing unrelated dirty files by reading the current diffs first so I only stage my changes deliberately.

May 11 · 10:19 AM · Assistant Source JSON

There’s an existing edit in scripts/validate-harness.mjs that duplicated the worker-source block; I’ll keep that structure intact and add the new assertions to the current file rather than reverting it. Next I’m adding a bounded formatter plus wiring it into dataset-scoped assistant input.

May 11 · 10:20 AM · Assistant Source JSON

The worker helper is in place with per-section and total caps. I’m adding harness assertions now so future changes can’t accidentally remove the dataset context injection.

May 11 · 10:20 AM · Assistant Source JSON

The harness contract now checks for the helper and the exact dataset-context instruction. I’m going to run the requested validation stack; if failures are unrelated or pre-existing, I’ll separate them from this change.

May 11 · 10:20 AM · Assistant Source JSON

pnpm build passes. I’m running the test suite and dashboard QA next; the QA step may take longer because it starts the preview app and drives browser journeys.

May 11 · 10:20 AM · Assistant Source JSON

All requested validation passes so far: build, test, and dashboard QA. Since this touches Worker assistant behavior, I’m running the preview deploy check called out in the repo instructions before committing.

May 11 · 10:20 AM · Assistant Source JSON

The Cloudflare preview deploy dry run passes. The repo instructions also say to commit, push, and run the existing deploy workflow after changes, so I’m checking scripts/status now and will stage only the files changed for this task.

May 11 · 10:21 AM · Assistant Source JSON

Production deploy succeeded, including the dashboard route. I’m committing and pushing the two changed files now as required by the repo instructions.

May 11 · 10:21 AM · Assistant Source JSON

Implemented, committed, pushed, and deployed.

Changed src/worker.ts to add bounded dataset prompt context injection from /datasets/:id/profile, including briefing markdown, profile JSON, schema, sample rows, and notes. Also updated the main assistant instructions exactly along the planned direction: use attached/provided dataset context first, avoid asking for facts already in prompt, and propose one concrete assumed next step for underspecified dataset requests.

Updated scripts/validate-harness.mjs with assertions for the new helper and prompt-context sections.

Validation passed:

  • pnpm build
  • pnpm test
  • pnpm run qa:dashboard
  • pnpm run cf:deploy:preview
  • pnpm run cf:deploy

Deployed Worker version: example-id-0006
Commit: 1ad8082 Inject dataset context into assistant prompts

::git-stage{cwd="/Users/example/Documents/Projects/alpha-research"} ::git-commit{cwd="/Users/example/Documents/Projects/alpha-research"} ::git-push{cwd="/Users/example/Documents/Projects/alpha-research" branch="codex/run-lifecycle-reconciliation"}