Eleven AI roles, no review dates, and one meeting to decide which ones should still exist. That is a composite scene, assembled from patterns I see in my work rather than from any single client: a leadership team looking at an org chart where the AI roles sit neatly in their boxes, and nobody in the room can say when any of them was last reviewed. Someone asks whether a particular role is still needed. The silence that follows is the subject of this piece.
The question that breaks it open is a simple one. If this e-mployee did not exist today, would we create the role? I use the word e-mployee for an AI worker treated as a member of the team, with a defined role, a human it reports to and work it is accountable for completing. Once you hold that definition, a second fact follows quickly: team members have lifecycles. Their roles change, move and end. An e-mployee role that cannot do any of those things is a permanent fixture on the chart, and permanent fixtures are how teams get crowded.
Why e-mployee roles never get reviewed
A human role comes with a calendar attached. There is a probation period, an annual appraisal, a succession conversation when someone leaves, and a budget cycle in which every headcount line is asked to justify itself. None of this is sentimental. It is how a team notices that a job has drifted from what was written down.
An e-mployee role usually gets a launch and a dashboard instead. The launch is a moment of attention. The dashboard is a standing glance at throughput. Neither one asks whether the role is the right shape for the team as it stands now. I covered how to write the role down at the start in my piece on how to write a job description for an AI e-mployee; this article begins where that one stops, months into live operation, when the description is still in a drawer and the work has moved on.
Three things keep the review from happening. First, nothing in the calendar forces it. Second, changes to the role arrive as small favours: one more inbox to watch, one more report to format. Each is called tuning, and none is recorded as a change of job. Third, ending a role feels like admitting a mistake, so teams postpone the conversation until a failure makes it unavoidable. By then the review is also an incident review, which is the worst moment to be making a calm decision about team design.
The four outcomes of a role review
I ask leaders to commit, before any review begins, that it can end in only four ways. Having four named outcomes matters because it makes the harder ones normal. When retirement is one of four listed choices, choosing it is an administrative act.
Keep. The purpose, the scope and the results all still match what the role was created to do. The signal is dull in the best way: the output is used, the people who use it have not asked for changes, and a sample of recent work looks like the job description. Keeping is a decision, and it earns a new review date.
Re-scope. The role has drifted, or the work around it has changed. The signal is a gap between what the role says and what the e-mployee actually does, or a human teammate who has started quietly working around it. Rewrite the role, not the tool. Decide which duties stay, which move to someone else, and which were never meant to be there. A re-scope usually changes the humans’ jobs too: a person may gain a duty they had quietly handed over, and another may be freed from checking work that no longer needs checking.
Reassign. The role is sound but sits in the wrong place. The signal is that most of its output is consumed by a different team, or that the manager it reports to no longer owns the process it serves. Moving it to another team, with a named human owner there, often fixes problems that no amount of adjustment inside the original team could.
Retire. The work no longer exists, is better done another way, or the cost of the role, in review time and rework, exceeds what it contributes. The signal is a role that people defend by describing what it once did. Retirement is cheap only when it was planned: the inputs, the outputs and the person who takes the work back have to be written down in advance, because they are impossible to reconstruct under pressure.
The six-question quarterly review
The review itself should take under an hour per role. I use six questions, in this order, because the early ones tend to settle the later ones.
- Would we create this role today, with what we know now? If the honest answer is no, start the conversation from re-scope or retire rather than keep.
- Is the written scope still what the e-mployee actually does? Compare the role description with a sample of recent work and flag any duties added informally.
- Who on the human team depends on its output, and have their needs changed? Ask them directly. The consumer of the work often knows the role has drifted before its owner does.
- Does any other role, human or e-mployee, now overlap with it?
- What would it take to hand the work back to a person, and does that person still exist and still know the work? Write the hand-back path now, while the answer is still easy to find.
- What does another quarter cost, in review time and rework, compared with what the role delivers? Name the review owner and fix the next review date before the meeting ends.
Who runs it matters less than who attends. I recommend the human manager the role reports to, together with one person from the team that consumes its output. The manager knows the intent; the consumer knows the reality. A review with only one of them tends to confirm whatever that person already believed.
Writing the exit before the entry
The cheapest moment to plan a role’s ending is the day it is created, when nobody is attached to it. On that day I ask for three lines, and only three: the first review date, the retirement trigger, and the hand-back owner. The retirement trigger is a plain sentence such as “if invoice volumes fall below the level where one person could cover the matching by hand.” The hand-back owner is a named person, not a department.
Here is an illustrative composite, not a client case. A finance operations team gives an e-mployee one job: matching supplier invoices against purchase orders. Over several months, because it is already connected to the shared mailbox, it starts sorting supplier emails as well. Nobody decides this. A colleague asks for a favour, it works, and the favour becomes a habit. At the first quarterly review the team compares the role description with a sample of recent work and finds two purposes in one role, with results measured for only one of them.
The outcome is a re-scope into two roles. Invoice matching stays as it was, with a fresh review date. The email sorting is moved into its own role, given its own owner and its own measure, and within one quarter the team sees that the volume is small enough for an accounts clerk to handle in a part of the day. That second role is retired and the work goes back to a named person, using a hand-back note written at the start. The chart gets simpler, and the clerk’s job gains a duty that now has a defined place in it.
One observation from the region where I work most. In smaller firms across Lebanon and the Gulf, one person often carries several functions, and that is precisely why the hand-back path is the first thing to disappear: the person who could take the work back has moved on to three other responsibilities and no longer remembers the detail. Writing the path down on day one is the safeguard, and it costs a paragraph.
Related evidence: Article 26(2) of the EU AI Act requires deployers of high-risk AI systems to assign human oversight to natural persons who have the necessary competence, training and authority, as well as the necessary support — so oversight is assigned to people with the authority to act, not to a department. (Article 26(2) of the EU AI Act)
The UK government's introduction to AI assurance defines AI governance as a range of mechanisms, including laws, regulations, policies, institutions and norms, used to outline processes for making decisions about AI. (the UK government's introduction to AI assurance)
Count the AI roles on your chart, then count the review dates. Adding a role and ending one should feel equally ordinary.
If your team has more AI roles than review dates, let’s talk: https://jonahtebaa.com/
