Multi-client infrastructure for AI agencies: what to standardise and what to isolate

An AI agency rarely has one product and one environment. It delivers agents, RAG systems, automations, APIs and workers for different clients. Every project may need its own cloud account, secrets, database, storage, model and access policy.

The problem begins when isolating clients means inventing a different operation for each one.

The first project can be operated manually. With five or ten active projects, deployments, access and alerts begin to compete with feature development.

The pattern that stops scaling

The sequence is usually familiar:

1. A VPS or cloud account is created for the client.
2. One person configures variables, networks and permissions.
3. Deployment is partially documented or remains in their memory.
4. Alerts arrive in different channels.
5. An incident returns to the person who built the environment.

This is not necessarily bad engineering. It is a fast way to start a project. The risk is repeating the exception until it becomes the agency operating model.

What should remain isolated

A common foundation does not mean sharing everything. Some elements need explicit client boundaries:

• secrets and credentials;
• data and storage;
• resources and consumption limits;
• networks and access policies;
• logs containing sensitive information;
• cost allocation and tagging;
• backups and recovery;
• change traceability.

The isolation level depends on the contract, data sensitivity and regulatory requirements. An experiment does not need the same architecture as a service processing confidential documents.

What should be standardised

The agency gains capacity when it reuses the process without mixing client contexts:

• a repository template;
• one approach to defining infrastructure;
• pipelines with consistent stages;
• staging and production conventions;
• centralised secret management;
• mandatory minimum observability;
• runbooks for common incidents;
• onboarding and offboarding checklists;
• tags that attribute cost.

Useful standardisation creates a known path. It does not force every project onto one provider or introduce Kubernetes by default.

Reference architecture: common operating plane, client boundaries

An initial architecture can separate the agency operating plane from each client’s resources:

                     AGENCY OPERATING PLANE
        repositories · templates · CI/CD · inventory · alerts
                                  │
                 ┌────────────────┼────────────────┐
                 │                │                │
            CLIENT A         CLIENT B         CLIENT C
          account/project  account/project  account/project
          app · data       app · data       app · data
          secrets · logs   secrets · logs   secrets · logs

The common plane knows how to deploy and verify. It does not need to centralise all data or hold permanent cross-client access. Every boundary should be revocable without affecting other clients.

Namespace, cluster or account: choosing the boundary

There is no single answer. The boundary follows the damage that an isolation failure could cause:

Boundary	When it may fit	Main risk
Namespace	Homogeneous workloads, same owner and moderate requirements	Misconfiguration shares a cluster and control plane
Separate cluster	Different teams, lifecycles or criticality	Higher cost and maintenance
Cloud account or project	Legally separate clients, billing or independent access	More governance and delivery complexity
Separate provider	Contractual, regional or technical requirement	Operating variation and less reuse

Record the data involved, identity, network, billing, recovery and control-plane owner. Kubernetes provides isolation mechanisms, but its multi-tenancy documentation distinguishes shared and dedicated clusters according to trust boundaries.

A minimum client definition

Onboarding should not depend on copying a folder and remembering which values to change. Even a small definition can make differences explicit:

client: acme
owner: delivery-acme
environment:
  region: eu-west
  isolation: cloud-account
  data_classification: confidential
delivery:
  repository: acme-platform
  production_approval: client-and-agency
operations:
  alerts: acme-operations
  recovery_target: documented-in-contract
  cost_tags: [client, environment, service]

This file contains no secrets and does not replace Terraform. It is a readable contract between onboarding, automation and operations. The pipeline can validate required fields before resources are created.

Guardrails before a large platform

The first controls should prevent expensive mistakes:

• reject deployments without client and environment tags;
• reject secrets in variables or repositories without suitable encryption;
• block public resources unless an exception is approved;
• require an owner and alert channel;
• verify a backup policy before production;
• record who approved the change and which version was deployed;
• run a post-deployment check and retain the result.

These guardrails can begin as CI/CD validation. A developer portal is not required to create value.

Tests that reveal whether the model is operable

A quarterly review can select one client and check:

1. Access: temporarily remove the environment creator and deploy using the documented procedure.
2. Isolation: verify identities, network and queries cannot cross the client boundary.
3. Recovery: restore a component or dataset into an isolated environment.
4. Cost: explain the period’s bill using real tags and resources.
5. Exit: produce the resource, access and data inventory needed to transfer the service.

A ticked checklist without execution confirms intent only. Evidence should include pipeline logs, recovery results, permission changes and accepted exceptions.

An operational runtime, not another internal product

Building a complete platform can be tempting. For an agency of 10 to 60 people, starting smaller is usually better:

1. Identify the three most repeated operational jobs.
2. Create a template for the most common project type.
3. Automate deployments and environment creation.
4. Define ownership across application, data and infrastructure.
5. Measure onboarding time, manual intervention and incidents.

If a capability does not remove waiting, risk or repeated work, it probably is not needed yet.

What good looks like

Improvement should be visible in daily work:

• a developer can create an environment without waiting for one person;
• every new project follows a verifiable checklist;
• deployments have rollback and traceability;
• alerts reach the right owner;
• cost can be connected to a client;
• one person’s absence does not block production.

The agency does not need to become an infrastructure company. It needs an operational foundation consistent enough to onboard clients without multiplying internal workload.

A simple test: take the last client you onboarded and list every manual step, every permission granted and every decision known by only one person. That is the first map of what should be standardised.