How to Govern Claude at Scale: From Solo to Enterprise

In a hierarchical company, the org chart describes who routes information to whom. It is the map of how decisions move, how context flows, and where authority lives.

In an AI-native company, the file structure does the same job.

CLAUDE.md. .claude/settings.json. managed-settings.json. Most teams treat these as configuration files. They are not. They are the codified operating model. They define what your agent knows, what it can reach, what it is allowed to do, and who has the authority to change any of it.

The teams that understand this build deliberate file structures and review changes the way they review code. The teams that do not end up with operating models that drift, fragment, and eventually break under the weight of their own inconsistency.

What follows is the file structure of an AI-native company at four scales: solo, team, organization, and enterprise. The pattern at each level is the same. Only the contracts change.

Scale 1: Solo

Files in play:

• ~/.claude/CLAUDE.md (global personal context)
• ~/.claude/settings.json (global personal settings)
• <project>/CLAUDE.md (project context)
• <project>/.claude/settings.json (project MCP servers, permissions)
• Local MCP servers (stdio)

At the solo scale, the file structure is the contract between an individual and their agent. The global CLAUDE.md declares stable preferences: tone, defaults, the kinds of mistakes you do not want repeated. The project CLAUDE.md declares context: what this codebase is, what conventions matter here, what the agent should assume when it opens a file.

The settings files declare integration topology. Which MCP servers are available. What permissions are granted. What the model can reach and what it cannot.

This is small but consequential. A well-constructed solo file structure is the difference between an agent that feels like a sharp collaborator and one that feels like a search engine with a chat box. The investment is small. The compounding effect is large.

Scale 2: Team

Files in play:

• <repo>/CLAUDE.md (checked into git, shared project context)
• <repo>/.claude/settings.json (checked into git, team MCP servers and permissions)
• <repo>/.claude/settings.local.json (gitignored, personal overrides)
• <repo>/AGENTS.md (multi-agent definitions)
• <repo>/SKILL.md files (shared skills)
• Shared prompt libraries (versioned in repo)

At the team scale, the file structure becomes the contract between teammates and the shared agent. This is where two patterns become non-negotiable.

First, CLAUDE.md belongs in version control and changes should go through pull request review. The agent's understanding of your codebase is now organizational knowledge. A change to CLAUDE.md is a change to how every teammate's agent will reason about the code. That deserves the same review rigor as a change to a critical interface.

Second, the split between .claude/settings.json and .claude/settings.local.json matters. The first is shared and committed. The second is personal and gitignored. Teams that conflate these end up either committing personal API keys to the repo or imposing one developer's MCP server choices on everyone. Get the boundary right early.

The shared prompt library is the third piece. Once a team is past pilot, the prompts that drive workflows become institutional assets. They should live in the repo, be reviewed when changed, and be tested for regressions when the model version updates. Prompts are code. Treat them as such.

Scale 3: Organization

Files in play:

• managed-settings.json (IT-deployed via MDM or GPO, cannot be overridden locally)
• Approved MCP server allowlist (referenced from managed settings)
• Org-wide CLAUDE.md templates (one per team, centrally maintained)
• Centralized prompt registry (versioned, reviewed, deployed)
• Audit log retention and routing configs
• API gateway routing rules (model selection, cost attribution, PII filtering)

At the organization scale, the file structure becomes the contract between IT and security and the workforce. This is where managed-settings.json earns its keep.

managed-settings.json is deployed by IT via MDM or group policy and cannot be overridden by a local user. It enforces the organization's policy decisions: which API endpoint to use, which MCP servers are approved, which models are permitted, what permissions are denied. It is the security boundary expressed as a file.

The approved MCP server allowlist deserves particular attention. The public MCP ecosystem will eventually have the same supply chain risks that npm and PyPI have today. A managed allowlist is the difference between teams installing whatever they find on a registry and teams running only the servers your security team has reviewed. This is non-negotiable for any deployment that touches sensitive data.

The centralized prompt registry is the third leg. Departments will diverge on prompts unless there is a canonical source. Drift in prompts means drift in outputs, which means drift in quality and brand voice. A registry, version-controlled and reviewed, prevents that drift without forcing every team into the same prompts.

This is the scale where most organizations attempting Claude deployment quietly fail. They get the technology working, then discover six months later that they have no consistent governance because nobody owned the file structure as a deliberate artifact.

Scale 4: Enterprise

Files in play:

• Multiple workspace topologies (per BU, per region, per data classification)
• Federated MCP server catalogs (governed by domain, not centrally)
• Organizational CLAUDE.md as code (versioned, reviewed in PRs, tested)
• Multi-tenant prompt registries with per-team scoping
• Cross-workspace governance configs (data residency, retention, audit routing)
• Compliance and retention policies expressed as files

At the enterprise scale, the file structure becomes the contract between the organization and itself. The complexity comes from federation: multiple business units with different needs, different data sensitivity, different regulatory regimes, all consuming the same underlying platform.

The pattern that works is the one that works for code at this scale. A platform team owns the substrate (the gateway, the audit pipeline, the managed settings template) and exposes it through versioned, reviewable artifacts. Domain teams own their slice (their CLAUDE.md patterns, their MCP server catalog, their prompt registry) inside guardrails the platform team sets.

CLAUDE.md at the enterprise scale is not a static file. It is configuration as code, deployed through CI, tested before promotion to production, and rolled back when changes regress quality. Same for the prompt registry. Same for managed settings.

The enterprises that get this right look like mature platform engineering organizations. The enterprises that get it wrong have one team's brilliant Claude deployment and three other teams' shadow copies of it that are quietly diverging.

The Pattern Is Always The Same

At every scale, three things are true.

• The file structure is a contract. It defines what is shared, what is personal, what is locked, and what is negotiable. Get the contract wrong and the operating model breaks.
• The contract should be reviewed like code. Changes to CLAUDE.md, settings files, prompt libraries, and MCP server registrations are changes to how the organization thinks. They deserve PR review, version control, and testing.
• The contract scales by federation, not by centralization. Trying to manage every team's CLAUDE.md from a central authority does not scale. Letting every team do whatever they want produces drift. The pattern that works is platform-level guardrails with domain-level autonomy inside them.

The Org Chart, Made Visible

The phrase "your file structure is your org chart" is not metaphor. It is description.

Walk into a hierarchical company and you can read the org chart. Walk into an AI-native company and you can read the file structure. The decisions about what is shared, what is locked, who can change what, and how the agent reasons about its work are all expressed as files.

The companies that build their file structure deliberately end up with operating models that scale. The ones that treat these files as configuration trivia end up with operating models that fragment.

This is the boring infrastructure of the AI-native organization. Boring infrastructure is where every transformation succeeds or fails.