A few years ago I started using a word in client work that made people pause: e-mployee. I meant it precisely. Not a chatbot, not an "AI tool," not a copilot bolted onto someone's existing role — but an AI worker that holds a real seat on the team. It owns a defined output. It answers to a named human. It is managed, reviewed, and held to a standard, the way you would manage a person. I wrote the idea up formally as The E-mployee Doctrine, archived with a permanent DOI so it could be cited and built on.
The word that matters just as much is the one on the other side of the relationship: e-mployer. If an e-mployee is an AI worker with a seat, an e-mployer is the human who manages that seat. That role barely existed two years ago. Today it is becoming the single most decisive skill in an AI-native organization — and almost nobody is being trained for it. This is the playbook I give the leaders I advise.
Stop bolting AI onto jobs. Give it a seat.
The default move is to take an existing job and add AI to it. The person stays the same; they just get a faster tool. This feels safe and changes almost nothing. The e-mployer move is different: you ask what output the team needs, and you assign that output to an e-mployee with a clear boundary around it. The AI does not assist a role — it holds one. That reframing is what separates organizations that compound from organizations that merely accelerate.
The five rules of structuring a team around e-mployees
When I help a team build around AI workers, the structure always comes down to five rules. None of them are about which model you use.
- One owned output per e-mployee. Give each AI worker a single, nameable thing it is responsible for — the weekly competitive brief, the first-pass support reply, the reconciliation report. Diffuse responsibility is how AI initiatives quietly die — the NIST AI Risk Management Framework makes the same point at the organizational level, stating that "organizations need to establish and maintain the appropriate accountability mechanisms, roles and responsibilities, culture, and incentive structures for risk management to be effective."
- A named human supervisor. Every e-mployee reports to a person who notices the day its quality drops — not at the quarterly review. No supervisor, no seat.
- An explicit failure protocol. Decide in advance what happens the first time the e-mployee is confidently wrong. The teams that survive have already rehearsed the failure; the ones that don't get surprised by it in production. NIST's own risk framework calls this out as its own subcategory: "contingency processes are in place to handle failures or incidents in third-party data or AI systems deemed to be high-risk" (GOVERN 6.2) — a failure protocol is not optional caution, it is what the standard expects to already exist.
- A refresh cadence for inputs. Every AI worker depends on context, data, or instructions that go stale. Someone must own the refresh, or the e-mployee degrades on a schedule nobody is watching.
- A review ritual, not a launch. Treat the e-mployee's work the way you treat a person's: reviewed regularly, given feedback, promoted to more scope when it earns it. Management is the work, not the setup.
An e-mployee without an e-mployer is not automation. It is an unmanaged risk with a login.
What makes a good e-mployer
A good e-mployer is not the most technical person in the room. They are the best manager in the room. They write clear briefs, set sharp boundaries, give specific feedback, and take accountability for what their e-mployees produce. The skill transfers directly from managing people — which is why the leaders who adapt fastest are often experienced managers, not the engineers. The hard part was never the model. It was the willingness to manage something new as if it were a member of staff.
Why this matters more in MENA than anywhere
In Lebanon and across the region, the talent constraint is real and the economic pressure is relentless. The organizations I work with cannot out-hire their problems. The e-mployee model gives a small team the leverage of a much larger one — but only if it is managed well. That is the work my team at Webspot does with organizations across the region: not selling them a tool, but helping them build the e-mployer discipline that makes AI workers durable. It is also the model I run my own operation on — my AI partner, Brian, is an e-mployee in exactly this sense, with owned outputs and a standard to meet.
If you want the full framework — the definitions, the doctrine, and the citation — it lives at jonahtebaa.com/e-mployees. But you do not need to read the doctrine to start. You need to pick one output, assign it to one e-mployee, name one supervisor, and decide what happens when it fails. Do that well, once, and you will understand the rest. The future of work is not humans versus AI. It is e-mployers who know how to manage e-mployees — and everyone else.
