Specialized agents and collaboration
More agents do not automatically mean a better outcome. Quality arises from independent assignments, writing boundaries, comparable evidence, and a synthesis that resolves contradictions.
What you will tackle, step by step
Decompose by result, not by label
Adding agents does not automatically make work smarter. Often it just makes it harder to follow. The right question is not "how many agents can I use?”, but "which autonomous result can I entrust without creating overlaps?”. This is where a good delegation starts.
A named subagent normally starts with an isolated context: it does not automatically see the entire conversation nor all the files already read by the coordinator. An explicit fork can inherit more context, but it doesn't replace a clear assignment. For this reason it must receive an autonomous result, such as a file map or a security review, not "deal with the backend".
Each assignment states sources, outputs, limitations, and evidence. If the coordinator cannot verify the output without repeating all the work, the contract is too weak.
Task Notes imports the same task twice. You want to use multiple agents, but the bug isn't localized yet and you don't want everyone editing the repository.
- Give an Explorer a read-only mission: reproduce the defect, follow the data, and deliver related files, symbols, and tests.
- After the map, give the Implementer only one result: fix the cause in the identified file, without cleaning up other code.
- Ask the Tester to add the duplicate case to the suite, working in the agreed test file and starting from the patch contract.
- Have a Reviewer who changes nothing read the diff and results and must cite each finding with file, line and impact.
Result: You have four different contributions, but only one verifiable story: reproduction, cause, patch, and test. Each step has an output and no one receives a generic "do what it takes".
Dependencies and real parallelism
Parallelizing is only useful when two jobs can actually advance without expectation. Opening multiple agents and then leaving them stuck on the same prerequisite is parallelism on paper. Draw the dependencies first; then decide what can go together.
Two independent searches can start together. Tests that depend on a new API must wait at least for the implementation contract. Drawing the dependency graph avoids fake parallelism and hidden waits.
Parallelism has a cost: startup, duplicate context, synthesis and possible conflicts. If two branches really need to write in parallel, separate worktrees can isolate their files; however, they remain to be integrated and verified. For a small task, a single agent with a clear plan is often faster.
- Break down the result into verifiable artifacts, not generic titles.
- Draw dependencies and separate truly independent jobs.
- Assign only one write owner for each file.
- Start only branches without dependencies or conflicts in parallel.
- Bring together evidence and disagreements in a controlled synthesis.
You need to add a priority to the tasks of Task Notes. A choice of data format, a modification to the parser, tests and an interface verification are needed.
- Start the map of the saved format and the search for the points where the priority is shown together: they are two independent readings.
- Block the implementation until the format is decided, because parser and migration must share the same contract.
- Start parser tests after the contract but in parallel with the view change, assigning separate files.
- Merge branches into an end-to-end check only when data, parser, and interface have produced compatible artifacts.
Result: Time is shortened where real independence exists. At the connection points you don't guess: wait for the artifact that defines the contract and then check the integration.
File ownership and conflicts
The worst conflict is not the one that Git marks in red. It's the one that goes unnoticed because two agents rewrite the same file with different ideas and the resulting version still appears valid. Ownership makes it clear who can write, who proposes, and who reviews.
If two agents edit the same file, the latter result may delete or reinterpret the former. Assign write ownership, serialize changes or have one of the two produce just a proposal.
Reading can be shared more easily than writing. A reviewer analyzes the diff without modifying it; the implementer retains responsibility for the patch until the findings are accepted.
The Implementer is correcting `importer.py`; the Reviewer notices that the uploaded file name is not normalized. Both would like to intervene immediately.
- Keep `importer.py` under Implementer ownership until the current patch closes.
- Ask the Reviewer for a read-only finding with dangerous input, function involved, impact and expected behavior.
- Have the Implementer integrate the finding into a second distinguishable diff, adding the proposed test.
- Return the full diff to the Reviewer to check that the risk is covered without introducing regressions.
Result: The security alert is not ignored, but neither is it transformed into a concurrent change. The author, intention and evidence for each step remain legible.
Evidence-based synthesis
A summary is not a collage of reports. The coordinator must do the most delicate work: understanding where the evidence agrees, where the conclusions diverge, and which claim can really be supported. Four confident agents can share the same wrong assumption.
The coordinator does not simply chain relationships. Compare cited files, tests, assumptions and limitations; reports disagreements and decides which evidence is most relevant.
A good final handoff separates what is implemented, what is verified, and what remains open. Subagents report to the coordinator; in an experimental team agent, however, teammates can also communicate with each other and share tasks. They are different coordination models, and in both the certainty of the tone is worth less than the evidence.
The Explorer attributes the double import to the parser; the Reviewer thinks the problem is in the save. Both cite real code, but neither has conclusive evidence.
- Table the two hypotheses with files cited, input used, and expected observation if each were true.
- Search for the first point in the stream where the duplicate is observable: parser output or store content.
- Run a test aimed at that boundary, without changing the code to favor one of the hypotheses.
- Updates the summary with the outcome, discards the disproven hypothesis and preserves the limit of checks not yet carried out.
Result: Divergence becomes an experiment, not a vote. The final conclusion arises from the observed boundary and remains proportionate to the available evidence.
Team for Task Notes
New import requires understanding, patching, edge cases and final checking.
Explorer → maps parser, store, and tests (read-only)
Implementer → owns parser.py
Tester → owns test_parser.py after the contract
Reviewer → reads the diff and cites findings
Coordinator → compares tests, diff, and risks; never invents consent