Foundations
AI employee glossary
Tobiloba Odejinmi · 5 Sept 2026 · 8 min · 1,795 words
Direct answer
An AI employee is a named workflow that does a real job inside your tools, with an owner, a stop condition, and a path to a person. It is not a chatbot you open when you remember. The rest of this page defines the words I actually use when I scope that job: agent, copilot, RPA, RAG, human-in-the-loop, escalation, workflow, structured output, evaluation, monitoring, and handover.
- Use “AI employee” for a owned job in production, not a chat tab.
- Agent, copilot, and RPA are different shapes. Do not mix the invoices.
- HITL only counts if escalation is a state you can list.
- Handover is part of the product. If nobody can run it next month, you shipped a demo.
AI employee
An AI employee is a production workflow that does a job a person used to do with their hands: first-pass support, a hiring screen, a follow-up note, a document pull, an inbound call that books or routes. It lives in the tools you already open. It has a name, an owner, and a written “never do” list.
I use the phrase when the work runs without someone prompting it every time. A person still owns exceptions. A person can pause it. If those things are missing, call it a demo or a copilot. Do not call it an employee. Employees have managers. Demos have decks.
The job is usually narrower than the marketing. One process. A counted pile. A week to map, build, and hand over. I will not pretend a chat window is a colleague. A colleague has a queue and someone who notices when the queue goes strange.
IBM still describes only about 9 percent of firms as frontier. Most companies have tools. Fewer have a named job like this, with logs and a Monday owner. That gap is what this glossary is for. Shared words, so the meeting is about the work.
Agent, copilot, and RPA
An agent is software that can take a sequence of steps toward a goal, usually by calling tools. It plans a little. It acts. It should stop. Anthropic’s 2026 agents report is clearest on the useful ones: bounded tasks, explicit tools, evaluation, and a path back to a person. An unbounded agent is a story you tell before the first bill from a looping tool call.
A copilot sits in the interface a person already uses and helps when asked. It drafts, suggests, summarizes. The person is still the one who hits send. Copilots are good at work that should not run unattended. They are a poor substitute when the pile arrives at 2am and nobody is there to ask.
RPA, robotic process automation, clicks through old interfaces the way a person would. It is brittle and still useful when there is no API. It does not understand a document. It does not judge a ticket. If your “AI employee” is mostly RPA with a language model glued on top, say that. The failure modes are different. RPA breaks when a button moves. A model breaks when it sounds sure and the source was wrong.
I will use an agent when the job needs a few tool calls and a stop condition. I will use a copilot when a person must remain the last click. I will use RPA only when the door into a system is a screen, not an API. Mixing the three in one sentence is how buyers get an invoice they cannot explain.
RAG
RAG means the system retrieves from your sources before it generates an answer. Policies, tickets, product docs, the last note on the account. The generation step is not supposed to invent the missing page. When retrieval is empty, the honest output is an escalation, not a confident paragraph.
People treat RAG like a brain transplant. It is a search step with a writer attached. If the index is stale, if the wrong PDF ranks first, if two policies disagree and nobody marked a winner, the employee will sound like your company and still be wrong. That is not a model personality problem. That is a library problem.
I want sources you can point at. A chunk ID, a document title, a ticket number. If the reviewer cannot see what was retrieved, they are marking prose, not work. At SmartComply the structured fields mattered more than the essay. RAG should feed those fields, not hide behind them.
Use RAG when the job depends on your text. Skip the ceremony when the job is “look up these three fields in the CRM and write the next step.” Not every AI employee needs a vector store. Some need a boring query and a schema.
HITL and escalation
HITL, human-in-the-loop, means a person is a required step for some class of work. Not a spectator. The system cannot mark those cases done. The person sees the original payload, not a summary that already decided the ending.
Escalation is how HITL becomes real. I treat it as a state: reason, owner, timestamp, payload, clock. You can ask the system what is escalated. You can see what is aging. You can see who is holding it. A ping in a channel is not HITL. It is a hope that someone was looking.
Escalation-as-state also keeps the miss explainable. When a model is wrong, the case does not vanish into a retry. It waits. A person corrects it. You write the rule. That is the same discipline I want when a payment path fails. The slide about uptime does not help. The person who knows the path does.
Design the easy button to be “send back,” not “accept.” If accepting is one click and escalating is a form, you trained the team to rubber-stamp. HITL dies that way, quietly, while the dashboard still says adoption is high.
Workflow and structured output
A workflow is the written path: trigger, steps, tools, outputs, and the states in between. Done, waiting, escalated. If you cannot draw those states, you have a script, not a workflow. Scripts are fine for a demo. They are how production surprises you.
Structured output means the system must return a shape you can check. Status, amount, next action, confidence that is a field and not a vibe. A paragraph can be a field inside the shape. A paragraph cannot be the only interface if you need to route, measure, or stop.
I use schemas for this. Zod is unglamorous. It is also how you stop a model from inventing a column. When the shape fails, the case escalates. That single rule removes a surprising amount of theatre. The model can still write. It cannot declare victory without filling the form.
Put the workflow on one page next to the job description. Same owner. Same “never do” list. If the workflow and the JD disagree, the workflow will win in production and the JD will win in the sales call. That split is how you get two truths and one incident.
Evaluation and monitoring
Evaluation is how you decide the workflow is allowed to run. A set of real cases with an expected shape. Not a vibe check on a happy demo. You run the set before go-live and again when you change a prompt, a model, or the retrieval source. If you cannot fail the set, you cannot trust a pass.
Monitoring is what you watch after it is live. Can a ticket start. Does a decision come back. Do escalations age. Did the required fields start coming back empty. I watch the paths a stranger will shout about. Pretty dashboards that show token counts are how teams avoid looking at the work.
BCG’s 2026 writing on AI value keeps returning to operating discipline. Evaluation is that discipline before the customer sees it. Monitoring is that discipline after. Neither is a model benchmark you saw on Twitter. Both are about your pile, your fields, your miss rate.
Write a stop condition next to the monitors. Wrong rate, schema failures, a tool that went dark. The owner should be able to pause without a war room. If pausing needs a deploy, you built a monument, not an employee.
Handover
Handover is the last day of the week, and it is part of the product. You get the docs, the monitoring, the owner, and a call with someone who can explain it. If only I understand production, that is a risk I already learned not to sell. Buyers ask this. Tired teams ask this at 2am.
A handover a person can use is short. How to pause. Where logs live. What a good case looks like. What an escalation looks like. Who to call when the database is the question. I have sat in diligence where nobody could explain the old system. Fancy slides do not survive that meeting.
Handover also includes the training loop. The three example cases. The “never do” list. The weekly sample. If those stay in my notebook, I did not hand the employee over. I rented you a week of my head.
When I say the week ends with something running, I mean this. Not a sandbox link. A job in the tools you already use, with a name on it, and a page a backup owner can read without me on the call. That is the definition I will stand behind. The rest of the glossary exists so we can get to that page without arguing about words.
Questions people ask
What is an AI employee?
A system that performs a defined job in your existing tools, with a named owner, logs, and a way to escalate to a person. It has a job description. It can be paused. It is measured on the work, not on whether someone opened a chat box.
What is the difference between an AI employee and a copilot?
A copilot sits next to a person and waits to be asked. An AI employee runs a queue you already have. You can have both. They are not the same purchase.
What does HITL mean?
Human-in-the-loop means a person still sees the cases that need judgment, and the system cannot silently finish those cases. If the human only gets a weekly dashboard, they are not in the loop. They are in a report.
What is RAG in this context?
Retrieval-augmented generation: the system fetches your documents or records before it writes. It is how you keep answers tied to a source. It is not magic memory. If retrieval returns the wrong PDF, the prose will be fluent and wrong.
What is a handover?
The moment the workflow is yours. Docs a tired person can follow, monitoring, the owner, the stop condition, and someone who can explain the database. If handover is a slide, it did not happen.
Written by
Tobiloba Odejinmi
Head of Engineering at 10mg Health. I have run engineering at Zeeh Africa and sold Insurpass and Shopl. I still write the code. If you have one process that still runs on people copying things, we can look at it in thirty minutes.
