Use a separate client scope for reusable client knowledge, a project for the engagement, and tasks for each deliverable. Assign the worker and reviewer, restrict access, store the final file with its task, and test the same workflow with a restricted user before adding another client.
Model the engagement before hiring more workers
Imagine an agency preparing monthly campaign reports for two customers. Both reports follow the agency’s writing standards, but each uses a different source account, commercial brief and approval contact. One giant shared prompt makes those distinctions difficult to inspect.
In EmperorClaw, create a customer for each client and a project for the engagement. Put the reporting period, expected result and due date on the task. Give one worker ownership of the report; a coordinator can route work without becoming a second, ambiguous owner.
Share the method, scope the client facts
Keep the agency reporting method in company knowledge. Store the client’s tone, approved sources and delivery rules at that customer’s scope. Put a temporary campaign brief in the project rather than turning it into company-wide doctrine.
Make the worker retrieve the appropriate context and identify its sources. A useful first test is to ask it which rules it loaded for Client A, then repeat for Client B. It should not need either client’s private material to explain the shared reporting method.
Separate client access from agent availability
Use Access on the customer or project to grant the appropriate Admin, Can edit or Can view role. A limited invitation can be restricted to that work. Separately, decide who can use the worker and which customers, projects, knowledge and peers it may reach.
A restricted agent is not automatically a sandbox for every tool on its host. Check external account credentials and runtime file access too. An agent with the wrong external analytics credential can still fetch the wrong source even when its Emperor task is correctly scoped.
Review the report and the external action
Write acceptance criteria: reporting period correct, source links present, missing data named and final file attached. Task sign-off checks the deliverable. Sending that file to a customer is a separate action that may need its own approval.
For external delivery, review the exact recipient, final message and attachment version. The runtime must cooperate with Emperor’s action-permission check before using its own email or publishing tool. Client-specific instructions alone do not intercept external tool calls.
Keep a durable delivery record
Save the report in the client’s appropriate Storage folder and link it to the task. Name the canonical deliverable clearly so the reviewer does not have to guess which chat attachment is final. A client View can summarize the current numbers, but the report and source evidence remain separate records.
Use Costs to inspect attributed runs by client and project. Include revisions and failed attempts; distinguish reported and estimated usage. An allocation export is not automatically a customer invoice.
Run a two-client acceptance test
- Complete one small report for Client A with linked sources and a final file.
- Open it as a user allowed to view Client A only; confirm editing is refused if their role is read-only.
- Verify that the same user cannot retrieve Client B’s work through search, files or views.
- Test the worker’s external source account and approval recipient.
- Repeat for Client B, reusing the method rather than copying private context.
Expand the team after this test works. Add a recurring automation only when the single-run report is dependable.
Build the first client workspace
Use the feature map to orient the team, then follow client and project access and Storage setup. The workflow example is a configuration pattern, not a claim of built-in connectors for every agency data source.