AI Workflows for Multi-Client Agencies: How Agencies Run AI Workflows for Multiple Clients

An agency running AI workflows for a single client can get away with a lot. One shared environment, one set of credentials, one audit trail that covers everything. The moment you add a second client, the shared-environment model starts to break down. By the time you have five or ten clients, it has broken completely.

The problems are structural. Shared environments mean shared risk: a misconfigured workflow for client B can expose client A's data. Shared credentials mean shared blast radius: a compromised API key affects every client. Shared audit trails mean you cannot produce a clean, client-specific record of what AI did on behalf of that client. And shared security settings mean you cannot enforce client-specific compliance requirements, like the financial services client who needs SOC 2 audit logging and the healthcare client who needs GDPR compliance mode.

The correct architecture for a multi-client agency is multi-tenancy: one platform, one management layer, but a fully isolated environment for each client. Each environment has its own identity, its own data, its own security policy, its own credentials, and its own audit trail. Nothing crosses the boundary between environments unless you explicitly design it to.

DAVE is built on this architecture. Every workspace in DAVE is a fully isolated tenant. The tenant boundary is enforced at the authentication layer (tokens are scoped to the tenant and cannot be reused across tenants), at the data layer (per-tenant encryption with AES-256-GCM authenticated encryption), and at the credential layer (each tenant's credential vault is encrypted separately and credentials are never returned through the API once stored). When you run an AI workflow for client A, it runs in client A's tenant. Client B's environment is not involved, not visible, and not at risk.

Every client workspace in DAVE is configured from Admin, then Settings. This page is the control center for the tenant's identity, appearance, and data lifecycle. Only users with the Admin role can access it.

The settings page is organized into three groups:

General: Tenant Name and Application Name. The Tenant Name identifies the workspace throughout the platform. The Application Name appears in the browser tab title and the application header, and defaults to "Hello Dave." For a client workspace, set the Application Name to something that identifies the client's environment clearly, for example "Acme Corp AI" or "Hello Dave - Acme." This matters when your team members have multiple client workspaces open in different browser tabs: a meaningful Application Name prevents the wrong workflow from being edited in the wrong client's environment.

Theme Colors: Primary, Secondary, and Background. Each tenant has its own color scheme, set via a color picker with hex code input. The defaults are Primary #3b82f6, Secondary #8b5cf6, Background #0a0a0a. For client workspaces, setting the primary color to the client's brand color makes the environment immediately recognizable. Theme changes take effect immediately after saving, with no page reload required.

Retention Policy: Retain Instances, Retain Artifacts, Retain Audit Logs. Each retention field has a dropdown with options of 30, 60, 90, 180, 365, or 730 days, or Forever. The defaults are 90 days for instances and artifacts, and 365 days for audit logs. For client workspaces, retention policy is a contractual and compliance question, not just a technical one. A client with a 12-month data retention requirement needs the Retain Instances and Retain Artifacts fields set to 365 days or longer. A client subject to SOC 2 should consider the SOC 2 recommendation of 7-year audit log retention, which means setting Retain Audit Logs to 730 days or Forever and exporting logs before the retention period lapses.

All settings changes take effect immediately on save. A green confirmation banner confirms success. Retention policy changes may take up to 24 hours to affect existing data, as cleanup runs via a scheduled background task. Expired data is permanently deleted and cannot be recovered: set retention periods before the client's data starts accumulating, not after.

One of the most valuable features of DAVE's multi-tenant architecture for agencies is that every security control is per-tenant. You can enforce different security policies for different clients without any of those policies affecting each other. A financial services client who requires hardware MFA and 90-day password expiration gets exactly that, in their workspace, without affecting the startup client in the next workspace who is running with email OTP and no expiration policy.

All security settings are configured from Admin, then Settings, then the Access tab.

Password policy. Five complexity levels are available: None, Basic (8 or more characters), Standard (8 or more characters, mixed case, number), Strong (12 or more characters, mixed case, number, symbol), and Enterprise (16 or more characters, mixed case, number, symbol, no common passwords). Password expiration can be set to apply to all passwords, all non-admin passwords, or disabled entirely. When expiration is enabled, the expiration period is set with a slider from 15 to 90 days. A Force Change After Reset checkbox (checked by default) ensures users must set a new password immediately after an admin resets theirs.

Multi-factor authentication. DAVE supports eight MFA provider types, configurable per tenant. The MFA enforcement policy has three options: tenant-wide optional (users can choose to enable MFA), tenant-wide mandatory (all users must enroll before accessing the workspace), or per-user optional (the admin configures MFA on a user-by-user basis). A grace period of 0 to 30 days gives users time to enroll after mandatory MFA is switched on. Trusted device duration (0 to 90 days) controls how long a device remains trusted before re-verification is required. Backup codes can be enabled or disabled per tenant.

The eight supported MFA providers are: Google Authenticator (TOTP), Microsoft Authenticator (TOTP with push notification support), Authy (multi-device TOTP with encrypted cloud backup), Duo Security (push notifications, phone callback, and hardware token support), YubiKey (FIDO2/WebAuthn hardware security key), Email OTP, SMS OTP, and Custom (configurable name, type, and setup instructions). Each provider card in the settings interface includes inline setup instructions.

Single sign-on (SSO/OIDC). SSO is a separate feature from MFA, configured on the OAuth sub-tab within the Access tab. Five SSO providers are supported: Google, Microsoft, GitHub, Okta, and Custom OIDC. When one or more SSO providers are enabled, users see the corresponding login buttons on the workspace login page alongside the standard email and password form. Each provider requires a Client ID, Client Secret, and either a Discovery URL (for OIDC providers) or an Authorization URL. The Callback URL is auto-generated based on the tenant's configuration. For enterprise clients who authenticate via Okta or a custom OIDC provider, SSO can be enabled in their workspace without affecting any other client's workspace.

Login security. Rate limiting is on by default, with a configurable maximum of 1 to 20 failed login attempts (default 3) before a lockout is triggered, and a configurable lockout duration of 1 to 60 minutes (default 5 minutes). Lockout events are recorded in the audit log. CAPTCHA can be added as an additional layer, with four supported providers: reCAPTCHA v2 (checkbox challenge), reCAPTCHA v3 (invisible score-based, with a configurable minimum score threshold from 0.0 to 1.0), hCaptcha, and Cloudflare Turnstile.

Session management. Session timeout is configurable from 5 to 1440 minutes, with a default of 60 minutes. Sessions use JWT-based authentication with tenant-scoped tokens. Refresh token rotation is enforced: each token refresh invalidates the previous refresh token to prevent replay attacks. Tokens are scoped to the tenant, ensuring no cross-tenant token reuse. A user who is logged into two client workspaces simultaneously holds two separate, non-interchangeable token sets.

Different clients have different compliance requirements. A client in financial services may need SOC 2 audit logging. A client handling EU personal data may need GDPR compliance mode. A client with neither requirement may be happy with standard audit logging. DAVE's compliance settings are per-tenant, so each client gets exactly the compliance mode their situation requires.

Compliance standards are configured from Admin, then Settings, then the Audit Log section within System Parameters. Three standards are available:

• Standard. Always on and cannot be disabled. Captures all mutations, authentication events, and system changes. This is the baseline audit trail that every DAVE tenant has, regardless of any other setting.
• SOC 2. Adds read-access logging for sensitive endpoints, covering SOC 2 trust service criteria CC6 (Logical and Physical Access), CC7 (System Operations), and CC8 (Change Management). When SOC 2 is enabled, every read of a sensitive resource (users, roles, credentials, API clients) is logged as a security event, not just writes. SOC 2 mode also activates prompt injection detection logging under CC7.2. The SOC 2 standard recommends 7-year audit log retention: set Retain Audit Logs to 730 days or Forever for clients with this requirement, and establish an export schedule before the retention period lapses.
• GDPR. Adds read-access logging for user data endpoints, covering GDPR Articles 5 (Lawfulness of Processing), 15 (Right of Access), 17 (Right to Erasure), 30 (Records of Processing Activities), and 33 (Breach Notification). For clients handling EU personal data, enabling GDPR mode ensures that every access to personal data is logged, supporting the client's obligations under Articles 15 and 30.

SOC 2 and GDPR can be independently enabled. A client who needs both gets both. A client who needs neither gets standard logging only. When a compliance standard is enabled or disabled, a timestamped audit.compliance_changed event is automatically logged with a before/after snapshot of the enabled standards. This means the compliance configuration history is itself part of the audit trail.

All audit events include a complianceTags array in their detail payload, indicating which compliance standards the event satisfies. The audit log page displays compliance badges next to event types, making it straightforward to filter and export events by compliance standard for a client audit.

The audit trail is the agency's proof of process. When a client asks "what did the AI do with my data last Tuesday?", the answer is in the audit trail: every workflow operation, every AI call, every human review decision, every credential access, every settings change, with the identity of the user who performed each action and the timestamp. This is the record that turns AI automation from a black box into an auditable, defensible process.

Each client workspace has its own notification configuration, managed from Admin, then Settings, then the Notifications tab. Notifications are per-tenant: the notification rules for client A's workspace have no effect on client B's workspace.

Notification events. Five events can trigger email notifications: task assigned, instance started, instance completed, instance cancelled, and user invited. Each event has an on/off toggle and an audience selector. The master Email Notifications switch turns all notifications on or off for the workspace without discarding individual event settings.

Notification audiences. Six audience types are available for each event: task assignee, instance owner, instance participants, workspace admins, role-based (every active user holding a named role), and a specific named user. Audiences can be combined: a task assigned event can notify both the task assignee and all workspace admins simultaneously.

Per-node overrides. Individual workflow steps can override the workspace notification rule. In the workflow editor, selecting a User Interaction or Human Review node and opening its Notifications section gives three options: use the workspace rule (the default), no notification (this step stays silent even when the workspace rule is on), and custom audience (this step notifies its own audience instead of the workspace rule's audience). This is useful for high-volume review workflows where notifying admins on every task would create noise: the per-node override silences the noisy step without changing the rule for the rest of the workflow.

Email templates. Each notification event has a customizable email template with variable substitution using {{placeholder}} syntax. For client workspaces, customizing the templates to use the client's Application Name and relevant context variables makes the notifications feel native to the client's environment rather than generic platform emails.

Team roles for an agency workspace. DAVE's six default roles map onto the typical agency team structure for a client engagement. Admin users configure the workspace and manage team members. Curate users build and maintain the workflow graphs for the client. Create users build and maintain the agents and prompt library. Use users run workflow instances and complete human review tasks. Reporting users monitor workflow performance and review the audit trail. Financial users manage billing for the workspace. A single team member can hold multiple roles simultaneously on a single seat: a senior consultant who both designs workflows (Curate) and runs instances (Use) does not need two seats.

Is each client's data completely isolated from other clients?
Yes. Each DAVE workspace is a fully isolated tenant. Data isolation is enforced at the authentication layer (tokens are scoped to the tenant and cannot be reused across tenants), at the data layer (per-tenant encryption with AES-256-GCM authenticated encryption), and at the credential layer (each tenant's credential vault is encrypted separately). No data crosses the tenant boundary unless you explicitly design a workflow to move it.

Can a team member work across multiple client workspaces?
Yes. A team member can hold accounts in multiple DAVE workspaces. Each workspace login produces a separate, tenant-scoped token. The tokens are not interchangeable: logging into client A's workspace does not give access to client B's workspace. The team member switches between workspaces by logging into each one separately.

Can I use different AI providers for different clients?
Yes. AI provider configuration is per-tenant. You can configure OpenAI for one client, Anthropic for another, and Azure OpenAI for a third. Each client's credentials are stored in their own encrypted vault and are never returned through the API once stored. DAVE supports seven AI provider types: OpenAI, Anthropic, Azure OpenAI, Google, OpenAI-compatible, local (Ollama), and custom. You bring your own API keys for each provider and pay the provider directly. DAVE never proxies or marks up AI usage.

Can I enforce different security policies for different clients?
Yes. Every security setting in DAVE is per-tenant: password complexity, MFA enforcement, SSO provider, login rate limiting, CAPTCHA, and session timeout are all configured independently for each workspace. A client who requires mandatory hardware MFA and 90-day password expiration gets that in their workspace. A client with no MFA requirement gets a different configuration in theirs.

Can I enable SOC 2 logging for one client and GDPR logging for another?
Yes. SOC 2 and GDPR compliance modes are per-tenant and independently configurable. Each client's workspace has its own compliance settings, its own audit trail, and its own retention policy.

What happens to a client's data when the engagement ends?
The retention policy controls how long workflow instances, artifacts, and audit logs are kept before automatic cleanup. When an engagement ends, you can reduce the retention period to accelerate cleanup, or set it to a specific duration that matches your contractual obligations. Expired data is permanently deleted and cannot be recovered. Export any data the client needs before reducing retention periods or ending the workspace.

Can I use the same workflow design across multiple client workspaces?
Workflow graphs are per-tenant. There is no built-in mechanism to push a workflow from one tenant to another described in the current settings documentation. If you have a standard workflow design that you want to deploy across multiple client workspaces, you would rebuild it in each workspace or use the API. Contact the DAVE team for current options on workflow portability across tenants.