An AI agent for client onboarding should gather approved intake information, explain the next step, and prepare a reviewable handoff. I would start with one workflow and make the completion criteria explicit before connecting any tools.

This guide builds an illustrative agency intake agent in Pickaxe. The example is a reusable design, not a claim about measured results from a customer deployment.

Define the onboarding agent's job

For this example, the client needs to submit a project brief, identify the decision-maker, and select a kickoff window. The agent can explain the process and prepare an intake summary; a team member approves the handoff.

My completion rule: an intake is ready only when the required fields are present and the client has confirmed the summary. A conversational “thanks” is not proof that a project record was created.

Field	Required?	How I would handle it
Organization and contact email	Yes	Ask for confirmation before sending a summary
Project goal	Yes	Capture the concrete outcome in the client's words
Decision-maker	Yes	Identify who can approve the work
Approved brief	Yes	Check that the document is the current version
Kickoff preference	Yes	Collect a preference without claiming a booking
Passwords or secret keys	No	Use the team's separate secure access process

Step 1: create the agent and choose a model

I would create an agent with one clear purpose and select a model in Agent Builder → Build → Model. The Agent Builder guide and model documentation describe the current interface.

I would start with a model that handles the required instructions and Actions, then compare cost and reliability using the same intake cases. Our LLM selection guide explains that evaluation.

Step 2: use an onboarding prompt with clear boundaries

Purpose: Help a new client complete the approved project intake.
Ask for organization, contact email, project goal, decision-maker, current brief, and kickoff preference. Ask one focused follow-up at a time.
Use the approved onboarding checklist to explain requirements. Do not invent prices, deadlines, or contract terms.
Never ask for passwords, payment card details, or API secrets in chat.
When the required fields are present, show a concise summary and ask the client to confirm it.
Only submit the intake after confirmation and only through the configured Action. Report success only when the Action returns a confirmed result.
If a field is missing, a source conflicts, or an Action fails, explain the issue and route to the project lead.

I would adapt this example to the actual service and approval rules. I would keep the agent's job small enough that a reviewer can tell whether it completed it correctly.

Step 3: connect the approved Knowledge Base

I would connect the onboarding checklist, service scope, and current contact or escalation instructions. I would omit obsolete offers and documents the client should not see.

In Build → Knowledge Base, choose Connect files or Add more files. To reuse an existing source, choose it from Workspace Knowledge Base.

The upload walkthrough covers the product steps. The RAG guide explains source design and retrieval testing.

Step 4: define the handoff before connecting Actions

I would first decide what the project team needs to receive. A compact structured record makes missing fields easier to detect than a long transcript.

{
  "organization": "Example Design Co",
  "contact_email": "contact@example.com",
  "project_goal": "Launch a customer support agent",
  "decision_maker": "Project owner",
  "brief_received": true,
  "kickoff_preference": "Tuesday afternoon",
  "client_confirmed": true,
  "status": "ready_for_team_review"
}

This is a hypothetical intake record. I would include only the fields the receiving system needs and verify them before sending.

Then I would connect an Action to create or update the appropriate record, where the integration supports it. I would check the credential permissions and required inputs for that exact system.

Design for retries. I would use a stable intake identifier where the integration supports one and check for an existing record before creating another. A retry should not silently create duplicate clients.

Step 5: test a realistic intake sequence

Case	Pass condition
All required fields provided	Agent summarizes accurately and asks for confirmation
Decision-maker missing	Agent asks for it and does not submit
Client changes the project goal	The confirmed summary uses the latest value
Client offers a password	Agent directs them to the approved access process
Action times out	Agent reports uncertainty and avoids claiming success
Client repeats submission	The integration detects or safely handles a duplicate
Policy does not answer a question	Agent acknowledges the gap and escalates

I would run these in the actual deployment and inspect the receiving system. A plausible chat response is not proof that an Action stored the right data.

I would also test each intended access group. Documents connected to an agent can influence its answers, so I would not mix clients' private material into a shared agent without an appropriate separation design.

Step 6: deploy the onboarding agent

I would use a portal when onboarding is part of a branded client experience, or an embed when the workflow belongs on an existing site.

I would configure access for the intended clients, test as a client, and verify the handoff with a team member. The access documentation explains the available controls.

I would publish a clear next step after submission. If kickoff requires approval, the agent should say “submitted for review,” not “your kickoff is booked.”

Measure the onboarding workflow

I would compare completion rate and staff follow-up time against the existing intake process. I would also inspect missing fields, duplicate records, failed Actions, and escalations.

For example, if 40 hypothetical intake starts produce 28 confirmed, valid submissions, the completion rate is 70%. I would keep starts, completed records, and team approvals separate so the number remains interpretable.

I would review a sample of transcripts after launch and add recurring failures to the test set. Changes to the onboarding policy, prompt, model, or integration should trigger a re-test.

Selling this as an agency service

I would sell the scoped workflow and its maintenance, not a promise that the client never needs to speak to the team. The proposal should define sources, integrations, acceptance cases, support, and who owns changes.

Our agency playbook, local business sales guide, and pricing model guide cover packaging and commercial scope.

Frequently asked questions

Does an onboarding agent need Actions?

It can answer process questions without them. It needs a suitable integration if it should create records, send notifications, or perform another external operation.

Can the agent schedule a kickoff?

Only if the deployment has the appropriate scheduling integration and permissions. Otherwise, I would collect a preference and let the team confirm it.

What should the first version include?

I would use one approved checklist, a small required-field set, one handoff destination, and a clear escalation path. I would expand after the initial workflow passes its tests.

Can I reuse the same agent for every client?

I would reuse the design while separating client sources, permissions, and destination records. A reusable template is different from sharing private context across clients.

I would start by writing the required fields and pass conditions. That turns a chatbot idea into a workflow I can build, inspect, and maintain.