People
Slack, email, and the AI employee
Tobiloba Odejinmi · 19 Aug 2026 · 6 min · 975 words
Direct answer
Put the AI employee where the work already is. If that is Slack, it is a queue with permissions, not a mascot. If that is email, it drafts or files in the inbox people already search. Do not add a third place to check. And do not let chat be the last step on money, a hire, or a legal promise.
- Meet the pile in Slack or email. Do not invent a tab.
- Slack is a queue. A personality is optional and usually a distraction.
- Permissions are part of the job description. Bots are greedy by default.
- One thread, one owner, one log — or you will lose the miss.
Meet people in the tools they already open
I will not ask a support lead to live in a new console so my workflow looks like a platform. Zeeh grew because other companies could plug in before lunch. The same test applies inside your company. If the AI employee needs a new login and a new religion, it will die in procurement, or it will die on Tuesday when nobody opens the tab.
Find the pile. Inbox, helpdesk, ATS, Slack channel that already is the helpdesk. That is the workplace. We connect there. The week is for that connection, not for a tour of a chat product with your logo on it.
Slack is a queue, not a personality
Give the workflow a name people can search. Do not give it a joke persona that makes serious misses sound cute. When a case is escalated, the thread should show the reason and a link to the payload. When it is done, the record should already exist somewhere that is not Slack.
A channel is a terrible system of record and a decent notification surface. Use it as the second thing. I have watched teams lose a decision because the thread scrolled and the guest left. Escalation-as-state still applies. If you cannot list what is waiting, Slack ate the state.
Email still runs the company
A lot of the real work is still a mailbox. Sales follow-up. Vendor noise. The customer who will not use your portal. An AI employee that cannot draft in that mailbox is skipping the job. An AI employee that sends from that mailbox on day one is skipping the fear that keeps you honest.
Draft, file, tag, escalate. Those are good first verbs. Send is a verb you allow only after the owner has seen a week of drafts and the “never do” list includes promises. I still write the code. I still sit in the reviews. I will not hide a send button behind a shrug.
What never belongs in chat
Money movement. Offer letters. Health details. Secrets. Anything a regulator would ask to see in a proper log. You can notify in Slack that a case needs a person. You do not complete those cases in Slack. Complete them in the system that already knows how to retain and permission the record.
This is boring on purpose. Hiring law does not care that the ranking happened in a private DM. NYC LL144 and the EU AI Act care whether an automated tool substantially assisted a decision, and whether you can show oversight. A disappearing thread is the opposite of oversight.
Permissions and the quiet leak
A bot invited to a workspace will see more than the job. Scope it. One channel, one mailbox, one helpdesk view. Write the scope in the job description. Review it when someone says “just add it to #general so it has context.” Context is how you leak a salary thread into a support draft.
I treat permissions like API keys. Least access. A name on the integration. A way to revoke it at 2am. If only one engineer can revoke it, you are back to the diligence problem: one person understands production. That is a risk, not a flex.
One thread, one owner, one log
When the AI employee posts, it should be obvious who owns the next action if a person is needed. When it is silent, the log should still show the run. When it is wrong, you should not be reconstructing the inputs from memory and a screenshot.
That is the whole design. Slack and email are doors. The employee is the job behind the door. If you remember one thing, remember this: a new tab is how the work stays with the people you were trying to relieve. Put the employee in the queue they already hate, then take the first pass off their hands.
Questions people ask
Should the AI employee live in Slack?
If the team already runs the process there, yes. If Slack is just where people complain about the process, no. Put it in the system of record and let Slack notify. Do not make Slack the record unless it already is.
Can it send email for us?
It can draft from day one. Sending is a later permission. I want a week of drafts a person still hits send on before we let it talk to customers alone, and never alone on money or legal language.
What should never happen in a channel?
Refunds, offer letters, medical detail, credentials, and anything you would not paste into a room with guests. Channels have guests. Threads get exported. Assume a screenshot.
How do we keep an audit trail in Slack?
Write the decision back to the system of record. Use Slack as the surface. If the only copy of a decision is a thread, you will lose it the week someone changes the retention policy.
Do we need a custom Slack app?
Only if the job needs it. A lot of work is “read a channel or a ticket, write a draft, escalate.” Start there. A custom app is a product. Do not build one to avoid naming the owner.
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.
