Alone, configuring an agent is a private matter; in a team it becomes a question of whose configuration prevails. As soon as several people and an administrator stand behind one repository, a hierarchy appears that cannot be ignored, and trying to act as if it were not there is costly - usually on the day someone's local relaxations meet in a shared branch.
The naive view is that everyone configures their own agent and a common order will emerge from personal settings. Or that everything can be described in one AGENTS.md and handed to the team as a single law. Both expectations feel practical right up to the first gap between what is allowed on paper and what a neighbor's agent actually does.
It breaks on the fact that a personal setting cannot weaken an organizational one. Organization-level deny and ask rules cannot be removed by a project config - and that is not a bug but the point: if a local file could override policy, there would simply be no policy. The personal lives under the organizational, not alongside it, and that is the only order in which the word policy means anything at all.
What the team contour provides: centralized billing and analytics, management of the available agents, an MCP registry, plugins and permissions at the organization level. Enterprise adds SSO over SAML or OIDC, centralized controls and dedicated deployment options. For example, the AllowedExtensions policy sets an allowlist of extension publishers at the device level, and update mode and telemetry are governed from there too - personal choice within these frames is already constrained by what the administrator set.
The professional mechanism is policy in layers, not one document. Roll it out by layer: identity, then repository access, then allowed agents, then permissions and sandbox, then plugins and MCP, then audit and branch protection. Each layer answers its own question, and together they give control that a single AGENTS.md cannot replace, because it sits in a different plane.
Why layers rather than one document. AGENTS.md is context and influence, not enforcement. It does not authenticate a user, does not constrain agents at the organization level, does not protect a branch from a merge without checks. The identity layer decides who; repository access - where; permissions and sandbox - what the agent may do by hand; plugins and MCP - which external capabilities are connected at all; audit and branch protection - what is not allowed without an independent check. Folding this into one file confuses an instruction with a boundary.
The administrator's minimum fits into five points. Allowed agents and channels are defined. Cascade is disabled or limited deliberately, not by the inertia of the transition period. The MCP and ACP registry passes review rather than being filled by anyone. Training, retention and sharing are documented. Protected branches require independent checks before a merge. This is not bureaucracy but the places where the absence of a decision becomes a decision itself - usually not in your favor.
The cost of a blurred policy is a quiet gap between what is allowed on paper and what each person's agent can really do. One developer lifted a restriction locally, another installed an unvetted plugin, a third left Cascade with its old permissions and memories - and there is no longer a common boundary, though at the level of words everything looked consistent. Such gaps make no noise until they meet in one pull request.
When a layered policy is justified. From the moment more than one person stands behind a repository and there is something to protect. For a small team, identity, allowed agents and branch protection are enough. Enterprise adds SSO, audit and dedicated deployment as the stakes grow - not before it is justified by load and risk, but not later than the first real risk of a leak or an uncontrolled action appears.
Verify policy by demonstration, not by trust. Confirm on a real machine that an organizational deny is not removed by a project config. Walk the administrator's checklist and mark that each point has an owner, not the shared responsibility of everyone at once. Check that the protected branch rejects a merge without independent checks. Each such check turns a declaration into a fact you can show.
The typical failure is trying to cover everything with one AGENTS.md; treating a personal setting as enough; leaving Cascade and the MCP registry without review by default; confusing the existence of a policy with its enforcement. The sign is the same: to the question who allowed this the answer sounds like no one explicitly. Assign a layer and an owner to each decision - and the policy stops being a declaration and becomes a boundary that holds without your constant presence.