Workshop and independent practice

AI agents for research workflows

You’ve inherited a research folder. It contains files from a colleague’s project, but the names do not tell you much and you are not yet sure how everything fits together.

Use a desktop agent to find out what’s there, make sense of it and develop a workflow another person can check and run again. The steps below give you a starting point; let what you discover guide the conversation.

Download the practice ZIP

Start here

Your first task is to understand the folder before changing anything. Download it, open it as a local project and ask the agent to help you investigate.

Some files are large. Ask the agent to inspect samples and use code where needed rather than paste entire files into a conversation. File access does not mean every file fits in a model’s context.

  1. Download the ZIP. On Windows, right-click and choose Extract All; on a Mac, double-click it. Open the extracted ai-agents-for-research-workflows folder.
  2. Open STARTHERE.html in your browser and keep it beside your desktop agent.
  3. Download the ZIP to your computer, extract it, and open the extracted folder in Codex. Use the separate Codex setup instructions if you need help getting started.
  4. Start by asking the agent what’s in this folder.

Add the extracted folder as a project

The screenshots below come from the earlier ChatGPT Work practice guide shared with Ella. They show that interface at the time; the standalone Codex app and newer versions may use different controls. The key step is to select the extracted local folder.

  1. In the interface shown, switch to Work, click Choose project, then New project.
  2. Give the project a name, such as Research workflow practice.
  3. Under Source folders, click Add folders ChatGPT can read and edit. Select the extracted ai-agents-for-research-workflows folder containing AGENTS.md and sample-research-folder.
  4. Click Create project. In Codex, use its local project/folder selector to open the same extracted folder. Check the selected path before starting.

Click either screenshot to enlarge it.

1. Choose project → New project.
2. Name the project and add the extracted folder.
What’s in this folder?

Work directly in the practice folder and feel free to change the files as you experiment. Everything here is mock data. You can always restore the starting folder by extracting a fresh copy from the ZIP. Record your changes so you can understand and repeat what you did.

1. Inspect the research folder · 15 minutes

What’s in this folder, and how do the files fit together?

Ask for a read-only inventory: file size, type, row count, columns, likely role and supporting evidence. The names are deliberately mixed. Look for handover notes and evidence within the files. Ask which files can be stacked and which must be joined. Leave the reveal folder until you want to check your interpretation.

If you get stuck

Ask the agent to inspect headers and a few rows, then count the full files with code. It should not read millions of rows into the chat. Try: “Which identifiers and column combinations identify one record?”

Check your result

Participant information spans demographic batches and enrolment batches. Tests have multiple rows per person: one row per participant, test, session and trial. Four tests use different units. There is a byte-identical demographic export. Stacking that export twice invents extra participants; joining raw test rows only by participant ID can multiply rows.

2. Rename and organise after agreeing a plan · 10 minutes

Suggest useful names and an organisation for these files. Show me the plan first.

Ask for current name, proposed name, role, evidence and any uncertainty. Names should distinguish demographic/enrolment batches, test type and session. Decide how to handle duplicates and dated notes, and record what you change. Leave genuinely uncertain cases for discussion.

When the plan is clear, authorise that specific plan. Ask for a record of old and new paths and file hashes. Work directly in the practice folder; a separate working copy is not required.

Check your result

The record should explain where each file went and what changed. Renaming alone should leave its contents and byte hash the same; edits should have a recorded reason and new hash. Record how you handled the exact duplicate. Subsequent code must use the new filenames or discover table roles from headers and content.

3. Build a checked merge · 30 minutes

Help me merge the participant information and test results. Explain the table relationships and checks before writing code.

Agree a plan: concatenate the distinct demographic batches; concatenate enrolment batches; verify unique participant IDs; join these tables one-to-one. Keep repeated test observations as a separate long table, or aggregate trials within each test and session before joining the participant master. Never average scores from different tests together.

Write a repeatable Python script for that plan. Record every transformation and flag duplicates, missing values and unmatched IDs.

Review the proposed script, its inputs and output paths before running it. Use the available environment; ask before installations or new permissions. Decide whether you run the command yourself or explicitly authorise the agent to run it. Keep scripts and requested outputs inside the sample folder with clear names.

Read the project notes before choosing which records to analyse. Keep people with incomplete information visible in the merged master. Make any eligibility and paired-value decisions explicit. Blank values are not zero; an absent session is not a failed score.

If you get stuck

Start with demographics and enrolment only. Ask for their row counts, distinct ID counts and unmatched keys. Then add one test, one session at a time. Ask the agent to show a hand-checkable trace for one participant.

Check your result

The master must have 100,000 unique participant IDs, not millions of rows from a many-to-many join. There should be one verified duplicate demographic file, duplicate test observations and an orphan test ID to flag. Keep an issue report. Check a participant’s demographic/enrolment details and all trials directly against the source rows. Test values and units must remain distinct.

4. Reproduce the result and record decisions · 20 minutes

Record how this dataset was made, and show how another person can reproduce it.

Keep the input file list and hashes, rename mapping, script, command, environment requirements, join keys, duplicate policy, missing-value rules, eligibility decisions, row counts and output hashes. Record unresolved issues and your manual checks. Save this beside the merged results.

Run the pipeline again and compare output contents and hashes. It should reproduce the same dataset when inputs and decisions are unchanged. Compare input hashes with the previous run and explain any differences. A clean rerun should rebuild the requested outputs, with any further changes recorded.

Check your result

The record should let someone locate the original inputs, understand each transformation and rerun the command. File generation dates or a fluent summary alone do not establish reproducibility. Keep timing metadata separate if it changes between runs.

Describe the assistance accurately

Write a short statement of what the agent wrote or ran, which choices you approved and what you checked. Distinguish the person running an agent-written pipeline from the agent executing it. Discuss any required disclosure with your supervisor or team; this exercise does not create an institutional policy.

Reveal: check your understanding

Where to find the dataset description

After investigating, open sample-research-folder/reveal/dataset-description.md in the extracted folder. The data dictionary is beside it. Compare them with your inventory before continuing or revising your merge plan.

5. Document these steps · after the session

Document the steps we took and set up a repeatable workflow that keeps track of every change. Include a run guide, an append-only change log and checks that another person can use to reproduce and verify the results. Show me the plan before creating anything.

Ask for a short run guide covering the inputs, dependencies, commands, outputs and checks. Link each step to the script or command that performs it. Record decisions and unresolved issues so another person can understand why the workflow behaves as it does.

Keep an append-only change log: for each rename, edit or transformation, record the time, purpose, old and new paths where relevant, input and output hashes, the command or script used, and its check results. Record failed attempts and corrections too. Do not overwrite earlier log entries. A list of prompts alone is not a record of what actually changed.

Build logging into the repeatable script so each run records its inputs, outputs, environment and validation results. Keep changing timestamps in the log, separate from the reproducible data outputs. Ask the agent to update the record whenever it makes a manual change; check the file hashes to catch changes the log missed.

Check your result

Start a new conversation and ask the agent to use the run guide. Review and authorise a clean rerun, then compare the output hashes and the recorded input hashes. Check that the new log entry records that run without removing the previous history, and that the change record explains what happened to each starting file.

Extend the exercise

Compare descriptive changes by condition or site after defining eligible paired records. Explain denominators and limitations. Build a local dashboard from checked summaries rather than embedding the full dataset. Document every analysis choice. Invented task data support no efficacy, clinical or population claim.

If something goes wrong

If the agent cannot see files, check extraction and folder access. If a merge grows unexpectedly, check uniqueness and table grain before continuing. If it requests installation or wider access, discuss the request. Restart from a fresh ZIP if needed.

Optional: last week’s conference exercise

If you would rather work with documents and event information, try the fictional Professional Practice Conference folder from last week’s workshop. All event details, people and organisations in that pack are synthetic.

Download the conference folder

Extract it into a separate folder and open that folder as its own local project. Start by asking the agent what is there and what the files tell you. Choose a task together, check its work against the sources, and use “Document these steps” above to keep a repeatable record. The pack also includes the editable example conference website.

Inspect this conference folder without changing it. What can you work out from the files, which sources agree or disagree, and what useful tasks could we do? Show your evidence and let me choose a task.