D5 · Scaling Across Teams and Systems

This domain is worth 16% of the mock — roughly 8 of 50 items. It is the “Scale Codex Across Governed Teams and Systems” course made concrete: coordinate parallel workstreams and integrate their outputs safely, standardise configuration across many repositories, wire Codex into the tools your teams already use, measure whether scaling is actually helping, and recognise the failure modes that only appear at scale. The exam rewards safe integration and standardisation over raw parallelism.

What you need to know

Running one agent well (D2) is different from running many across an organisation. At scale you coordinate parallel workstreams and integrate their outputs safely — independent branches, verified changes, controlled merges — rather than letting agents collide. You standardise AGENTS.md across repositories so behaviour is predictable everywhere. You embed Codex in delivery through the Codex SDK, App Server, the GitHub Action and integrations with GitHub, GitLab (beta), Slack and Linear. And you measure both adoption and quality, because more agent activity is not automatically more value. The characteristic failure modes — merge conflicts between parallel agents, config drift, unreviewed changes at volume, and mistaking activity for outcomes — are all testable.

Learning objectives

By the end of this page you should be able to:

1. Coordinate parallel workstreams and integrate their outputs safely.
2. Standardise AGENTS.md and configuration across many repositories.
3. Integrate Codex into delivery via the Codex SDK, App Server, GitHub Action, and GitHub/GitLab/Slack/Linear.
4. Measure adoption and quality, not just activity.
5. Recognise and mitigate the failure modes of scaling an agent across many repositories.

5.1 Parallel workstreams and safe integration

Scale means several Codex tasks running at once — across branches, repos or teams. The value is throughput; the risk is unsafe integration.

        ┌── workstream A (branch) ──┐
task ──►┤── workstream B (branch) ──┤──► VERIFY each ──► CONTROLLED MERGE ──► main
        └── workstream C (branch) ──┘     (tests, diff)   (review + CI gate)
              parallel, isolated

5.2 Standardising AGENTS.md across repositories

One good AGENTS.md (D2) makes one repo predictable. At scale, consistency across repos is the lever: an engineer or an agent moving between repositories should meet the same conventions, build/test commands and no-go areas.

Standardisation is what turns “Codex works on my repo” into “Codex works the same on all our repos”, and it is what makes parallel workstreams safe to integrate — because each was produced under the same rules.

5.3 Programmatic and delivery integration

Codex plugs into how software is actually delivered.

5.4 Measuring adoption and quality

At scale, “more Codex activity” is not the goal — better, faster, safe delivery is. Measure both sides.

ACTIVITY  ≠  VALUE
│              │
tasks run   review pass rate, defects avoided,
per week    security findings resolved, cycle time

Measure BOTH; a rise in activity with falling quality is a warning, not a win.

5.5 Failure modes of scaling an agent

Some problems only appear once many agents run across many repos. Know the pattern and the mitigation.

Decision framework

Use SCALE SAFELY (SISM): Standardise, Isolate, Safe-merge, Measure.

Common mistakes

Scenario challenge

Scenario. A platform group of 40 engineers across 25 repositories has adopted Codex. Leadership is delighted: tasks-run-per-week has tripled. But three problems have surfaced: two parallel Codex tasks on the same feature branch overwrote each other last week; the 25 repos have drifted so Codex uses different build commands and conventions in each; and the revert rate on merged PRs has quietly climbed while nobody was watching quality. A manager proposes: “keep scaling — the activity numbers prove it is working — and we will fix issues as they come up”.

Expert reasoning trace.

1. The headline metric is misleading. Tripled tasks-per-week is activity, not value. The rising revert rate is the quality signal that matters, and it is moving the wrong way — so “the numbers prove it is working” is exactly the activity-vs-outcomes trap.
2. The collision is an isolation failure. Two agents on one branch overwrote each other because the work was not isolated. The fix is one workstream per branch/worktree, integrated through a controlled merge, using cloud or Ultra for genuine parallelism.
3. The drift is a standardisation failure. 25 repos with different build commands and conventions make Codex behave inconsistently and make parallel outputs unsafe to integrate. Standardise a shared AGENTS.md template and managed configuration, with periodic drift checks.
4. The revert rate is an unreviewed-volume / quality failure. Climbing reverts while “nobody was watching” means the review gate and quality measurement both lapsed under volume. Reinstate the review gate (auto-review as evidence, not replacement) and measure quality alongside adoption.
5. Reject “fix issues as they come”. At scale, reactive fixes lag the damage; the mitigations are structural (isolate, standardise, safe-merge, measure).

Exam-correct decision: treat the revert rate — not tasks-per-week — as the readiness signal; isolate parallel work per branch/worktree with a controlled merge; standardise AGENTS.md and configuration across the 25 repos with drift checks; reinstate the review gate and measure quality alongside adoption. Not “keep scaling because activity is up”, not parallel work on shared branches, not letting each repo diverge, not reactive-only fixes.

Assessment traps

Practice questions

Each item states how many responses to select. Attempt before revealing.

Key takeaways

• Parallelism is throughput; safety is isolation plus a controlled merge. Give each workstream its own branch/worktree and verify before merging.
• Standardise AGENTS.md and configuration across repositories, with drift checks, so agent behaviour is predictable everywhere.
• Match the integration to the job: GitHub Action for GitHub CI, Codex SDK for your own tooling, App Server for hosting, and the GitHub/GitLab (beta)/Slack/Linear integrations for their platforms.
• Remember GitLab is beta when planning a critical rollout.
• Measure adoption and quality; rising activity with falling quality is a warning, not a win.
• Scaling failure modes — collisions, config drift, unreviewed volume, activity-as-value, ungoverned auth, security debt — need structural mitigation, not reactive fixes.