Client Onboarding Assistant
A dozen small obligations owned by different people, tracked in someone's head.
At a glance
- Who it’s for
- What it does
- New clients move through onboarding steps, with each step tracked in one place.
- What stays in your tenant
- Onboarding records are stored in Dataverse in your environment, under your security roles.
This build demonstrates the pattern using a fictional company; the constraint discussed is real, but this is not delivered client work.
The problem
Onboarding a new client in a professional services firm is a dozen small obligations owned by different people: engagement letter, identity and compliance checks, document collection, system provisioning, billing setup, kickoff scheduling. Each is simple. Collectively they are a coordination problem, tracked in someone's head and a spreadsheet.
The failure is rarely a missed step in isolation. It is that nobody can say, at any given moment, where a given client actually is in the process.
Why several agents rather than one
A single agent covering the whole process becomes unmaintainable quickly. Its instructions grow to cover every branch, its topics collide, and changing the compliance rules risks breaking document collection.
Splitting by domain keeps each agent small enough to reason about and test. A parent agent handles the conversation and delegates to specialists in intake, document collection, and provisioning. Each specialist owns its own knowledge, tools, and rules. The compliance team can change their agent without anyone touching the others.
Architecture
The parent agent holds the conversation and the overall state. It routes each request to the child agent that owns that domain, and each child returns a structured result rather than free text. Progress is written to Dataverse so status is queryable independently of any conversation.
The constraint that drives the design
Delegation boundaries must match ownership boundaries.
The temptation is to split agents by conversational topic. The durable split is by who owns the rules. Compliance owns identity checks, operations owns provisioning, finance owns billing setup. When agent boundaries match team boundaries, each team can change its own logic without a coordinated release.
Split any other way and you have distributed a monolith: the same coupling, now across four places.
Delivery considerations
State lives in Dataverse, not in the conversation. A client onboarding runs for weeks across many sessions and several staff. Conversation memory cannot carry it.
Children return structured results. Free text passed between agents compounds ambiguity at every hop.
Failure must be visible. If a child agent cannot complete, the parent surfaces it and the record shows a blocked state, rather than the process silently stalling.
Handover means documented boundaries. Whoever maintains this needs to know which agent owns which decision, or the first change will be made in the wrong place.
Keep reading
More from the App Library
Power Platform admin · DLP · Environment strategy
Agent Governance Setup
DLP is the boundary that has to hold, and it has to be set per environment
Copilot Studio · SharePoint Online
Policy and Handbook Assistant
Answers only from the corpus and refuses rather than guessing
Copilot Studio · Power Automate · Dataverse
Time Off and Request Intake
Approval runs after the return step, outside the 100 second timeout
