People
Who owns the AI employee
Tobiloba Odejinmi · 18 Mar 2026 · 6 min · 1,017 words
Direct answer
Someone with a name owns the AI employee. Not a Slack channel. Not the vendor. Not “the ops team.” That person can pause it, receives the cases it will not finish, and can explain a miss on Monday without opening six tabs. If you cannot point at that name, you are not ready to go live.
- Ownership is a person, a stop button, and a queue of exceptions.
- IT can run the pipes. The business owner still owns the outcome.
- Escalation is a state with an owner, not a ping that vanishes.
- Write the name down before the first real ticket hits production.
A channel is not an owner
I have watched teams stand up a workflow, drop it into a shared channel, and call that governance. A channel is a place people mute. An owner is a person who gets the exception, can stop the run, and has to live with the outcome.
This is the first question I ask on a call. Not which model. Not which tool. Who gets the cases the system will not finish, and can they pause it without filing a ticket. If the answer is a shrug, we are not picking a process yet. We are finding out whether anyone wants the job.
What the owner actually does
The job is small and specific. They set the scope. They decide what “done” looks like. They take the queue of things the system marked as unsure. They review a sample of the work that looked fine. They can tell a customer, or a clinic, or a hiring manager what happened last Tuesday.
They also decide when to turn it off. That sounds obvious until a model starts failing softly. Soft failure is worse than a crash. The queue still moves. The answers look finished. Only the owner is in a position to notice that the shape of the work changed.
- Name on the workflow, not a rotation that exists only in someone’s head.
- A written stop condition: wrong rate, missing fields, or a tool going dark.
- A place the exceptions land that a person actually opens.
- A weekly look at a sample, including the cases nobody complained about.
IT can run the pipes. They cannot own the outcome.
Engineering should own keys, logs, and whether the connection to the helpdesk still works. That is real work. It is not the same as owning whether a refund was right or a candidate was ranked fairly.
When IT is the only owner, two things happen. The business treats the system as magic. Engineering treats every complaint as a ticket about “the model.” Nobody is looking at the process. BCG’s 2026 work on AI value keeps landing here: the constraint is the operating model, not the next model release. You feel that the first week a named owner is on leave and the queue has nowhere to go.
Escalation is a state, not a mention
I treat escalation as a state on the work item. It has a reason, a payload, an owner, and a clock. It is not a @here in Slack that scrolls away. If you cannot query “what is escalated right now,” you do not have a loop. You have a notification habit.
This is what I mean by escalation-as-state. The AI employee either finishes the job, waits on a tool, or moves the case into a state a person has to clear. Those are the only honest endings. “Posted in the channel” is not an ending. It is how misses hide.
Write the name before the first real Monday
I will not hand over a workflow with the owner still listed as a team. At 10mg, if a clinic cannot open the system, that is not an engineering metric. It is a patient problem. The same rule applies here. If the AI employee writes the wrong note on a lead, someone has to be able to say why without a forensic project.
Put the name in the runbook. Put the backup name next to it. Put the stop condition in the same paragraph. Then run one week where that person actually takes the exceptions. If they cannot do the job in a normal week, the workflow is not ready. The model is not the thing that failed. The ownership design did.
What I refuse to leave fuzzy
Who can pause it. Where exceptions go. How a miss gets explained to a human being who did not build the system. Those three answers have to fit on one page. If they do not, you are not buying speed. You are buying a future incident with no narrator.
IBM still puts the share of frontier firms at about 9 percent. The rest are running tools and pilots. The difference I see is rarely talent. It is whether a person with a calendar will admit the workflow is theirs after the demo glow wears off.
Questions people ask
Who should own an AI employee?
The person who already owns the process. Support owns the support workflow. Hiring owns the screen. Engineering can keep the connections healthy. They do not own whether a customer got the right answer.
Can IT own it?
They can own uptime, keys, and logs. They should not own whether the work is correct. That split is how you get a system nobody will pause when it starts inventing fields.
What if the vendor built it?
The vendor can fix a bug. They cannot sit in your queue at 9am. If the only person who understands a miss is on another company’s Slack, you bought a dependency, not an employee.
Does the owner need to write code?
No. They need to read a runbook, judge an exception, and know who to call when the logs look wrong. If the runbook requires the original engineer, ownership is still sitting in that engineer’s head.
What happens if nobody wants to own it?
Do not ship. A process with no owner will not get one after it starts making quiet mistakes. That is how you get a silent miss and a customer who found it first.
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.
