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

• 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

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

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

• 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

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.