Onboarding a New Hire Alongside an Agent That Already Knows the Job

A new person joins. The work they were hired to do is now mostly drafted by an agent, and their first month consists of reading output and clicking approve. Four weeks later they are fast and they cannot tell you why any of it is right.

Onboarding a new hire alongside an agent has one hard requirement: they must do the work unaided before they are allowed to approve it. Judgement comes from having made the decision yourself and seen what happened, and reviewing someone else's answer, human or machine, does not build it.

What gets lost

The old apprenticeship was inefficient and it worked. A junior did the tedious version of a task, got it wrong, had it corrected, and slowly built a sense of what a good answer looks like. The tedium was not the point but it was the vehicle.

Remove the drafting and you remove the vehicle. What is left is a person comparing an answer to a standard they have not yet developed. They cannot spot a subtly wrong figure because they have never worked out the figure. They cannot notice a missing section because they do not know what the sections are for.

Worse, the output is fluent. A new person reads confident prose about a domain they do not know and assumes competence. They are not being lazy. They have nothing to compare against.

Do the work first, then see the draft

The fix is ordering, and it is not complicated.

For the first stretch, the new person does the task themselves before the agent's version is shown to them. Then they compare. Then someone experienced walks through the differences with them.

This is slower for a while. That is the entire cost, and it buys what you are hiring for.

The comparison is where the learning lands. Three outcomes, all useful:

• They got it right and the agent got it right. Confidence, and a sense of what the standard is.
• They differed and they were wrong. The correction sticks because they had committed to an answer.
• They differed and they were right. The most valuable case. They learn that the output is not authority, which is the lesson the whole approval step depends on.

Give them the failures early

Most training material shows the happy path. For someone who will spend their week approving, the important material is the other one.

Keep a set of real cases where the agent got it wrong, with the reason. Not hypotheticals. Actual output that was rejected, and what the reviewer noticed.

Walk a new joiner through those in week one. It does two things. It teaches the specific failure shapes in your domain, and it sets the expectation that rejection is normal and expected rather than an accusation of a broken system.

If your team has no such collection, that is itself worth knowing. It means either nothing has ever been rejected or nobody wrote it down.

Let them reject things

There is a social problem underneath the technical one. A new person is unlikely to reject output that three experienced colleagues have been approving all year. They assume the group knows better.

Say out loud that rejecting is part of the job, and put some effort into training the team to reject agent output well. Ask a new joiner, at the end of week one, what looked odd. Take the answer seriously even when it is wrong, because the alternative is training them to stay quiet.

The teams that get this wrong tend to be the ones where approval throughput is measured and rejection is not.

What the manager has to keep doing

None of this works if the experienced people have also stopped doing the work.

If nobody on the team has produced the thing from scratch in eighteen months, there is no one to run the comparison conversation. The same quiet drift turns up elsewhere, for instance when automated meeting notes change what people say out loud. The knowledge that made the review meaningful is aging out, quietly, while the numbers look fine.

Some teams handle this by rotating a portion of work through a manual path deliberately. It looks wasteful on a spreadsheet. It is the same argument as keeping a skill current for the day the tool is unavailable or wrong in a new way.

The first ninety days, roughly

• Weeks one to two. Do tasks manually. See the agent's version afterwards. Discuss the gaps with someone senior. Read the rejection archive.
• Weeks three to six. Approve real work, but with a second reviewer behind them, and keep a manual task each week.
• After that. Approve independently, with escalation rules they helped write, because writing the rules is itself a test of whether they understand the risks.

Adjust the lengths to the complexity of your work. The sequence matters more than the timings.

Where the system helps

SicherOne keeps project management, HR and agent activity on one set of records, so a new joiner's comparison exercise sits next to the real history of the work rather than in a training environment that resembles nothing. A human approves agent output before it ships, which is what makes the new person's role a real one rather than a formality.

Existing staff need their own version of this conversation about which part of their job the agent is doing. The failure to avoid is a team where everyone can operate the approval queue and nobody could do the job without it. That state is easy to reach by accident and hard to reverse once the people who knew have left.