What an AI employee actually is

What is an AI employee, in operational terms?

I use the word employee on purpose. A tool waits for a click. An employee has a shift. It has a pile of work that arrives whether anyone is watching the demo. It has a way to say it is done, and a way to say it is not sure.

In practice that means five things you can write on one page. A name. A single process. A queue of cases. A policy that is not a vibe. A log that a stranger can read at 2am. If any of those are missing, you are still in prototype land.

I run engineering at 10mg Health. We serve more than 6,000 providers and have put out $3.4 million in loans. Nobody there cares if a model is clever. They care if a pharmacist can finish a path, and if a miss has a name next to it. That is the standard I use when I talk about hiring an AI employee.

The job title is a reminder. Software that sits in a tab is a product. Software that takes work off a person and can be wrong in public is labor. Treat it like labor. Give it a manager.

What does a day of work look like?

Work arrives. A form, a ticket, a document, a callback that did not happen. The system reads the inputs it is allowed to read. It applies the steps you wrote. It writes the fields a downstream system needs. Then it either closes the case or it stops.

Stopping is the job as much as finishing. A good AI employee knows the edge of its authority. Refunds, medical advice, legal language, and anything that changes a person's money or health should hit a person. The system can prepare the file. It should not stamp the decision.

At the end of the day you should be able to answer three questions without a slide. How many cases moved. How many a person had to take. Which misses would embarrass you if a customer called. If you need a data team to find those numbers, the log is not a log. It is a graveyard of tokens.

• Intake: the case hits a queue, not a chat window someone might open.
• Action: the system follows written steps and fills a shape you can check.
• Record: every close and every stop has a reason a person can read.
• Handoff: the person gets working state, not a paste of the whole thread.

What is not an AI employee?

A chatbot with a friendly name is not an employee. It does not own a queue. It does not close work while you sleep. It answers, then it waits. That can still be useful. It is a different hire.

A copilot is not an employee either. A copilot sits next to a person and makes the next sentence faster. The person still owns the queue. If the person is on leave, the copilot does not come in. I will write about that split in another piece. The short version: helper and worker are not the same budget line.

RPA is not an employee. It is a recorded hand. When the button moves, the hand misses. When the PDF is ugly, the hand freezes. An AI employee can read messy input. That does not make it magic. It makes the failure mode different. You still need a person for the cases that are not in the policy.

A platform is the opposite of this hire. A platform wants every team, every workflow, a new login, a steering committee. I have watched that die in procurement. One process is a thing you can finish. A platform is a thing you can announce.

Who is accountable when it is wrong?

Someone with a calendar and a phone number. Not 'the AI'. Not 'the vendor'. Not a Slack channel that goes quiet on Friday. If a clinic gets a bad decision, I want a person who can say what the system saw and what the policy said.

This is why I care about structured output. If the system can invent a field, you will spend the week arguing with a paragraph. If it has to return a shape you defined, you can see the miss. I learned that doing document review, not from a keynote.

Accountability also means you accept a miss rate. You do not get zero. You get a rate you can explain, and a path to correct the case before it becomes a complaint. If your plan is 'the model will get better', you do not have a plan. You have hope.

What do you write down before you hire one?

Write the process as if a new hire starts on Monday and you will be in a market. Inputs. Steps. Systems they may touch. Cases they must not close. The name of the person who takes those cases. How long a case may sit before someone looks.

If that document does not exist, do not hire yet. You will automate folklore. Folklore does not survive the second week, when the weird case arrives and two people remember two different rules.

I am based in Lagos. A lot of the work I have shipped has been for teams that move money or move patients. Those teams already know this. They write SOPs because a verbal rule is how you lose a license. An AI employee is just another reader of that SOP. If the SOP is thin, the reader will be confidently thin.

How do you know the first month worked?

The pile is smaller. The people who used to do the first pass are doing the exceptions, and they can still go home. Nobody is quietly redoing every case 'just to be sure' unless the miss rate earned that distrust.

You should also know your escalation rate. If everything escalates, you hired a router. If nothing escalates, you are either in a toy process or you have turned the gate off. Research on handoffs in 2026 keeps saying the same thing I have seen in ops: a handoff is a transfer of working state, not a transcript dump. Target something like 10 to 15 percent on a well-scoped queue, and put hard gates on refunds, legal, and medical.

If you want help picking the first process, I do that in a week. One workflow, a written policy, a log, a person on the leftovers. The page is /ai. Book 30 minutes if the process is already real. If it is still a slogan, write the process first. The meeting will be shorter.