← All work

Connected agents · Power Automate · Dataverse

Multi-Agent Client Onboarding

A dozen small obligations owned by different people, tracked in someone's head.


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

Multi-Agent Client Onboarding architectureA parent agent holds the conversation and delegates to three child agents split by which team owns the rules: intake, compliance and provisioning. Each returns a structured result. Progress is written to Dataverse so status is queryable outside any conversation.Parent agentHolds the conversation and routesno domain rules of its ownIntake agentowned by OperationsEngagement letter,scope, kickoffreturns a structured resultCompliance agentowned by Compliance teamIdentity checks,document collectionreturns a structured resultProvisioning agentowned by ITAccounts, access,billing setupreturns a structured resultDelegation boundaries match ownership boundaries — each team changes its own agent without a coordinated releaseSplit by conversational topic instead and you have distributed a monolith: the same coupling, now across four places.Dataverse — onboarding stateruns for weeks across many sessions and several staffconversation memory cannot carry it — blocked states are visible
Delegation boundaries match ownership boundaries, or it is a distributed monolith

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.