Parallel work and subagents

Today's topics

• Parallel tasks and task dependencies.
• Separate agent sessions and subagents.
• Context, cost, and verification.
• Git for managing changes to your project.

Independent tasks and dependencies

• Parallel work means several agents work on separate tasks at the same time.
• A dependency means one task cannot start until another task has finished.
• Some steps of policy analysis can be split across several agents. Other steps must wait for an earlier step to finish.
• Ask this question of each step. Can several agents define the problem at the same time? Can they collect data at the same time? Can they run the analysis at the same time?
• The exercise asks you to answer this question for each step of your own project.

Two reasons to run several agents

• Speed is one reason to run several agents. You split a task into five independent pieces and give each piece to its own agent. A five-minute wait then becomes about one minute.
• Some pieces need output from another piece. Such a piece has to wait. The speedup is then gone.
• Checking is the second reason. Two agents do the same job, and neither can see the other's work. Comparing their results tells you something one run cannot.
• Research already works this way. Two coders code the same sample. Someone else runs a replication.

Running separate agent sessions

• Open separate conversations and give each a specific task. You coordinate the work and combine the results.
• Provide each session with the question, relevant files, and requirements it needs.
• When agents write files, assign separate output files. Reading the same source is usually straightforward; editing the same file requires coordination.

Session messaging

• In both Claude Code and Codex, one open session can send a message to another session.
• Claude Code can list the sessions you can reach and send a message to one of them. This needs no setup. It also works with sessions on other machines. The /help command in Claude Code lists the messaging command.
• In Codex, a session can queue a message to another local or remote session.
• Use messages to coordinate your open sessions. For example, the session that collects the records tells the drafting session that the records are ready.
• Messages are for coordination in the moment. The lasting record of your work stays in your repository. A collaborator can read it there later.

Live demonstration: Two tasks at once

• Use one prepared dataset. Ask one session for a descriptive table and another for a chart.
• Give both the same population, time period, and treatment of missing values.
• Compare the outputs. Check that the table and chart describe the same sample.

How the main agent delegates

• A subagent handles a task assigned by the main agent and returns a result.
• The main agent can divide work, coordinate the tasks, and combine the reports.
• State the task, inputs, constraints, and expected output clearly when asking for delegation.

Separate sessions vs. subagents

Delegation and parallelization

• Delegation assigns responsibility for a task. Parallelization runs tasks at the same time.
• Subagents can work in parallel on independent tasks or in sequence when one needs another's result.
• For example, agents can examine separate documents simultaneously. A synthesis begins after their reports are available.

What a subagent sees

• Context is the information available to the model for its current response. It includes instructions, messages, and material read during the task.
• Each subagent works in its own context. The background it receives depends on the tool and how it is launched.
• Give it the question, files, and decisions its task requires. Check the delegation message if its result suggests that it missed important background.

Keeping the main conversation focused

• A subagent can inspect many documents or long logs within its own context and return a concise report.
• This reduces the intermediate material in the main conversation. The report should retain evidence references so you can inspect the supporting details.
• Separate context does not imply separate files. Agents may still have access to the same project folder.

Time and token costs

• Tokens measure the text processed and generated by the models. Subagents use tokens too.
• Parallel work can reduce waiting time. Repeated background, duplicated work, and combining results can increase total usage.
• Use a small number of well-defined tasks. Check usage and whether the extra agents improved the result.

Plan with the advanced model, execute with the cheap one

• The advanced model plans better. It also costs more.
• The cheap model is fast. It costs almost nothing.
• Planning needs the better model. Execution is mechanical. Spend the expensive tokens on planning.
• You set your own session's model with /model. This works in both tools.

One prompt does it:

Independent checks

• Give two agents the same question and source material. Ask each to work without seeing the other's answer.
• Compare their results, then investigate disagreements in the source or calculation.
• Agreement is useful evidence of consistency. Both agents can still make the same mistake, especially with the same model and instructions.
• Check a result against the data, source text, or a calculation you can inspect.

Example: Check a reported number

• Ask one agent to calculate a statistic from the data. Ask another to calculate it separately from the same definition.
• Compare the values and the sample, denominator, filters, and missing-value rules.
• If the numbers differ, identify the reason before choosing an answer. If they agree, inspect the calculation and a small set of source records.

What Git does

• Git runs on your own computer and records versions of your project. It works with no internet connection.
• A commit saves a snapshot of the project along with a short message saying what changed.
• A diff shows the difference between two versions. Before you commit, read the diff and check that the code ran. Every saved version should be one that worked.

Who commits

• Anyone working in the project folder can commit, and that includes the agent. Ask the agent to run the Git commands and to explain the changes it made.
• When several agents work at the same time, they can overwrite each other's edits. Give each agent different files. Review and commit one agent's change before you start the next one.
• Always start a new agent task from a committed working version.

Leaving files out

• A commit does not have to record every file. List the files Git should never record in a file called .gitignore.
• Put data with restricted content there, along with API keys, passwords, and large outputs. Inspect the file list before you commit.

Going back

• If the agent breaks something, ask it to revert to the last working commit.
• Revert undoes a commit by adding a new commit, so the history is kept.

GitHub

• GitHub is a website that stores a copy of your repository. You need it to back up the project, to show the project to someone, or to work with other people.
• Push sends your local commits to GitHub. Pull brings down commits made elsewhere. For a solo project on one laptop, pull rarely comes up.
• On GitHub the owner controls who can push. In a private repository only the owner and invited people can see the project or change it.
• In a public repository everyone can read the project, and only invited people can push. Other people propose changes through a pull request, and the owner reviews it. For this course you do not need a pull request.

What to do for your project

1. Create a GitHub repository for your individual project. Private is fine, and student accounts are free.
2. Push your local project to it.
3. Keep working in the repository. Commit every later change to your questions, code, or document with a message, and push. The final submission is the repository, and its commit history should show how the project developed.

Your memo

• We discuss your memos on problem definition, and any questions that came up while writing them.

Bardach on evidence, and what changes with an agent

The same questions for your project

• What do you already suspect the answer is, and where could each point be checked?
• Which of that evidence exists already, and which would you have to collect yourself?
• Which item would change your conclusion if it came out differently from your guess?
• Which items are documents, and which require talking to a person?
• Who argues the other side of your question, and what would they cite?

Which of it could an agent do?

• Which items could an agent collect on its own?
• Which of those could run at the same time?
• Which one must wait for another result?
• Which cannot be delegated?

Reading

• Bardach and Patashnik, A Practical Guide for Policy Analysis, Step Two, "Assemble Some Evidence" (pages 12–18), and Part II, "Assembling Evidence" (pages 83–93).

Checkpoint 1: question and data · 5% · individual · due Oct 1 before class. Push your project to your GitHub repository. Its README should state the policy question, audience, proposed data source, and intended product. Keep the repository private and invite me as a collaborator. My GitHub username is philohistoria. Post the repository link on Canvas. Students get free GitHub benefits through GitHub Education.

Weekly memo · due Oct 1 before class. Which parts of your project could be split across several agents working at the same time? Which parts could not? The eightfold path can be a useful way to think this through. You do not have to use it. Try one split in a simple experiment and describe what happened. Attempts that failed are welcome too. Aim for 150–200 words total. Describe what you actually tried and observed in your own words. Do not use AI to write the memo. Begin in class and submit to Canvas Discussions. See assignments and grading.