How to Run a Recruiting to Onboarding Handoff for an AI Company Brain
Hand the company brain a few approved facts about an accepted hire and keep the candidate file out of its reach. We recommend a narrow handoff contract: an allowlist of fields with an owner for each, no connector from the assistant to the applicant tracking system (ATS), and a rule that anything promised in recruiting but missing from the signed offer stays unconfirmed. Without that, the manager repeats interviews and finds setup needs on day one, or interview ratings and sensitive notes end up in a tool built to answer employee questions.
The assistant gets no connector to the ATS
Recruiting and onboarding use information for different jobs, and their records should not merge. Interview feedback is not onboarding guidance, a recruiter's note about a requested schedule is not an approved arrangement, and a start date in an offer workflow does not prove that an employee identity is active.
We recommend giving the company brain no connector to the ATS at all, redacted or not. The ATS pushes an allowlisted event into the HR system, and the assistant reads only the HR system and the onboarding tools. A redaction layer has to be right on every query, and one new custom field in the ATS is enough to put an interview rating into an answer. With no connector there is nothing to redact, and the negative search test below checks an absence instead of a filter.
The NIST Privacy Framework has two subcategories that describe this design: CT.DP-P4, configurations that permit selective collection or disclosure of data elements, and CT.DP-P5, attribute references substituted for attribute values. The event below follows both, because it carries references and approved routing values and never the values themselves.
What crosses the boundary
Start with the smallest set of facts needed to prepare the employee's first work. For each field, record its source, purpose, destination, owner, verification rule and retention action.
| Source fact | Onboarding use | Destination | Acceptance owner | Rule |
|---|---|---|---|---|
| Legal name and employee identifier | Match the employee record | HR system | People Operations | Transfer through the approved HR integration |
| Confirmed start date | Schedule lifecycle tasks | HR and identity workflow | People Operations | Reject dates without an accepted employment state |
| Approved role, team, manager, and location | Select tasks and access requests | HR and onboarding workflow | Hiring manager | Manager must confirm before activation |
| Approved working arrangement | Prepare equipment and workplace tasks | Onboarding workflow | People Operations | Use the approved term, not a recruiter's free-text note |
| Named setup needs | Create owned follow-up tasks | Restricted case system | Assigned specialist | Pass a case reference, not sensitive details, to the company brain |
| Candidate interview notes and ratings | None | ATS only | Recruiting | Do not transfer |
This table is a design example, not a universal field list. Legal, privacy, HR and security owners must approve the contract for the locations and systems involved.
Prefer a controlled value to free text. A role identifier is safer to route than a paragraph describing the candidate, and a case reference is safer than accommodation, immigration, health or compensation details in a general payload. If the company brain needs to tell the hire whom to contact, it retrieves the support route and not the private case. Send the transfer as a versioned event, not as an unstructured prompt:
{
"event_type": "onboarding_handoff_prepared",
"contract_version": "1.0",
"employee_ref": "hr-record-reference",
"offer_ref": "signed-offer-reference",
"effective_start_date": "approved-date",
"role_ref": "approved-role-reference",
"manager_ref": "approved-manager-reference",
"location_ref": "approved-location-reference",
"task_refs": ["owned-task-reference"],
"source_system": "ats",
"acceptance_state": "awaiting_manager"
}The event holds no interview transcripts, no model summaries of candidate performance and no private case details. offer_ref points to the signed offer or addendum behind every term, and the stored contract version lets a later audit say which fields and rules applied.
Promises that are not in the offer
Candidates hear things in recruiting that never reach a document: a later start, a four-day week, a particular laptop, a review after six months. Before the handoff, ask the recruiter for a one-line list of anything promised outside the signed offer. Each item either goes into an addendum with an owner or is withdrawn in writing. Until then the assistant treats it as unconfirmed. It neither confirms nor denies it: it says it cannot find the item in the employee's record and routes the question to People Operations and the recruiter. A friendly "yes, that is right" from the assistant is a commitment nobody approved.
Run the handoff as an acceptance workflow
A webhook delivery proves only that one system sent a message. The handoff is complete when the hire is linked to one authoritative employee record, approved facts have named destinations and owners, the manager has accepted or corrected the context, the company brain serves approved material under the new identity's permissions, and temporary transfer data is deleted or restricted. Model it as a stateful process with outcomes such as prepared, awaiting_manager, accepted, activated, failed and closed, and run it in this order:
- Trigger only from the state your organization treats as an approved hire, plus the identifiers that prevent duplicate employee records, and not from a stage label recruiters use informally. If that state is reversed, stop activation and open an exception instead of deleting evidence.
- Validate the payload against the allowlist. Reject unknown fields, check controlled values such as location, legal entity, role, manager and start date against authoritative records, and quarantine an unsupported contract version. A newly added ATS field then cannot flow into onboarding by default.
- Create owned work, not a context dump. In the GitLab onboarding handbook, the onboarding issue is created at least four business days before the start date and assigned to both the manager and a People Operations team member, each with tasks to finish before the hire arrives. Copy that ownership. A fact such as "manager not confirmed" becomes a blocking task for People Operations, not a sentence in the new hire's searchable profile.
- Ask the hiring manager to accept or correct a short summary: role, team, location, start date, approved arrangement, first-week outcomes and open tasks. Record who accepted which contract version and when. Acceptance verifies operational context and does not authorize restricted access.
- Activate from authoritative identity state. Microsoft lists extending HR-driven provisioning as a reason to use Entra lifecycle workflows, which run their tasks against users the HR system has already provisioned. Keep that order on any identity platform. The company brain applies the activated identity's permissions and creates no trust from an ATS export, so it does not expose onboarding pages because the ATS says the candidate was hired.
- Close and clean up. Confirm that the employee record exists, tasks are owned, manager corrections were applied and company-brain access resolves under the intended identity. Then delete the temporary payload copies or restrict them under the retention rule. Closing should leave an outcome record, not the whole transfer message.
Kipwise's employee onboarding workflow illustrates the product-side destination: assigned reading, searchable company knowledge, and progress tracking. Feed that destination approved role and workflow references. Keep candidate evaluation records outside it.
Let the hire check the record
Before day one, send the hire the same facts the manager accepts, minus anything meant for the manager only: legal and preferred name, role, start date, location and working arrangement. The hire is the only source for how a name is spelled and where the laptop should ship, and a wrong value found in week two has already reached the email address, the badge and the equipment order. This is the Communicate-P function of the NIST framework in practice: individuals have reliable knowledge of how data about them are processed.
What the assistant may say during the transition
It may explain approved onboarding tasks, name the owner of an open request, link to current employee guidance and say that the manager has not yet confirmed. It should not summarize interview feedback, infer why the candidate received an offer, disclose private setup cases or claim that access is ready before the authoritative system reports success. When context is missing, the answer names the missing decision and its owner: "Your work location has not been confirmed in the employee record. People Operations owns that update, so location-specific onboarding tasks are paused." That beats guessing from the candidate's address or a recruiter's note.
When something goes wrong
- The start date changes: recalculate due dates and identity activation from the authoritative record and invalidate the old schedule, so the hire does not receive a second checklist.
- The manager rejects a field: keep the proposed and the corrected value in the outcome record, and update tasks from the accepted value. Do not edit the candidate record to make the discrepancy disappear.
- Identity creation fails: hold company-brain access and permission-dependent tasks, and send the identity owner the employee reference and an error category, not the candidate payload.
- An unexpected field appears: quarantine the event, record the contract mismatch and notify the integration owner. Do not ask the model whether the field looks sensitive.
- The same event arrives twice: key it on the hire, contract version and source event, and return the existing workflow state instead of creating duplicate accounts, tasks or reading assignments.
- Restricted data crosses the boundary: stop processing, restrict access to the payload, keep only the evidence incident handling needs, and fix the allowlist before replaying a clean event.
Test the boundary with a synthetic hire
Test business outcomes and negative controls, not API connectivity. Run a synthetic hire through the contract, then break it: add interview notes, ratings and a private case detail; change the start date and manager before activation; deliver the same event twice; send an unsupported contract version; remove a required owner. Each case must fail safely and leave a recovery route. Before launch, collect evidence that:
- the accepted payload contains only allowlisted fields, and every transferred fact has a purpose, a destination and an owner;
- manager corrections reach downstream tasks before activation;
- company-brain retrieval uses the activated employee identity;
- duplicate and out-of-order events do not create duplicate work;
- temporary transfer data follows the recorded cleanup action;
- a failed handoff resumes from the last accepted state without a full candidate export.
Then run the negative search test: put a distinctive phrase only in a synthetic interview note and search the company brain for it. The result must be empty before and after activation, in search, prompts, logs and onboarding exports.
Inventory one role's copy-and-paste
List every fact people copy from the ATS into onboarding for one role today, and classify each as transfer, task reference, manager confirmation or ATS-only data. Give every transferred item an owner and a cleanup rule, then run a synthetic hire through the contract. Connect live candidate records only after the negative search test and the cleanup check pass.
