Solo practice with an agent is a skill; team practice is a system. The same briefing doc that felt ergonomic as a personal scratchpad becomes contested ground when five authors edit it. The skill one person wrote to speed up their week becomes a liability when it’s running on every teammate’s machine and no one is sure who maintains it. The move from individual to team is where agentic coding acquires the governance problems that every shared infrastructure eventually accumulates.

Representation

A team using agents shares three things, whether or not they intend to.

The first is briefing context — the project-level documents (CLAUDE.md, GEMINI.md, AGENTS.md) that prime every agent on every machine with the same baseline. If the team does not explicitly maintain these, each engineer’s personal copy drifts, and agents begin giving different answers to the same question depending on whose workstation is running them.

The second is skill and command infrastructure — the slash commands, custom skills, and prompt templates that encode team-specific workflows. One engineer writes a /deploy-preview command; three weeks later four teammates are relying on it, none of them sure who owns it.

The third is policy — what the agents are allowed to do in the team’s shared environments. Individual practitioners set permissions for themselves; teams must set permissions as a contract, written down, reviewable, auditable.

The failure modes of team agent practice are specific and repeat across teams.

Briefing-doc bloat. Everyone adds their context without removing anyone else’s. After six months the briefing doc is 8,000 words, the agent reads most of it before doing anything, and the team is paying a context tax on every session without noticing. Nobody owns it because it belongs to everyone.

Skill-registry rot. A skill is useful for a month, then becomes obsolete when the underlying workflow changes. Nobody removes it; a new teammate joins, uses the stale skill, gets a result that matched reality two quarters ago but does not now. The skill never broke; the context it encoded became wrong without breaking.

Permission erosion. The CI policy starts strict. A teammate hits a legitimate case the policy blocks, a one-off exception is carved out, then another, then another. Six months later the policy has thirty carve-outs and no one can tell which are still justified. The net effect is that permissions reset to “allow everything” through accretion.

Review-cycle arbitrage. A teammate notices that agent-generated PRs get lighter review than human-written PRs — because the reviewer assumes the agent was careful, or because the PRs are often trivial, or because there’s no convention. Real bugs start landing through this channel. The agent didn’t get worse; the review discipline slipped for an entire category of change.

Operation

Four practices — shared briefing-doc discipline, skill registries, agent-assisted review, and policy-as-code — carry most of the weight.

Practice 1: briefing-doc discipline

The top-level briefing doc (Ch 7) is the highest-leverage shared artifact in the repo. Treat it the way the team treats any other load-bearing file — a CODEOWNERS entry, PR review required, a changelog comment in the file itself when major sections are added or removed.

The mistake to avoid: treating the briefing doc as documentation for humans who happen to also be using agents. That framing leads to explanatory prose, historical context, onboarding material — all of which is useful for humans and wasteful of agent context. The briefing doc is a briefing for the agent; human-oriented material belongs in linked docs the agent can fetch on demand.

Practice 2: team skill and command registries

Personal skills live in ~/.claude/skills/, ~/.gemini/commands/, and similar per-user locations. Team skills need to live somewhere the team can see, review, and version. Two shapes work well in practice.

All three tools have converged on the same basic architecture: repo-committed project-level directory for shared skills, user-level directory for personal skills. The specific path names differ; the two-tier pattern is convergent. If you design your team registry around the two-tier model, you are betting on a structural pattern that will outlast the specific paths.

A team skill registry also needs deprecation machinery. A skill that worked six months ago may be actively misleading now; a registry with no way to mark “retired” silently rots. Minimum: a retired/ subdirectory and a retired-at: field in the skill’s frontmatter, plus a quarterly review that moves unused skills there.

Practice 3: agent-assisted code review

The convergent pattern across the three tools: a human opens a PR, an agent runs automatically via the tool’s GitHub Action, the agent posts a review with comments, a human reviewer uses the agent’s review as input rather than replacement.

The governance questions around agent-assisted review are where teams get themselves into trouble.

Who reviews the agent’s output? If the agent posts fifty inline suggestions on a PR, the human reviewer either reads all of them (slow) or skims (misses things). The working pattern: the agent’s top-level summary is mandatory-read; inline suggestions are advisory; a human reviewer is still required for merge approval regardless of the agent’s verdict.

Does the agent get merge authority? Some teams let agent-approved PRs auto-merge if they pass CI. This works for narrowly-scoped changes (dependency bumps, generated-code updates) and fails for anything else. The boundary is clear in principle, fuzzy in practice — err toward requiring human approval.

What’s recorded? Agent reviews leave an audit trail in PR comments, but a reviewer’s agreement with the agent often doesn’t. If a human reviewer LGTMs a PR after reading the agent’s detailed review, the reviewer’s sign-off is as binding as any other — but the agent’s review contains the substance. Teams should be explicit about this: the agent’s review is reference material; the human approval is the authorization.

Practice 4: policy-as-code

For teams operating in CI (see Ch 12) or production environments, agent permissions are shared policy. The working pattern: check the policy configuration into the repo, review it via the same PR flow as code, and apply the same test-before-merge discipline to policy changes as to code changes.

The minimum: the tool’s settings/permissions file lives in the repo (settings.json, .claude/settings.json, or equivalent), is owned by someone in CODEOWNERS, and policy changes require the same review as code changes. The maximum: a dedicated policy engine (OPA, Cedar) that wraps the agent with declarative rules (“agents from branch X can touch paths matching Y, can call tools Z”). Few teams are at the maximum in 2026; most are at some point along the spectrum.

Evolution

Team patterns move more slowly than feature-surface details. Three axes worth tracking.

Emerging: skill-and-policy version pinning. Teams are beginning to pin the versions of skills, briefing-doc conventions, and policies — the same way they pin dependency versions. A PR that changes the briefing doc increments a version; CI jobs can select a specific version. This mirrors the direction software packaging went two decades ago; agent infrastructure is likely to follow. 18–24 months before mature tooling.

Emerging: role-scoped agents. A few teams have begun running multiple agent profiles — a “junior-dev agent” with narrow write permissions and thorough explanations, a “senior-dev agent” with broader permissions and terser output — and routing tasks to the appropriate profile. This is role-based access control applied to the agent itself. No tool ships first-class support in 2026; it’s a manual configuration pattern that will likely become a product feature.

Emerging: agent-generated changelog discipline. When agents author significant PRs, the question of attribution surfaces: who is accountable for the change? The emerging convention — the human who dispatched the agent is accountable, the agent’s involvement is logged in commit trailers — is not yet universal. Expect explicit commit-trailer conventions and org-level policy to settle over the next year.

Quick reference