Onboarding a new agent without grinding your team to a halt

Let a new agent write their own answers on day two, without sending them yet. That's the fastest onboarding method there is. Many teams do the opposite. First a week of reading along, then observing, and only then typing something themselves.

Reading along feels safe, but it yields little. Someone reading another person's conversation sees the answer but not the hesitation before it. The questions onboarding is really about almost never concern the wording of the answer. They concern: am I allowed to promise this, where do I look this up, and who decides when the amount is higher.

Those questions only surface when someone is in the driver's seat. And they're valuable, because nine times out of ten the answer isn't written down anywhere.

The hidden cost of onboarding isn't with the new agent. They produce little in the first weeks, and everyone knows it. The cost sits with the experienced colleague beside them.

Do the maths for a team of five. A new agent easily asks fifteen questions a day in the first two weeks. Each question interrupts a colleague who is mid-conversation. A two-minute interruption costs more than two minutes, because afterwards that colleague has to get back into the case they were working out. Two people working at half strength together costs more than one new agent needing three days longer.

That explains why teams postpone onboarding until things are quiet. Except things don't get quiet, and a new agent learns the trade precisely on the busy days. Waiting for room means structurally onboarding too late.

The way out isn't allowing fewer questions. It's making the same question cost you only once.

Almost every company that wants a knowledge base starts with an empty document and a list of topics. Someone is asked to write out the most important procedures. Three weeks later there are forty articles nobody reads, because they answer questions nobody asked.

The reverse route works better. Every question a new agent asks a colleague is by definition a question that occurs in practice. Record those questions for two weeks and you need no topic list: you have the list. What's more, a real phrasing comes with it, because the answer the colleague gave on the spot is exactly the answer that works.

That's this article's point in one line: a knowledge base shouldn't be written in advance but derived from the questions you don't want to answer twice.

In practice it works like this. Open a shared channel or document where the new agent asks their questions, instead of calling them across the room. The experienced colleague answers there. At the end of the week someone runs through the list and turns the five recurring questions into a knowledge article. Five a week, not forty at once.

The side effect is that the next new agent no longer has to ask those five questions. Person three's onboarding is shorter than person two's, and with over-the-shoulder onboarding that's never the case.

A concrete schedule a small team can run without freeing anyone up.

Day 1. Systems, passwords and one pass over the actual products. No explaining procedures, because they don't land yet.

Days 2 to 5. Writing their own answers to real questions from the largest category, not sent until a colleague has seen them. That's the core. The new agent runs into every ambiguity without a customer noticing.

Week 2. Sending independently in that same category, with a sample review afterwards. New categories are added only once the first one runs unaided. Half-mastering two categories is slower than fully mastering one.

When reviewing in week 1, there's one question per answer: could this have been sent, and if not, which fact was missing. Feedback on phrasing comes later. Start on tone in week 1 and you teach someone to write cautiously before they know what they're talking about.

This schedule resembles what a team with AI drafts already does, and that isn't a coincidence. A draft reviewed before sending is exactly what an onboarding agent needs. The difference is that with an agent you also use the corrections to update your documentation, rather than only improving the answer.

This approach doesn't apply everywhere. In conversations where most of the work sits in the conversation itself, there's little to record. Phone support is the clearest example: a new agent learning to handle an irritated caller learns that by listening in, not by reading an article. There, sitting alongside an experienced colleague is the fastest route, and the knowledge base only helps with the factual side.

In very small teams the arithmetic changes too. With two of you, a shared question channel is heavier than turning round in your chair. Do still record the answers, even if the asking stays out loud.

And in highly specialist work where every case differs, a list of recurring questions yields little. There the gain sits not in the knowledge base but in building the record per customer.

Whichever package you use, a system needs to support three things here. Having an answer reviewed before it's sent. Surfacing a question that had no usable answer instead of letting it vanish into a conversation. And turning such a question into a knowledge article in one action. Without that last part, every good intention stalls at the moment someone has to type it out again.

In Cuego an answer sits as a draft on the conversation until someone releases it, and questions the knowledge base had no grounding for land separately in a knowledge-gap list, with the original question and the channel. For an onboarding agent that's the same list as for the AI agent: both trip over exactly the information nobody wrote down.

Next time someone starts, set up just one thing differently from last time: let the questions land somewhere they stay put. It won't change that agent's onboarding time much. It will change the next one's.