Agent-specific build profiles

Agent-specific build profiles are lightweight build configurations optimized for the agent iteration use case rather than the human pre-merge or release use case. A standard CI build might run: linting, static analysis, unit tests, integration tests, documentation generation, test coverage analysis, artifact signing, and deployment packaging. An agent iteration build needs only: compilation succeeds, relevant unit tests pass. The rest is noise for iteration purposes and adds 8-15 minutes to a loop that should take 90 seconds.

The core insight is that different consumers of the build system have fundamentally different requirements. A release build needs everything: full test coverage, signed artifacts, generated documentation, security scanning, license compliance checks. A human pre-merge check needs most things: unit tests, integration tests, lint, static analysis. An agent iteration build needs the minimum signal to determine if the agent's last change was correct: does it compile, and do the tests that directly test the changed code pass?

Build profiles encode these different requirement sets as named configurations. In Bazel, this is a combination of .bazelrc configs and target selection. In Gradle, it's task profiles. In CI, it's separate workflow files or job conditionals that trigger different step sets based on the branch source. The key is that profiles are first-class build system concepts, not ad-hoc hacks - they're versioned, tested, and maintained with the same rigor as the main build configuration.

One assumption behind these profiles changed in August 2026: the profile can no longer assume a single checkout. Worktree isolation per agent stopped being something platform teams assembled by hand and became a vendor default - Meta's Muse Code, announced on 5 August, spawns its subagents in isolated git worktrees as standard behaviour. That is the right design for concurrency, and it moves the problem into the build system. Five agents in five worktrees is five source trees on one machine, each invoking your build, each with its own output directory unless you tell it otherwise. A profile tuned for one checkout will either duplicate every artifact five times or have five processes contend for one cache. Agent build profiles now need to be worktree-aware: a shared, content-addressed cache that all worktrees read from and write to, and output paths keyed per worktree so parallel builds do not corrupt each other. Multi-root workspace support in the editor is the same story one layer up.

The performance difference between a full build and an agent-optimized build profile can be dramatic. Teams moving from a 15-minute full CI pipeline to a 90-second agent profile see agents that can iterate 10x faster on the same infrastructure. This isn't magic - it's recognizing that the full pipeline runs steps that aren't useful for agent iteration, and explicitly not running them during iteration.

• Agent iteration is fundamentally different from pre-merge validation - agents need fast confirmation of local correctness; full pre-merge validation is appropriate only when the agent believes a change is complete and ready
• 10-15 minute CI pipelines are acceptable for human pre-merge; they're catastrophic for agent iteration - with a full pipeline, agents can iterate 4-5 times per hour; with an agent profile, they can iterate 30-40 times per hour
• Skipping irrelevant steps improves signal quality - an agent profile that runs only affected tests has a clearer signal: pass means "the code I changed is correct," not "the code I changed plus 500 tests unrelated to my change are all passing"
• CI cost scales with build count - agent iteration generates many more builds than human development; an agent profile that costs 10% of a full build makes agent CI 10x more cost-effective per iteration
• Different profiles make quality standards explicit - defining what must pass for "agent iteration" vs. "human pre-merge" vs. "release" makes quality requirements concrete and machine-checkable

1. Audit your current CI pipeline - List every step and categorize it: (a) required for release, (b) required for pre-merge human review, (c) required for agent iteration correctness, (d) optional/informational. Steps in category (c) and not (a) or (b) are candidates for exclusion from the agent profile.
2. Define the agent iteration profile contents - Typically: compilation for changed targets and their dependents, unit tests for changed targets, lint for changed files only (not full lint). Explicitly exclude: integration tests, documentation generation, coverage reports, security scans, end-to-end tests.
3. Create a .bazelrc config for agent builds - Add a build:agent config in .bazelrc that sets --test_tag_filters=-integration,-e2e,-slow and uses --build_tests_only. Agents invoke Bazel with --config=agent to get the optimized profile. In CI, route agent-branch builds to a workflow that passes this flag.
4. Create a separate CI workflow file for agent iterations - In GitHub Actions, create .github/workflows/agent-iteration.yml that triggers on agent/** branches. This workflow runs only compilation and unit tests, completes in under 2 minutes, and reports results immediately. The agent/** branch naming convention routes builds automatically.
5. Run the full pipeline on agent PRs before merge - The agent iteration profile is for iteration, not for pre-merge validation. Before an agent-generated PR is eligible for merge, it must pass the full CI pipeline. Automate this: when a PR moves from agent/ draft to ready for review, trigger the full pipeline.
6. Make the profile worktree-aware - Assume several agents are building several worktrees of the same repository on the same machine at the same time, because vendor harnesses now spawn subagents that way by default. Point every worktree at one shared content-addressed cache so the second agent gets the first agent's artifacts, key output directories per worktree so concurrent builds cannot overwrite each other, and check that your build tool's lock behaviour degrades into queueing rather than failing. Verify by running the profile in four worktrees simultaneously and confirming the cache hit rate rises rather than the wall-clock time.
7. Measure the profile's signal accuracy - Track how often a change that passes the agent iteration profile fails the full pipeline. If the failure rate is over 10%, the agent profile is too permissive and missing important checks. If it's under 2%, the profile is well-calibrated. Adjust which tests are included in the profile based on this failure rate.

Making the agent profile so permissive that it doesn't catch real bugs. An agent profile that never fails doesn't help the agent know when it's made a mistake. Include at minimum the unit tests for the modules the agent is changing. A profile that always passes provides no signal.

Not automating profile selection. If agents need to manually specify --config=agent or remember to use the right CI workflow, they often won't. Automate profile selection: detect the branch name pattern (agent/*) in CI configuration and route to the agent profile automatically. Agents should never need to think about which build profile to use.

Letting the agent profile diverge from the full pipeline. If the agent profile runs different compilation flags, different test runners, or different code generation steps than the full pipeline, builds that pass the agent profile may fail the full pipeline for reasons unrelated to the agent's changes. Keep the agent profile as a strict subset of the full pipeline, not a different build.

Not versioning the agent build profile. Build profiles should be versioned in the repository alongside the code they build. If the agent profile is maintained separately from the main CI configuration, they'll drift apart and produce incorrect results. A single .bazelrc file or a single CI workflow file that both the agent profile and the full pipeline inherit from is the right structure.

A build profile that assumes one checkout per machine. Harnesses now isolate each subagent in its own git worktree by default, so the realistic local picture is several source trees building concurrently. A profile with a fixed output directory turns that into artifacts overwriting each other; a profile with no shared cache turns it into the same compilation performed N times. Neither shows up when you test the profile on your own single checkout, which is why the four-worktree test belongs in the profile's own validation.

Ignoring the CI cost of running the full pipeline on all agent PRs. If every agent draft PR runs the full CI pipeline, the cost savings from the agent iteration profile are eroded. Use CI triggers carefully: run the agent profile for every push to an agent branch, run the full pipeline only when the PR is marked ready for review or when a merge is requested.