How Do You Bring Someone New Into an AI-Heavy Workflow?

How Do You Bring Someone New Into an AI-Heavy Workflow?

Teach the judgement before the tools. A new person can learn a prompt in an hour. What takes months, and what nobody writes down, is knowing when the output is wrong, which steps a human must still sign off, and what the team decided not to automate and why.

We work this way ourselves, and we have watched clients try to hand an AI-assisted process to a new hire. The failure is almost never that the person cannot use the tool. It is that the process only ever existed in the head of whoever built it.

This is what we think good onboarding looks like when a real part of the work runs through models.

Why Is This Harder Than Normal Onboarding?

Because the process has fewer visible edges. A traditional workflow leaves a trail of forms, tickets and handoffs that a newcomer can follow. An AI-assisted one often looks like a person typing into a box and accepting what comes back.

The expertise is in the accepting. A person who has run the process for a year rejects a bad output in two seconds and cannot always tell you how. That instinct is the thing you need to transfer, and it does not live in the prompt.

There is a second difficulty. The tool changes under you. Models are updated, prompts get tuned, and a walkthrough recorded in March may not match what happens in September.

Is There a Legal Dimension to This?

In the European Union, yes. Article 4 of the EU AI Act requires providers and deployers of AI systems to take measures to support the development of AI literacy among their staff and other people operating AI systems on their behalf. That obligation became applicable on 2 February 2025.

The wording is worth reading carefully, because it is about understanding rather than paperwork. It covers staff having enough understanding to make informed decisions about deployment, tailored to their technical background and the context of use.

If you sell into Europe or employ people there, onboarding is not only a productivity question. It is part of how you meet that duty, which connects to the wider ground we covered in what the EU AI Act means for marketing automations.

What Should Someone Read on Day One?

Three documents, and none of them should be a prompt library. The team's AI use policy. A short written description of each automated process, including what it does not do. And the list of decisions that always require a human.

That third one is the most valuable and the least common. Write it as a plain list of sentences: nothing goes to a client without a person reading it, no pricing figure comes from a model, no code merges without review.

If you do not have an AI use policy yet, write the one-page version before you hire, not after. We made the argument for that in needing an AI use policy before you need AI tools, and it applies doubly when someone new is joining.

How Do You Teach Judgement About Output Quality?

With examples of failure, not examples of success. Collect the outputs your team rejected and explain why. Ten bad examples with reasons will build better instincts than a hundred good ones.

This is the single practice we would push hardest. Most teams keep their good prompts and throw away the bad results, which is exactly backwards for teaching. The bad results are the curriculum.

Sort them into categories as you go. Confidently wrong facts. Right answer in the wrong format. Correct but useless. Missed the actual question. A newcomer who can name these four has most of the skill already.

Should a New Person Use the Automations Straight Away?

Let them do the job manually first, once. Not for a month, and not for training's sake as a ritual. Once, end to end, so they know what the automation is doing on their behalf.

We think this is worth the lost day. Someone who has written the thing by hand can tell when the generated version is subtly off. Someone who has only ever reviewed output is grading work in a subject they never studied.

After that, put them in the review seat rather than the operator seat. Reviewing output is a lower-risk way to learn the process, and it is where most of the skill lives anyway.

What Should You Actually Write Down?

For each automation: what triggers it, what it produces, who owns it, what it costs roughly, what it explicitly does not handle, and what to do when it fails. Six lines. If it takes three pages you will not keep it current.

The failure line is the one that saves a weekend. Most automation documentation describes the happy path beautifully and says nothing about what a person should do at eleven at night when it stops.

Keep the documentation next to the automation rather than in a separate wiki that drifts. This is the same argument as in documenting AI automations so someone else can run them, seen from the new person's side.

How Do You Stop the Knowledge Living in One Head?

Make the person who built it not be the person who explains it. Have the newcomer write the documentation from what they learn, then have the builder correct it. The gaps show up immediately and they show up in writing.

The structure worth borrowing here comes from the NIST AI Risk Management Framework, which organises its guidance around four functions: govern, map, measure and manage. NIST published it on 26 January 2023 and states it is intended for voluntary use.

You do not need to adopt the framework to use its shape. Govern is your policy and your owners. Map is the written description of what each automation touches. Measure is your evaluation and review. Manage is what you do when something goes wrong. A new person who understands those four layers understands your setup.

What Access Should a New Person Get?

The same as anyone else doing that job, granted the same way, with the same logging. Do not create a special reduced account for the first month unless the role genuinely requires less, because you will forget to upgrade it and they will work around it.

Do make sure the usage is attributable. Most platforms let you break usage down by key. Anthropic's documentation, for example, describes exporting a CSV from the Usage page in the Claude Console to see usage broken down by API key and model. Whatever your provider, set this up before the person starts rather than after a surprising invoice.

Attribution is not surveillance. It is how you answer the question of which automation is costing what, and it is impossible to reconstruct later.

How Long Should This Take?

Expect a month before they are comfortable and a quarter before their judgement is yours. That is slower than people plan for and it is not a sign of a bad hire.

The reason is that the interesting cases arrive slowly. Someone needs to see a model be confidently wrong about something that matters, in real work, with a real deadline. You cannot manufacture that in week one.

What you can do is shorten the gap by handing them the failure archive, the six-line docs, and the list of human-only decisions on day one. Most teams hand over a login and a link to the tool.

What Would We Change About How Most Teams Do This?

Two things. Stop treating prompt sharing as knowledge transfer, and start treating review as the primary job rather than the leftover job.

The prompt is the least durable part of the system. It will be rewritten. The standards a person applies to the output are what persist, and those are almost never onboarded deliberately. They are absorbed, slowly, by whoever happens to sit nearby.

If you want help getting your automations documented well enough that a new person can actually take them over, or building the review process that makes that possible, we are happy to talk it through. Find us at phoenix.studio.