Clanker CloudWinning an engagement is followed by a different job: getting delivery ready. Someone has to reconcile the approved scope with sales notes, identify missing inputs, prepare the kickoff agenda, and explain what the client needs to do next. In a small consultancy, that someone may also be selling and delivering the work.
An onboarding Agent in Clanker Cloud Workspace can prepare a consistent kickoff pack from the material you provide. Save the consultancy's method in the Agent, keep each engagement's facts in its Project, and review the resulting checklist before using it with the client.
The example below is fictional. It shows a role to configure and a packet to test, without claiming that client systems have been connected or that an engagement has already run through the process.
Separate your method from the engagement
Your onboarding method changes less often than a client's brief. It might require an approved scope, a named contact, a list of missing inputs, and a kickoff agenda. Those rules belong in the reusable Agent's instructions or reference knowledge.
The signed-off scope, actual contacts, project dates, and current requests belong in the engagement Project. Keeping those facts separate makes it easier to reuse the role without carrying the previous client's details into a new task. Check the selected Project, knowledge, and files before each run.
Start with three deliverables:
- An internal readiness checklist for the engagement owner.
- A client-facing list of inputs and clarification questions.
- A kickoff agenda built around confirmed goals and unresolved decisions.
The onboarding checklist walkthrough covers a single task. This version turns that task into an Agent you can test and reuse.
Configure an Engagement Coordinator Agent
Create a custom Agent and select the tools needed to read Project files and save the pack. Add your onboarding procedure as reference knowledge. Broad access to unrelated systems is unnecessary for this first file-based task.
Use instructions such as:
Prepare onboarding packs for consultancy engagements.
Use the current Project's approved scope and intake material.
Identify the source for commitments, owners, and dates.
Separate approved work, requested additions, and open questions.
Use "unknown" when a source does not identify an owner or date.
Keep internal readiness notes separate from client-facing text.
Draft the client input request and kickoff agenda for review.
Do not accept scope changes, promise a delivery date,
create accounts, request credentials, or send messages.
Save the requested files in the current Project.
These instructions describe the role you want; test whether the output follows them. The custom Agent guide explains how to choose knowledge, Skills, and tools. A reusable Skill can hold a detailed checklist when your process needs one.
Build a small test packet
Create a Project for a fictional operations consultancy engagement. Add this as intake-notes.md:
Client: Harbor Goods, fictional business.
Approved work: review order-handling steps and recommend changes.
Deliverables: process map and recommendations memo.
One workshop is included. Implementation is outside scope.
Client contact: Priya, operations manager.
Consultancy lead: Elena.
The process outline has been received.
A sample order export is still missing.
Priya suggested a workshop on 22 October; not confirmed.
A later email asks us to configure the order system.
No system access or implementation work has been approved.
Keep the current scope in a separate file so the Agent has an explicit authority for agreed work. Mark sales notes and later requests as such. A request to configure a system should not become an implementation commitment merely because it appears in the same packet.
Run the Agent once before reusing it
Start a Session with the Agent in the engagement Project and give it this task:
Read the approved scope and intake notes for Harbor Goods.
Create a kickoff pack with these files:
engagement-readiness.md: scope, received inputs, missing inputs,
stated owners, dependencies, and decisions for Elena.
client-input-request.md: a concise draft asking for missing
material and clarification. Keep internal commentary out.
kickoff-agenda.md: confirmed objectives, preparation,
discussion topics, and decisions still needed.
Cite source filenames for material commitments in the
internal checklist. Keep 22 October tentative.
Flag system configuration as an additional request.
Use fictional data labels. Save the files; do not send them.
Open the files and follow the evidence. The missing export should be visible. The workshop should be tentative. Implementation should remain outside the approved scope. Priya and Elena should retain their stated roles without acquiring new approval powers that the packet never gave them.
Read the client-facing request separately. It should ask for the missing material and confirmation needed for kickoff. It should not include the consultancy's internal evaluation of the client or silently ask for administrator credentials.
Test difficult packets, then save the improvements
Try a second fictional packet with no client contact and two conflicting proposed dates. A useful Agent preserves those uncertainties. If it chooses a date or invents an owner, revise its instructions and repeat the trial before applying the role to another engagement.
Save useful corrections in the Agent's method. Keep client-specific corrections in the Project. When an actual client supplies a missing input, add the dated source and ask for an updated pack showing what changed. The saved first draft is history, not the current state forever.
For collaboration, review the private sharing workflow. Sharing an Agent copy does not automatically provide its recipient with the original Project's files or private connections; set up the recipient's context separately.
Once onboarding is working, reuse the same engagement Project for weekly client reporting. If requests arrive by email, configure the revision-request workflow separately and verify its sender permissions and automatic response behavior.
Measure missing inputs caught before kickoff, corrections needed, preparation time, review time, and usage across several engagements. Begin with the custom-assistant starting flow, then copy this role and test packet into your own setup. The first useful result is a kickoff pack you trust enough to review with the client.
Sources
Give your assistant one useful job
Start the custom-assistant flow, then use this onboarding role and fictional packet to test your consultancy's process.