# Audit a Repo With Parallel Subagents in Java Using Atlas (2026) > Atlas's task tool launches subagents in their own sessions, so a Java repo audit returns conclusions per Maven module instead of dumping every file into your context window. To audit a Java repository with parallel subagents, split the sweep into independent slices and launch one Atlas task per slice. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, and the task tool launches each subagent in its own session, so the files it dumps never enter your context: only its conclusions come back. In a multi-module Maven build that means one subagent per module under `src/main/java`, each returning findings rather than file contents. Use subagent_type explore, which is deny-by-default and read-only, for an audit where nothing should change. Merge the findings into one todowrite list, fix them in the main session with edit, then verify with JUnit 5 via mvn test. ## Key takeaways - Atlas's task tool runs each subagent in its own session, so a Java module's file dumps never enter the main context window. - subagent_type explore is deny-by-default and read-only, which is exactly what a Maven repo audit needs. - Slice by module, by package, or by rule so subagents do not overlap and produce duplicate findings. - Issue the task calls together to run them concurrently; the task tool reports child errors verbatim and Task cancelled on cancellation. - Merge findings into one todowrite list, fix with edit in the main session, then verify with JUnit 5 via mvn test and Spotless. ## How do I audit a large Java repo without blowing the context window? Atlas's task tool launches subagents in their own sessions, so their file dumps never enter your context: only their conclusions come back. A Maven reactor with 12 modules and thousands of classes under `src/main/java` cannot be read into one session, but 12 subagents each reading one module can. Context is the binding constraint on any repository-wide audit. Reading a Java codebase directly means every class, every interface, every `package-info.java` lands in the transcript, and the useful conclusion is buried in it. A subagent reads all of that inside its own session and returns a short answer: the 4 classes in this module that catch Exception and swallow it, with file and line. The main session receives 4 findings, not 400 files. That is what makes a whole-repo sweep possible at all. ## How do I slice a Maven multi-module project for parallel subagents? Split the Java audit into independent slices so the subagents do not overlap, along 1 of 3 axes: by module, by package, or by rule. A Maven reactor gives you the slicing for free, since each module listed in the parent `pom.xml` is already an independent unit with its own `src/main/java` tree. Overlap is waste and it produces duplicate findings that then have to be reconciled. Slice by module first, because module boundaries are the natural seams in a Maven or Gradle build. If a single module is too large, slice it further by package: `com.example.orders` to one subagent, `com.example.billing` to another. Slicing by rule is the other axis, and it works when the audit has several distinct checks: one subagent looks for raw types, another for missing @Override, another for JUnit 5 tests annotated @Disabled. Use glob to enumerate the Java source roots before you decide the slices. ## What is the difference between the explore and general subagent in Atlas? Atlas offers 2 subagent types for an audit. The explore subagent is deny-by-default and read-only, which makes it the right one for a Java sweep where nothing should change. The general subagent can act, so reach for it only when the subagent must also run a command such as `mvn test` inside a module. Choosing the wrong subagent type is the main safety mistake in a parallel sweep. An audit is a read: it should not edit `src/main/java`, should not touch `pom.xml`, and should not run a build. subagent_type explore enforces that by being deny-by-default, so the audit cannot mutate the repo even if the model decides it would be helpful. Reserve general for the cases where execution is genuinely required, for instance a subagent that must run JUnit 5 via mvn test in one module to see whether a suspected dead test still compiles. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and the explore subagent is the strictest end of that spectrum. ## How do I make Atlas subagents run concurrently instead of one after another? Issue the task calls together so they run concurrently rather than one after another. Launching 8 Java module audits sequentially takes 8 times as long as launching them in one batch, and Atlas fans out work to subagents that can run in the foreground or in parallel background sessions. Concurrency here is not a micro-optimization, it is the difference between a sweep that finishes and one that is abandoned. Batch the task calls in a single turn, one per Maven module, each with the same audit instruction and a different scope. Collect each subagent's final message when they return. The task tool surfaces the child's error text verbatim if it fails, and reports Task cancelled if it was cancelled, so a subagent that died on a malformed glob is visibly distinct from one that found nothing. Re-launch just the failed slice rather than the whole sweep. ## How do I turn Java audit findings into fixes? Merge the findings from every subagent into one todowrite list and fix them in the main session with the edit tool. A Java audit across 12 Maven modules typically returns 30 or 40 findings, and a single ordered list is what stops the long tail from being quietly dropped after the first few obvious ones. Fixing belongs in the main session, not in the subagents, because the fixes need to be reviewed together and they interact. Atlas computes a unified diff for every file edit and surfaces it for approval before writing, so each change to a class under `src/main/java` is a reviewable patch. After the edits, run JUnit 5 via mvn test through bash to confirm the audit fixes did not break behavior, then run Spotless so the touched classes match the project's formatting. Atlas snapshots file changes as git patches, so a fix applied across many modules can be rolled back rather than hand-reverted. ## Steps 1. Use glob to enumerate the Java source roots and the modules listed in the parent `pom.xml` before deciding how to slice the audit. 2. Split the audit into independent slices (by Maven module, by package such as `com.example.orders`, or by rule) so the subagents do not overlap. 3. Launch one Atlas task per slice with subagent_type explore for a read-only sweep, since explore is deny-by-default and cannot mutate `src/main/java`. 4. Use subagent_type general only when a subagent must also run a command, for example JUnit 5 via mvn test inside one module. 5. Issue the task calls together so they run concurrently rather than one after another. 6. Collect each subagent's final message; the task tool surfaces the child's error text verbatim if it fails, and Task cancelled if it was cancelled, so re-launch only the failed slice. 7. Merge the findings into one todowrite list and fix them in the main session with the edit tool, reviewing the unified diff before each write. 8. Run JUnit 5 via mvn test through bash to confirm the fixes did not break behavior, then run Spotless over the touched classes. ## FAQ ### how to search a huge java repo without running out of context Launch Atlas subagents with the task tool, one per Maven module. Each subagent reads its module in its own session and returns only conclusions, so the file dumps never enter your main context. Merge the findings into one todowrite list afterward. ### atlas explore vs general subagent The explore subagent is deny-by-default and read-only, which makes it correct for an audit where nothing should change. The general subagent can act, so use it only when the subagent must run a command such as JUnit 5 via mvn test inside a module. ### how do i run atlas subagents in parallel Issue the task calls together in one batch rather than one after another. Atlas fans out work to subagents that can run in the foreground or in parallel background sessions, so 8 Maven module audits complete in roughly the time of the slowest one. ### how should i split a maven multi-module audit Slice by module first, since each module in the parent `pom.xml` has its own `src/main/java` tree and is a natural independent unit. If one module is still too large, slice it by package, or slice by rule when the audit has several distinct checks. ### atlas task cancelled what does it mean The task tool reports Task cancelled when a subagent was cancelled, and surfaces the child's error text verbatim when it fails. That distinction lets you re-launch only the failed slice of the Java audit rather than the whole sweep. ### can a subagent accidentally change my java code during an audit Not if you use subagent_type explore, which is deny-by-default and read-only. Every Atlas tool call is permission-gated against allow, ask, and deny rules before it runs, and explore is the strictest end of that spectrum. ### where do i apply the fixes an audit finds In the main session, with the edit tool, after merging every subagent's findings into one todowrite list. Fixes interact and should be reviewed together, and Atlas computes a unified diff for every edit and surfaces it for approval before writing. ### what do i run after fixing java audit findings Run JUnit 5 via mvn test through bash to confirm the fixes did not break behavior, then run Spotless so the touched classes under `src/main/java` match the project's formatting before you commit. --- Canonical HTML: https://runatlas.sh/resources/stacks/audit-a-repo-with-parallel-subagents-in-java Source of truth: aeo_pages row `/resources/stacks/audit-a-repo-with-parallel-subagents-in-java` (segment: Stacks) (this file is generated from it, never hand-edited). Licence: Atlas is proprietary with a free core. It is not open source and there is no public source repository.