AI agent · HR & payroll · One entry, every system
Onboarding paperwork
A new joiner has to exist in a dozen systems before their first day, and each one asks for the same facts again. The agent takes one approved joiner record, creates the rest, checks that each entry took, and tells you exactly what failed.
Typical volumes for this process, not a client figure.
Twelve systems, one new joiner, one person doing it by hand.
One entry, the rest created and verified, with a report of what failed.
Where the time goes today
When someone accepts an offer, a chain of set-up begins: an employee record in the HR system, a payroll record with bank and tax details, an email account and directory entry, a building badge, a laptop order, benefits enrolment, access to the applications their role needs, a place on the induction schedule. Each system has its own form, and often one or two people in HR operations key the same name, start date, manager and cost centre into each.
The errors are small and costly. A start date keyed wrong in one system means the laptop arrives a week late. A mistyped cost centre in payroll charges the salary to the wrong department. A forgotten access request leaves the new joiner unable to work for their first days. None of this shows until the first day, when the manager notices, and it is rarely clear which system failed or why.
The steps also vary by joiner: role, country, contract type, rehire or not, company car or not. Checklists try to capture this, but they drift out of date as systems change.
How the agent works
- Read the joiner recordThe agent takes the approved joiner form or HR record, and the signed contract where fields must be confirmed, and extracts what each system needs: name, start date, role, manager, location, cost centre, contract type.
- Work out what appliesFrom role, location and contract type, it determines which systems and access profiles this joiner needs, using rules your HR and IT teams maintain.
- Create in each systemIt creates the record in each system through its interface, or raises a request in the owning team's queue where direct creation is not allowed, as with equipment orders.
- Verify each entryIt reads each record back and checks that the stored values match the joiner record, including start date, manager and cost centre.
- Report what failedHR receives one report per joiner: what was created and verified, what is pending with another team, and what failed, with the system's error message and a suggested next step.
What stays with a person
HR approves the joiner record before anything is created, and that approval is the control point: the agent never creates an employee from an unapproved offer. Pay, grade, exceptions to standard access and work authorisation checks stay with the people accountable for them. Where an identity or work authorisation document has to be seen and verified, a person does it.
When a system rejects an entry, the agent does not try different values until one is accepted. It reports the failure, and a person decides whether the joiner record or the target system needs correcting.
What it reads, what it produces
| It reads | It produces |
|---|---|
| The approved joiner form or HR system record | Records created in each target system |
| The signed contract or offer letter, where fields must be confirmed | Requests raised in the queues of teams that act themselves, such as equipment or facilities |
| Role-based access and equipment rules | A verification report per joiner, system by system |
| Each target system's record, read back after creation | A failure list with each system's error and a proposed fix |
| The organisation structure, for manager and cost centre | A record of everything created, reused later as the offboarding checklist |
Controls that come with it
- Nothing is created until the joiner record carries an HR approval.
- Access beyond the standard profile for a role requires a named approver.
- Each record is read back after creation; anything that does not verify is reported as failed.
- Every action is logged with the system, the values written and the response received.
- Each creation has a documented reversal, so a withdrawn offer can be undone in every system.
How you know it works
- Joiners fully set up before their start date
- HR time spent per joiner on system entry
- First-day issues reported by managers or joiners
- Entries failing verification, by system
Is your process ready?
- Written rules: which systems and access profiles each role and location needs is written down, or can be.
- Systems: most target systems accept entries through an interface, and their licences allow a service account to use it.
- Cheap check: each entry can be read back and compared the moment it is created.
- Volume: a few dozen joiners a month across many systems adds up to hundreds of entries; a handful of joiners a year does not repay the build.
- Consistent process: HR, IT and facilities agree on who creates what, and in which order.
The five candidacy checks are explained, with an exam, in the free Module 01.
What goes wrong
- Systems with no interface, where the agent can only raise a request and the chain stalls in someone's queue.
- Role-based access rules that exist only in the heads of IT administrators.
- Joiner records approved before key facts, such as cost centre or manager, are final.
- Automating onboarding without the matching offboarding, which leaves accounts open after people leave.
Questions we get
Is this an agent or a script?
If every joiner needs the same systems and every system has a stable interface, a script is cheaper and you should build one. An agent is worth it when the path varies by role, country and contract, when some inputs arrive as contracts or emails rather than structured forms, and when failures need to be read and explained, not just logged. Many organisations end up with both.
What about systems that have no interface?
For those, the agent raises a request in the queue the owning team already uses, with every field filled in, and tracks it until it is done. It does not operate systems by imitating a person at the screen unless you choose that and the licence allows it, because that approach breaks whenever the screens change.
Can it handle rehires and internal transfers?
Yes, with rules for each. A rehire may have an existing record to reactivate rather than a new one to create, and the agent checks for that before creating anything. An internal transfer changes some systems and leaves others alone. Each case type is tested against past examples before the agent handles it unsupervised.
How does offboarding fit in?
Because the agent records everything it created for each joiner, that record becomes the checklist for removing access when they leave. Offboarding is usually built second, reusing the same system connections. It matters as much for security as onboarding does for the first day, and an audit of leavers' access is far simpler when the list already exists.
Want this agent on your process?
Tell us about your version of this process — volumes, systems, what goes wrong. A person answers with an approach and a price, usually within two working days, or tells you it is the wrong project.