Agents in a team
Coding with agents · topic coding-with-agents/team
Once several people and several agents work on one repository, individual habits need to become team practice. This topic covers running parallel agent sessions without collisions, using worktrees, wiring agents into CI, enforcing rules with hooks, agreeing review norms, and attributing agent work honestly.
Concepts
- Parallel sessions
- Running more than one agent session at once, on separate tasks, to use waiting time. It multiplies output and also the chances of two sessions editing the same files, losing track of which change belongs where, or exhausting your own attention for review. Parallel work needs isolation per session and a discipline of finishing and reviewing one task before merging the next. glossary
- Worktrees
- Separate checked-out copies of one repository, each on its own branch, sharing one history. A worktree per agent session gives each its own files and build state, so parallel sessions cannot overwrite each other and a bad session can be discarded without touching the others. They are the standard way to isolate concurrent agent work locally. glossary
- CI integration
- Making the continuous integration pipeline the shared gate for agent changes: the same lint, test, build and security checks run on every pull request regardless of who or what wrote it. CI turns individual verification into a team guarantee and gives agents an objective target. Agents can also be given CI results to fix, within the same bounds as any self-checking loop. glossary
- Team hooks
- Scripts that run automatically at fixed points, before a commit, after an agent edits a file, before a command runs, to enforce a rule mechanically: format the code, block a secret, refuse a forbidden path. Hooks enforce what instructions can only request, and they apply to every session and every team member the same way, which is what makes them a team tool. glossary
- Review norms
- The team's agreements on how agent-assisted changes are reviewed: the author reads and understands every line before requesting review, the PR says what the agent did and what was verified, reviewers read the diff rather than the description, and size limits keep changes reviewable. Norms keep the human accountability that agents can quietly erode. glossary
- Attribution
- Recording that an agent contributed to a change, typically as a trailer in the commit message and a note in the pull request, alongside the human who directed and verified the work. Attribution lets reviewers calibrate attention, keeps history honest, and separates what a person certifies from what a tool produced. The human remains the author of record. glossary
Links
- Builds on: Quality with agents
- Leads to: nothing yet
- Competencies drawing on it: Works with agents alongside a team
Lessons
- Saying what the agent did, in the commit and the review (explanation)
- Enforcing the team's rules with hooks and CI (tutorial)
- Running several agent sessions in worktrees (tutorial)
- Writing down how the team uses agents (explanation)
Your reference
Each lesson above adds its takeaways and its example here once you finish it. Your reference lists every lesson you have finished.
Saying what the agent did, in the commit and the review
Unlocks when you finish Saying what the agent did, in the commit and the review.
Takeaways
- Before you ask for review, read every line yourself and split a change that's too large to read. The pull request says what the agent did and what you checked, and the change goes through the same review and CI gates as any other.
- Reviewers read the diff, and the description tells them where to look. Answer for the whole change as its author, including the parts the agent wrote.
- Put the attribution in a trailer in the last paragraph of the commit message, in the form the project asks for, such as
Assisted-byorCo-authored-by. - In a project that uses the Developer Certificate of Origin, a
Signed-off-byline certifies it, and only a person can give that. An agent never signs off, and you sign off only after you have read the change.
Example
Which lines are trailers? · open in the lesson
This is the agent's commit message:
fix: read quoted amounts in the nightly import
The importer split "1,250.00" into two fields. It now reads each rowwith the csv module, so a quoted amount stays one field.Assisted-by: Claude:claude-sonnet-4-6I also tidied up the date parsing while I was in the file.
Signed-off-by: Coding Agent <agent@example.com>Before you run it, write down what the script prints for this message. Then copy the directory and run it to check.
python3 trailers.pyPrints: Signed-off-by: Coding Agent <agent@example.com> (verified in CI from site/examples/coding-with-agents/attribution-and-review-norms/trailers.py)
Enforcing the team's rules with hooks and CI
Unlocks when you finish Enforcing the team's rules with hooks and CI.
Takeaways
- Team hooks run at fixed points, such as before an agent edits a file, and apply to every session in the project. An instruction is advice the agent may skip, and a hook runs every time.
- A Claude Code
PreToolUsehook gets the tool call as JSON and blocks it by exiting with status 2, and the agent reads what it wrote to standard error. Status 1 is an error in the hook, after which the call goes ahead, and a matcher on Edit and Write doesn't see a shell command that writes the file. - CI integration runs the deterministic gates on every pull request, whoever wrote the change. The job and a reviewer decide whether the change can merge, and the agent fixes a failing job from its log within the same limits as any self-checking loop.
- Pin each action in a workflow to a full commit SHA, and give the job only the permissions it needs.
- A rule that must hold every time goes into a hook or a CI check. A review finding that comes back a second time goes into the project instructions, or into a check when a script can find it.
Example
Five edits, as the hook sees them · open in the lesson
The course's script copies the project to a temporary place, adds the hook, and feeds it five tool calls the way Claude Code does. The last two edit files in a Claude Code worktree under .claude/worktrees/. Run it from site/examples/coding-with-agents/ci-and-hooks/ in your clone of the course repository, and compare what you see with the output below.
python3 feed_hook.pyPrints the lines below (verified in CI from site/examples/coding-with-agents/ci-and-hooks/feed_hook.py)
Edit importer.py: exit status 0 Edit test_nights.py: exit status 2 test_nights.py is protected: agents may not change it. If it must change, stop and tell the user why. Write nights/2026-09-15/store-09.csv: exit status 2 nights/2026-09-15/store-09.csv is protected: agents may not change it. If it must change, stop and tell the user why. Edit .claude/worktrees/fix-import/importer.py: exit status 0 Edit .claude/worktrees/fix-import/test_nights.py: exit status 2 test_nights.py is protected: agents may not change it. If it must change, stop and tell the user why.
Running several agent sessions in worktrees
Unlocks when you finish Running several agent sessions in worktrees.
Takeaways
- Parallel sessions use the time you would spend waiting. Give each one a worktree on its own branch, with a task that changes different files from the rest.
- Worktrees of one clone share the history and every ref under
refs/, including the stash. Each worktree has a separate folder of files,HEADand index. A new worktree has no ignored files and no installed dependencies until you set it up. - Keep one line per session: worktree and branch, task, next check-in, and whether it waits on you. Answer a waiting session first.
- Integrate in a fixed order, the change others depend on first. The other sessions rebase and run the check again, because a rebase without a conflict can still leave a stale example.
- Give each session its own copy of what a worktree can hold, and tell every session to leave alone what exists once, such as the stash,
mainand a fixed port.
Example
Two worktrees, and one that git refuses · open in the lesson
The course's script copies shop to a temporary place and makes the copy a git repository with one commit on main. Then it runs the commands above and prints each one after the name of the folder it runs in. The list shows only the folder and the branch of each worktree, because paths and commit hashes differ on every machine. The script runs git quietly, so the two add lines show no output of their own. For the last command the script says in its own words what git does. Run it from site/examples/coding-with-agents/parallel-sessions/ in your clone of the course repository, and compare what you see with the output below.
python3 worktrees.pyPrints the lines below (verified in CI from site/examples/coding-with-agents/parallel-sessions/worktrees.py)
shop$ git worktree add -b api-half-kilo ../shop-api shop$ git worktree add -b docs-usage ../shop-docs shop$ git worktree list shop main shop-api api-half-kilo shop-docs docs-usage shop$ git worktree add ../shop-extra main git refuses: main is checked out in shop
Writing down how the team uses agents
Unlocks when you finish Writing down how the team uses agents.
Takeaways
- Write the team's practice for agent use in the project instructions file, where every person and every agent session reads it. It says what agents may do and what every change passes, how agent work is attributed and reviewed, and which directories and commands are off limits.
- Make the gate and the attribution form decisions at the start. Write every other rule from an incident the team has seen, and name the incident next to the rule.
- Add a rule when a mistake comes back. Read the file again from time to time, and remove a rule when its reason is gone or no incident or day-one decision is behind it.
- The file states each agreement and its reason. An agreement that must hold every time also gets a hook or a CI check, and one that needs a person's judgment stays with the review.
Example
The invoice project's history · open in the lesson
The course's script builds the project's git history with fixed dates and prints each commit, oldest first, with its message body indented under it. Run it from site/examples/coding-with-agents/team-practice/ in your clone of the course repository, and compare what you see with the output below.
python3 history.pyPrints the lines below (verified in CI from site/examples/coding-with-agents/team-practice/history.py)
2026-05-04 chore: the invoice service
2026-05-11 feat: export invoices as CSV
Assisted-by: Claude:claude-sonnet-4-6
2026-05-12 Revert "feat: export invoices as CSV"
The agent ran the lock command while it added the export,
and requirements.lock upgraded both dependencies. The review
read invoices.py and skipped the lockfile, and the release
failed its smoke test.
2026-05-13 feat: export invoices as CSV, lockfile unchanged
Assisted-by: Claude:claude-sonnet-4-6
2026-05-18 feat: a due date on each invoice
2026-05-27 feat: discount for early payment
Assisted-by: Claude:claude-sonnet-4-6
2026-06-02 fix: cap the early-payment discount at five days again
Two agent sessions ran in two worktrees of one clone. The
invoice session stashed its cap on the discount, and the
report session popped that stash into its own worktree and
discarded it with its other changes. The discount shipped
without the cap.
2026-06-08 docs: list the invoice rules
2026-06-16 feat: late fee on overdue invoices
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Coding Agent <agent@example.com>
2026-06-17 Revert "feat: late fee on overdue invoices"
The commit ends with a sign-off in the agent's name. Our
sign-off certifies the Developer Certificate of Origin, and
only a person can give that.
2026-06-18 feat: late fee on overdue invoices
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Robin <robin@example.com>Sources
DLAI-5Claude Code: A Highly Agentic Coding Assistant, DeepLearning.AI (course)Academy claude-code-in-actionClaude Code in action, Claude Academy (course)Academy ai-native-sdlc-playbookThe AI-native SDLC playbook, Claude Academy (course)Claude Code hooksHooks reference, Claude Code documentation (reference)GitHub docs workflow-syntaxWorkflow syntax for GitHub Actions, GitHub documentation (reference)