We Onboarded a New Hire Without HR Touching Anything Twice

April 27, 2026Kris Newlin

Key Takeaways

Onboarding is repeated work pretending to be unique work. Same accounts, same trainings, same tools, same first-week plan. Most of it can be done once and reused.
The bottleneck is rarely HR's effort. It is the wait between "we hired Maya" and "Maya can actually do her job." Two weeks of waiting on access requests is normal at most companies.
An AI coworker turns onboarding into a single Slack thread. One message, one structured plan, drafts that go to a human for review, and a measurable first-week outcome.
Review-first matters here more than anywhere else. New employees are watching how your company actually works. Sloppy onboarding makes a permanent first impression.
The cost of a bad onboarding compounds. Engineers without working access spend their first week on Slack questions instead of code. New AEs without CRM access lose 5 days of pipeline.

The setup that broke

Our HR generalist, Lena, used to keep an onboarding spreadsheet. Sixteen rows per hire. Every row was a tool: Slack, Notion, Linear, GitHub, HubSpot, Stripe view-only, password manager, a calendar invite to the company all-hands, three Google Drive folders, a benefits portal, the engineering wiki, the design tokens repo, two internal Loom videos, and the welcome doc.

She did it by hand. Every hire. Every time.

Then we hired three engineers in one week.

By Wednesday Lena was working until 9 PM. By Thursday she had double-created a Notion account for one of them and missed Stripe access entirely for another. The engineer she missed sat through standup on Friday explaining she could not actually run the financial dashboard the team kept asking her to update.

We had not hired more people than usual. We had hired them at the same time. The system was fine for one. It was broken for three.

What changed

We started running new-hire onboarding through Viktor, our AI coworker. The first time we tried it, Lena posted a single message in a Slack thread:

@viktor we hired Maya Patel as a Senior Backend Engineer. Start date Monday. Her email is maya@ourcompany.com. She reports to Daniel. Standard engineer onboarding plus access to the payments service repo. Draft the full setup, do not execute anything yet, give me a checklist to approve.

Within a few minutes Lena had a 22-step plan in the thread. Each step had three things: what would happen, which tool would be touched, and the credentials or template that would be used. She approved it line by line. The lines she did not approve, she edited.

Once she clicked approve on the full plan, Viktor went and did the work. Slack invite sent. Notion seat assigned. Linear added to the engineering team. GitHub added to two repos. HubSpot view-only created. Calendar invites for the first two weeks. Welcome message drafted in Maya's onboarding channel for Lena to send under her own name.

The whole thing took 18 minutes of Lena's time. The previous version took 3 hours.

What does AI onboarding actually do?

It runs the repeatable scaffolding so a human can spend their time on the parts that need a human. Specifically:

Step	What HR used to do	What an AI coworker does
Account creation	Open 12 tabs, fill in 12 forms	Provision accounts via integrations after one approval
Permissioning	Look up role doc, copy paste roles	Apply role-based defaults, flag exceptions
First-week calendar	Manually invite to 8 meetings	Pull the standard schedule, add hire to recurring invites
Welcome content	Write personalized message	Draft personalized welcome from template, HR edits
Buddy assignment	Slack the team for a volunteer	Suggest 2-3 candidates based on tenure and team
Access audit on day 7	Forget about it	Run automatic check, flag missing access
Feedback survey on day 30	Forget about it	Send templated survey, collate results

What is left for the human: deciding who the buddy is, reading the day-30 survey, having actual conversations.

How does a first week actually look?

Maya's first week, after the new system was in place:

Day 0 (Friday before). Lena approved the plan in the thread. Maya got an email with her temporary password manager invite, a one-page welcome doc with her buddy's name and the company values, and a calendar invite for Monday morning.

Day 1. Maya logged into Slack at 9 AM. Daniel (her manager) and Carlos (her buddy) had each gotten a draft message asking them to introduce themselves. Daniel sent his straight; Carlos edited his. By 9:15 Maya had two real introductions waiting.

At 9:30 there was a calendar invite for a 30-minute "tools tour" with Carlos. Carlos did not have to remember to schedule it; the system had done it.

By noon, Maya had pushed her first commit to the docs repo (we have engineers fix a typo on day one as a deliberate exercise). The commit access worked because nothing was missing.

Day 3. Viktor pinged Lena in a private DM: "Maya has not used HubSpot yet. This is normal for engineers, but flagging for awareness." Lena ignored it. That was the right call.

Day 7. Auto-generated access audit. One issue: the design tokens repo had been overlooked because the role template was outdated. Lena fixed the template and re-ran the audit. Two minutes.

Day 30. Templated feedback survey, sent automatically. Three of seven engineers had filled it in by the next morning. Lena had real signal on what was working and what was not.

The point is not that any of this is futuristic. It is that none of it required Lena to remember to do it.

Where the review-first model earns its keep

We made one rule early: nothing in onboarding executes without a human approving the plan. This sounds slow. It is not.

Lena reviews the plan once. She edits the parts that are wrong. She approves. Then she goes back to her actual job.

Without review-first, two specific things go wrong. First, you give a new hire access they should not have, and you find out 90 days later when they accidentally see the salary spreadsheet. Second, you forget to give them access they should have, and they spend their first week filing tickets to get it.

Both of those have happened to us before. They have not happened since we put a human approval step in front of every onboarding plan.

If you want the longer argument for why this matters across all AI coworker use cases, we wrote it up in Don't Let Your AI Agent Act Without Asking.

What about offboarding?

The same thing in reverse. When someone leaves, you do not want to be hunting through 16 tools at 5 PM on someone's last day trying to remember which accounts they had.

We use the same approach. Manager posts the request in a thread. Viktor drafts the offboarding plan. HR approves. Access gets removed in a controlled order: customer-facing tools first, internal tools second, archived rather than deleted where possible.

The audit log is the bonus. Six months later, when someone asks "who had access to the Stripe production keys in March?" we have a real answer.

What if we do not have an HR person?

Most companies under 50 employees do not. Onboarding is whoever the founder asked to do it last time. Often the COO. Sometimes the office manager. Often nobody.

This is exactly the case where an AI coworker pays back the fastest. The bottleneck was never that HR was overworked. It was that nobody owned the process, so it never got systematized. An AI coworker forces the systematization, because to give it instructions you have to write the process down.

The first time you onboard someone with Viktor, you spend 30 minutes describing what should happen. The second time, you reuse the template and edit. The third time, it is a 5-minute approval thread.

You did not hire HR. You wrote the playbook HR would have written.

How does Viktor compare to traditional onboarding tools?

Traditional onboarding tools (BambooHR, Rippling, Gusto) run the HR side: payroll, benefits, document signing, employee records. They are good at what they do. They are not what we are talking about here.

Capability	HRIS (BambooHR, Rippling)	Viktor
Payroll, benefits, taxes	Yes	No
Document signing	Yes	Drafts, sends via SignWell
Account provisioning across 30 tools	Limited (SCIM where supported)	Yes, via 3,000+ integrations
Drafting personalized welcome content	No	Yes
Coordinating buddy assignments	No	Yes
Day-7 access audit	Manual	Automated
Day-30 feedback survey	Add-on module	Yes, via Slack DM or form tool
Approval workflow on every action	Limited	Yes, review-first by default

The two are complementary. Keep your HRIS for the legal and financial side. Add Viktor for the operational side that nobody owns.

Frequently Asked Questions

Does this work for non-engineering roles? Yes. The repetitive parts are the same: account creation, calendar setup, welcome content, access audit, feedback collection. The role-specific parts (which tools, which trainings, which buddy) are template variables.

What about background checks and I-9 verification? Those still go through your HRIS or your dedicated background check vendor. An AI coworker can remind you to start them, can confirm completion, and can flag a hire who is missing required documents on day 1, but it does not run the legal process itself.

How do you handle role changes after the hire is in the system? A role change runs through the same pattern. Manager posts the change. Viktor drafts the access delta (additions and removals). HR approves. Audit log records what changed.

What happens if Viktor gets the role template wrong? The reviewer catches it before approval. That is the entire point of the review-first model. Then you fix the template once, and every future hire benefits.

Is this safe? What about data leakage between hires? Each onboarding plan is generated for one hire. Viktor does not retain personally identifiable information beyond what is needed to execute the approved plan. We covered the broader security model in Is Your AI Agent Safe?.