How to Build a New Hire Buddy Program with an AI Company Brain

Keep the buddy a person and let the company brain do the paperwork around them. We recommend that the assistant track assignment, consent, cadence and backup, retrieve cited answers and route questions to the right owner, while the buddy's default move on a documented question is to look it up together with the hire, and nothing a hire says to the buddy is stored. Buddy programs break at assignment, cadence and backup, and an AI layer that automates the relationship itself adds a privacy risk without adding any support.

Where buddy programs break

Most programs define the idea and not the operating state. A manager enters a name in the onboarding plan and the organization treats the assignment as done. Then four gaps appear. The assigned person is a poor fit: on leave, overloaded, too close to the manager for a sensitive conversation, or unfamiliar with the hire's work. The buddy does not know what the role includes, so they answer policy questions from memory, promise things they cannot approve and become an unofficial performance evaluator. Meetings drift because a calendar invitation is mistaken for a conversation. And nobody has a recovery path when the buddy is absent or the relationship is not working.

GitLab's onboarding buddy guidance treats these as separate controls. Assignment belongs to the manager and is the first manager task in the onboarding issue. A buddy is asked to schedule an initial call, to check how far the hire has got through the onboarding issue, to check in at least twice in the week after the start date and at least once for the rest of the first month, and to arrange a backup if they will be out. The CIPD induction factsheet opens with a point worth keeping in view: first impressions can affect how well a person integrates into the team and how satisfied they are, and induction is the chance to welcome them, help them settle in and make sure they have the knowledge and support to do the role. The first two are human jobs, which is the buddy's part. The third is where the company brain helps.

Four roles, and the buddy's default move

Write a one-page role contract before configuring anything:

• The hiring manager owns the assignment, confirms workload and conflicts, approves exceptions and stays accountable for role expectations and performance conversations.
• The onboarding buddy helps the hire with team habits, finding people and sources, informal working norms and blockers. The buddy does not approve access, interpret regulated policy, promise employment outcomes or assess performance.
• The source owner answers questions that need an authoritative policy or process decision: People Operations, payroll, IT, security, legal or another owner.
• The AI company brain retrieves approved onboarding knowledge, shows the source and owner, tracks public workflow state and routes questions to the correct human. It does not store the content of private buddy conversations or replace accountable decisions.

As a decision rule: a documented, low-risk answer within the reader's permissions comes from the company brain with its citation. Team navigation and informal context go to the buddy. Anything that changes access, pay, benefits, policy application, safety or employment status goes to the accountable source owner. If the hire asks for privacy, stop the automated capture path and offer a human channel.

We recommend that the buddy's default move on a documented question is to look it up together with the hire. A buddy who answers from memory teaches the hire to ask a person, and sometimes passes on an outdated rule. A buddy who opens the cited page with the hire teaches them to find the answer, shows them who owns the source, and can file a knowledge-gap task on the spot if the page is wrong or missing. GitLab's buddies are asked to suggest helpful handbook pages and to help new team members get used to navigating the handbook, which builds the same habit.

One assignment record

Do not scatter the assignment across an HRIS note, a calendar event and a chat message. Create one minimal record that other systems can reference, and keep conversation content out of it:

{
 "assignment_id": "buddy-2026-042",
 "new_hire_id": "employee-1842",
 "buddy_id": "employee-0971",
 "manager_id": "employee-0310",
 "start_date": "2026-09-07",
 "program_end_date": "2026-10-02",
 "eligibility_checked_at": "2026-08-28T10:30:00Z",
 "buddy_accepted_at": "2026-08-28T12:05:00Z",
 "cadence": ["day 1", "day 3", "day 7", "day 14", "day 28"],
 "backup_buddy_id": "employee-1160",
 "allowed_context": ["team handbook", "role onboarding plan"],
 "status": "scheduled",
 "last_verified_at": "2026-08-28T12:10:00Z"
}

The record holds identity, ownership, consent, timing, allowed context, backup and state. It leaves out what the hire asked, how the buddy read the conversation and any sentiment score, which limits the personal information the workflow collects. People Operations sees the full assignment state, the buddy sees the hire's approved onboarding context, and the hire sees names, expectations, schedule and support routes. Better still, do not index the record: People Operations, the buddy and the hire can read it where the workflow lives. If you do index it, Microsoft's document-level access guidance for Azure AI Search lists four ways to enforce permissions at query time, so pick the one that matches your identity system.

The workflow in six steps

1. Check eligibility and ask for consent

Start seven to ten days before the start date, and evaluate explicit rules and not only a similarity score. Treat automated matching as a shortlist: the manager confirms suitability, then the proposed buddy actively accepts. Record a decline without asking for a reason, move to the next candidate, and never announce a buddy before they accept.

GitLab says its guidelines, a buddy with more than three months at the company who shares the department and a similar time zone and is free for the first two weeks, came from its onboarding survey and from buddies' feedback, and that meeting all of them is not always possible. We recommend the same split: gate on what makes the relationship impossible or unsafe, which is a planned absence in the first weeks, no capacity and a reporting conflict, and rank the rest. A hard filter on tenure or team turns "no eligible buddy" into the usual outcome.

2. Give the buddy a bounded context pack

The buddy needs enough to help, not the candidate record: the hire's name, pronouns if voluntarily supplied for this purpose, role, team, start date, time zone, approved work arrangement, onboarding plan and links to team knowledge. Exclude interview notes, compensation, medical or accommodation information, background checks and private manager comments. The company brain retrieves only sources both people may open, and if the hire cannot open a cited page, the buddy does not paraphrase it as a workaround. The access problem goes to the owner.

3. Schedule a cadence with state, not only reminders

Suggest a default such as day 1, 3, 7, 14 and 28, let both people adjust it, and track each checkpoint as scheduled, completed, rescheduled, declined or missed, because a calendar event proves delivery and not attendance. Ask either participant to confirm after the expected time, send one reminder, and if the checkpoint stays unresolved notify the program owner and not the hire.

We recommend capping contact before the start date at one welcome message and one call invitation, sent by the buddy and not by the assistant. GitLab's template does this: the welcome email goes to the hire's personal address because the work email is not available until day one, and it promises nothing further there beyond a Zoom invitation to say hello. State the cap in the message, and start the assistant's work on day one, when the hire has an account.

4. Route questions by type

Put a visible card in the onboarding workspace:

• Team habit or informal navigation: ask the buddy.
• Documented process: ask the company brain and inspect the cited source.
• Access request or technical failure: contact the named IT owner.
• Pay, benefits, leave, legal, safety or a policy exception: contact the authoritative owner.
• Personal concern or relationship problem: use the private People Operations channel.

The buddy can help the hire phrase a question, but the buddy's answer is not a policy source. If the buddy spots missing documentation, open a knowledge-gap task for the source owner, and never publish the conversation.

5. Provide a backup and a change path

Assign a backup before the program starts and define when it activates: an out-of-office period longer than two working days, two missed checkpoints, a team transfer or a request from either participant. Give the hire a neutral way to ask for another buddy without sending the reason to the current buddy or the manager, and let People Operations record the change while keeping the explanation in the appropriate private system.

6. Close with evidence, not surveillance

Confirm only what the process needs: the buddy accepted, the required introductions happened, the hire knows the support routes, unresolved blockers have owners and the assignment is closed. Do not ask the buddy to score readiness or mine message history for engagement. NIST's AI Risk Management Framework is voluntary and comes with a companion Playbook for putting it into practice. Use whichever review structure you prefer, as long as it tests these before launch: permissions, opt-out behavior, routing accuracy, backup activation and the deletion or restriction of temporary context.

A worked case

Maya joins a customer operations team on September 7. The workflow shortlists three experienced teammates, and her manager excludes one who will be on leave and another who directly owns Maya's probation review. Luis accepts, and the system records it and names Priya as backup. Luis receives Maya's role, start date, time zone, team handbook and approved onboarding plan, and no interview feedback or compensation data. On day one Maya asks whether a customer refund exception applies in her country. Luis does not answer from memory. He and Maya open the current policy through the company brain, see its owner, and because the case needs interpretation the workflow routes it to the regional operations owner. In week two Luis is out for three days, so the workflow activates Priya for one check-in and tells Maya who is covering. No private notes were stored, so none are copied. At the end of week four Maya confirms she knows where team knowledge lives and how to reach the buddy, the manager and the policy owners, one tool-access issue stays assigned to IT, and People Operations closes the record without rating Maya or analyzing her messages.

Failures to expect

• No eligible buddy accepts. Notify the manager and the program owner, and use a temporary People Operations contact and not an overloaded employee by default.
• The cited knowledge is inaccessible. Do not have the buddy copy it into chat. Create an access task or replace the source with an approved version the hire may read.
• A meeting is repeatedly missed. Trigger the backup or reassignment path at the defined threshold, because more reminders do not fix a capacity problem.
• The buddy gives a wrong policy answer. Correct it through the accountable owner, tell the people who acted on it, restate the buddy boundary, and do not turn the message into searchable policy.
• The hire asks a private question in the AI interface. Show a clear notice, stop automated routing where possible and offer the private human channel, without summarizing the question into the assignment record.
• The assignment record goes stale. Revalidate identity, availability and access when a manager changes, a buddy transfers teams or the end date moves.

Test it before launch

Run an acceptance test with People Operations, a manager, a buddy and a test employee identity. Confirm that an unaccepted buddy is never announced and an ineligible or unavailable person is excluded, that the hire and the buddy see only the approved context pack and restricted sources stay restricted, that each checkpoint has an observable state and one missed checkpoint does not cause reminder spam, that backup activation works and either participant can request a change privately, that policy and access questions reach the right owner, and that private conversation content is absent from the record and temporary context follows your retention rule.

Kipwise's employee onboarding workflow shows how assigned knowledge, company search, and progress tracking can sit around onboarding work. Whatever platform you use, keep the buddy contract independent of the product. Identity, consent, role boundaries, permissions, routing, backup, and closure are the controls that make the program durable.

Start with one cohort

Choose one team hiring at least two people in the next month. Write the role contract, define eligibility, create the minimal assignment record, name the private escalation route and test one backup activation before inviting real participants. Then run the cohort and review process failures, not employee behavior.