# Agency Topology (/docs/organizations/agency-topology)



A typical way to run an agency on Layers: **one organization for the
agency, one project per client.**

```
Acme Performance (Organization)
├─ Client A — Mobile game (Project)
├─ Client B — Subscription app (Project)
├─ Client C — DTC ecommerce (Project)
└─ Client D — Health app (Project)
```

## Why one organization [#why-one-organization]

* **Single member pool** — add agency staff once at the organization level;
  they get access to every project in the organization.
* **Single billing relationship** — one subscription, one wallet.
* **One place to look for activity** across clients.

## Why per-client project [#why-per-client-project]

* **Isolated brand voice, data, and configs** — no cross-contamination.
* **Easy offboarding** — archive or export one project without affecting
  others.

## Onboarding a new client [#onboarding-a-new-client]

1. Org admin creates a new project from the agency organization.
2. Connect ad accounts on the project.
3. Add agency staff as members of the organization if they aren't already.

## When to split into multiple organizations [#when-to-split-into-multiple-organizations]

* **Different legal entities** for the agency.
* **Conflict-of-interest separation** between competing clients.
* **Data-residency requirements.**
* **Acquired sub-agency** whose staff should be fully isolated from parent
  clients.

## Limitations today [#limitations-today]

Layers does not currently support:

* Per-client role scoping (every org member can see every project in the
  organization).
* Per-client markup or pass-through billing.
* White-label branding (custom subdomain, custom login page).

If you need these, talk to Layers about your use case.