How to manage AI coding context across multiple client projects

Picture an agency with ten developers working across fifteen client repositories. Some engineering rules are the same everywhere: how tests are written, where business logic lives, how credentials are handled. Others belong to one client: its domain model, its deployment setup, the integration nobody is allowed to touch.

Developers also use different AI coding agents. Some use Cursor, some use Claude Code, and the choice may change next year.

If all of that context is copied by hand into repositories and agent configurations, keeping it consistent gets harder with every project. The question this guide works through is how to separate reusable agency knowledge from client-specific context while still making both available during development.

The three layers of coding context

It helps to stop treating everything as one pile of "AI rules". Context at an agency sits at three different levels, with different owners and different lifespans.

1. Agency-level context

Agency-level AI coding context is reusable engineering knowledge that applies across multiple client projects. Examples are architecture principles, testing standards, security expectations, API conventions, and implementation patterns. The agency owns it and maintains it once.

2. Client and project-level context

Client-specific context should remain scoped to the project when it describes domain rules, architecture, constraints, or requirements unique to that client. Examples are domain terminology, the application's architecture, integration requirements, the deployment environment, and project specifications. It should not leak into unrelated projects.

3. Developer and task-level context

This is short-lived or personal: the current task, temporary debugging notes, preferred response style, exploratory instructions. Each agent has a place for personal preferences. Cursor has user rules, and Claude Code reads ~/.claude/CLAUDE.md and CLAUDE.local.md.

Putting all three in the same files makes every change riskier. A good context architecture makes the scope and owner of each piece explicit.

Why copying the same rules into every client repository does not scale

The common approach is to write a good set of engineering instructions and copy it into each client repository. At first this is simple and works.

Then one shared rule changes, and the agency has to update Client A, Client B, Client C, and every other repository that carries the rule. Some get updated. Some are forgotten. Some developers have extra local copies, and the agent-specific files hold yet another version.

Context drift occurs when copied versions of the same engineering knowledge stop matching across repositories, developers, or coding agents. Nothing breaks visibly. An agent in Client B just follows a rule the agency stopped using months ago.

Separate reusable knowledge from project-specific knowledge

Scope is the main design decision. Compare two rules:

• "Business logic should live outside HTTP controllers." This is reusable. It applies to most of the agency's work.
• "This application uses its existing service layer and domain boundaries, and they must be preserved." This is about one codebase and means nothing in another.

Applying all agency context to every project causes problems too. A convention that suits one client's stack can mislead an agent working in a different stack. Shared context should be scoped on purpose, not applied everywhere by default.

Option 1: keep everything in each client repository

Each repository holds all of its own instructions, including the agency's conventions. This is the simplest architecture, and for many agencies it is the right one.

• It is version controlled and transparent to the client.
• Project context stays next to the code.
• It needs no additional system.

It works best when the agency has few projects, shares little knowledge between them, wants the client to own every instruction, and has everyone on the same repository-level workflow.

The trade-offs:

• Reusable agency knowledge is duplicated in every repository.
• Changes have to be propagated by hand.
• The agency's own knowledge becomes coupled to repositories the client owns.
• Agent-specific copies may still be needed on top.

Option 2: maintain agency templates

A second approach is a canonical template: a starter set of rules the agency copies into each new project. New projects start consistently, the idea is easy to explain, and it fits scaffolding well.

Templates solve initialization better than synchronization. Once copied, the client project has its own version. Later changes to the template do not reach projects that already exist, so they do nothing about drift. Templates remain useful. They just solve a different problem from keeping many live projects aligned.

Option 3: use an agent-independent context layer

An agent-independent context layer separates project knowledge from the lifecycle of a specific coding agent, and, in this model, from the lifecycle of a specific repository. Reusable agency context, client context, and agent configuration stop being the same files.

The agency's knowledge can then exist independently of any one client repository or any one coding agent. The benefits are ownership, reuse, consistency, lifecycle control, less duplication, and agent independence.

Who should own the context?

Client work often mixes knowledge with different owners. Roughly:

• Client-owned: application architecture documentation, domain specifications, client-specific requirements, and project-specific constraints.
• Agency-owned: reusable engineering methodology, internal implementation patterns, cross-project conventions, and reusable guidance for coding agents.

Some information is shared, or governed by the contract rather than by either side alone. A technical system should not try to decide who owns what, and this guide is not legal advice. What the architecture can do is let you keep differently scoped knowledge in separate places, so the question can be answered by people instead of by where a file happened to be committed.

This is the same idea discussed in keeping AI coding agent rules outside your repository: repository ownership and context ownership are not always the same thing.

What happens when a client engagement ends?

If the agency's reusable instructions were committed into the client's repository, separating the two later is awkward. The files are mixed with the client's own, they are in Git history, and deciding what to keep means sorting them out by hand.

With agency context managed separately, the lifecycle is cleaner.

During the engagement, development uses the client repository, the client's context, and the agency's context together.

After the engagement:

• The client keeps its repository and its own project knowledge.
• The agency keeps its reusable context.
• Access to the agency-managed external context can be removed on its own.

Removing access manages future access and ownership boundaries. It does not erase what developers or AI systems have already seen, and it does not recall text already given to an agent in a running conversation.

Working across different coding agents

Agencies rarely standardize on one coding agent forever. One developer prefers Cursor, another prefers Claude Code, and the tools themselves change.

If the core engineering knowledge lives only in one agent's configuration, switching agents becomes a migration. Cursor project rules and Claude Code instruction files are different formats, and the two versions have to be kept in step by hand. A source that does not belong to either agent reduces that coupling. The mechanics of using two agents on the same project are covered in sharing project context between Cursor and Claude Code.

How XOROX approaches multi-client context

XOROX is an agent-independent project context layer for AI coding agents. It manages project context such as Rulesets and Specifications separately from the repository and makes it available to the agents it supports, currently Cursor and Claude Code.

For an agency, that means context can be maintained outside the client's repository and still be connected to the development work in it. It is worth being precise about how far the current product goes.

• One XOROX project per client project. Rulesets, Specifications, and credentials belong to a single project. Client-specific context stays with its project.
• No agency-wide layer. XOROX does not have organization-level Rulesets that projects inherit. The reusable agency context from the architecture above is something you maintain per project.
• Keeping one source for shared rules. A Ruleset can be created from a Notion page or from a file in a connected GitHub repository. Creating each project's Ruleset from the same page or file lets you edit the shared text in one place. GitHub-backed Rulesets update when the file changes on push. Notion-backed ones update when a workspace owner or admin refreshes them.
• Access is per project credential. Revoking a project's credential stops its delivery of context immediately. This is a manual step, not an automatic offboarding process.

There is no approval workflow, audit trail, or hierarchy of projects. If you need those, you need them from somewhere else. Workspaces with several members are part of the Pro plan; see the pricing on the home page.

Example agency workflow

A small agency has six developers and twelve active client projects. It has shared engineering conventions and a specification for each client, and developers use both Cursor and Claude Code.

1. Each client project is created as a project in XOROX.
2. Each project gets its Rulesets (the agency conventions that apply to it, such as testing and API rules) and its Specifications (that client's domain and deployment details). Where the shared text should stay in one place, the agency backs those Rulesets with the same Notion page or repository file.
3. A developer joins a client project, runs the installer, and runs xorox init in their clone with a credential for that project.
4. Cursor or Claude Code receives that project's Rulesets and can retrieve its Specifications when they apply.
5. Context is maintained in XOROX, not in the client repository, so the repository does not carry a copy of the agency's rules.
6. When the agency stops working on the project, it revokes that project's credential. The client repository is unchanged. Local agent configuration files that xorox init created remain on developers' machines until removed, and the Installation page describes how.

On macOS or Linux:

curl -fsSL https://xorox.eu/install.sh | sh
xorox init

On Windows (x64), in PowerShell:

irm https://xorox.eu/install.ps1 | iex
xorox init

xorox init stores the credential in the developer's user-level configuration, not in the repository, and keeps the files it adds out of Git. See Installation and Authentication.

For the team side of this, including how to decide what to share between developers, see managing shared AI coding rules across a development team.

When you don't need an external context layer

Repository-level instructions are simpler when:

• the agency has only a few projects,
• little context is reused between clients,
• each client should own all of the project's instructions,
• everyone uses the same coding agent,
• duplicated context is not causing maintenance problems, or
• everything relevant naturally belongs with the code.

An independent context layer becomes more useful when:

• the same engineering knowledge is reused across many projects,
• the team uses more than one coding agent,
• agency and client context have different owners,
• context changes independently of the repositories,
• developers move between client projects often, or
• duplicated instructions have started to drift.

If none of that applies yet, keep it simple.

Practical recommendations

1. Identify which context is agency-wide.
2. Keep client-specific knowledge scoped to its client and project.
3. Do not copy reusable rules unless independent copies are intentional.
4. Define a source of truth for shared engineering decisions.
5. Keep temporary task instructions out of permanent rule sets.
6. Review context regularly and remove what is obsolete.
7. Avoid tying organizational knowledge to one coding agent.
8. Treat context ownership as separate from repository ownership.

Summary

Managing AI coding context across client projects is mostly a problem of scope and ownership. The goal is not to centralize everything. It is to keep reusable agency knowledge reusable, keep client-specific context scoped to its project, and stop agent configuration from becoming the accidental source of truth.

XOROX provides an agent-independent project context layer for teams that want to manage coding-agent context separately from individual repositories and coding tools. The quickstart shows how to connect a first project.