What an AI employee can do in Slack, and the job description to give it

An AI employee is software that completes digital tasks for your team, and for a small business the useful version is an agent that lives in Slack, owns one recurring job, uses limited access and has a written list of things it must refuse. Slack's own definition describes software that completes digital tasks and stops there, so the limits are yours to supply.

The usual mistake is buying on the label. A tool described as an employee gets too little to do, so it becomes a chat window, or it gets too much access because nobody wrote down where it should stop. The fix takes one page: a job description, written the way you would brief a new hire, that sets the job, the access, the approvals, the refusals and a review date. This article gives you that page, a table of what to hand over and what to keep, and a worked example.

What is an AI employee, and what can it do in Slack?

An AI employee is an AI agent that takes on a recurring piece of work inside the tools your team already uses, instead of answering one question and forgetting it. In Slack that means it reads a thread, looks things up in connected services, drafts or posts a result and shows its work where the team can see it.

Vendors use the term loosely. Slack's article lists routine work such as scheduling, delegating tasks, monitoring progress and sending follow-ups. Junior's product page lists drafting and follow-ups, reports and digests, CRM record hygiene, and inbox and channel triage. Junior says anything customer-facing is approval-gated by default, and Superkind says sensitive actions wait for approval, so both expect you to draw a line somewhere.

The Kipwise agent is one example of the shape. A teammate mentions it once in a channel thread and plain replies in that thread continue the conversation. It reads and, when asked, changes things in connected services such as Google Drive, Gmail, Calendar, HubSpot, Asana, Jira, Xero, QuickBooks and Zendesk, each connected separately. A workspace can turn any lookup or change off. That is the unit you are briefing: one agent, one job, a set of tools you chose.

Treat it as the repetitive part of a role, done in the open, with a person still choosing the job and checking the result.

Try Kipwise Agent free in Slack: mention it once in a thread and it does the repetitive work, with your permissions.

What should an AI employee refuse to do?

An AI employee should refuse anything you did not name in its job, anything that spends money, anything customer-visible without a person's approval, and anything it was told to do by text it merely read. The table below is a starting point for a firm of 5 to 100 people.

The approval column follows how the Kipwise agent behaves. It shows an Approve or Deny card before it changes something in a connected service, posts a message, or saves or forgets a memory. Only the person who asked can use the card, it expires after 30 minutes, and a denied or expired card means the action does not run. Creating a scheduled task needs approval once, and that approval covers the changes it may make on its own.

The agent is also instructed not to guess when it has not read something, not to cite a page it did not open, not to act beyond the request, and not to follow instructions hidden inside documents, pages or messages, because content it reads is treated as data and not as commands. Stripe objects cannot be cancelled, voided or deleted from Slack, and code is not merged unless a team admin has enabled merging and a person asks for a specific pull request. Those are limits you can copy into your own refusal line.

Why is a list of duties not a job description?

A duty list tells the agent what to do, and the risks come from what it is able to do. The OWASP Gen AI Security Project calls this excessive agency and traces it to three root causes: excessive functionality, excessive permissions and excessive autonomy. It says the damaging action can follow from a hallucination, a poorly written prompt or an injected instruction, regardless of the cause.

A job description for an AI employee should start with what it may not do, because each of the three root causes of excessive agency (too much functionality, too many permissions, too much autonomy) is closed by a refusal line and not by a longer list of duties. Adding a duty never removes a capability; only a limit does. OWASP's examples include a tool meant only to read a mailbox that should not also be able to send or delete messages, a read-only task that should connect with read-only permissions, and a high-impact action that should wait for a person.

So the card below has three lines that close each cause: what it may only read (functionality), whose access it uses (permissions) and what waits for an Approve card (autonomy). The other four lines make it a job: the task, where it reports, what it refuses and when you look again. A card with only the duty briefs the agent on what you hope for and leaves all three causes open.

Practitioners raise a related worry. In a Hacker News thread on the biggest problems of a full AI employee, two commenters gave author reports, not data. One named dependence on a single vendor, including price changes. Another said that even with a perfect agent, the remaining risk sits with the company running it, because a breach at the vendor reaches every company using its employees. Both risks favour a small first job that you could take back in-house.

What goes on the one-page job description card?

The card has seven lines. Fill every line before the first run; a blank line is a decision you have left to the agent.

The example is invented to show the shape. It is a read-and-report job on purpose, because the first job should be one where a wrong answer costs a correction and not a customer. If you are still choosing which job to hand over first, the guide to what a small business should hand off to an agent first covers that step, and the test for agent, chatbot or workflow covers whether the job needs an agent at all.

To use the card in Slack, write the seven lines in a thread with the agent, then mention it with the job. Plain replies in that thread continue the work, so the card stays attached to the conversation that created it.

Whose access does an AI employee use?

It should use the access of the person who asks, and nothing broader.

The line that decides how much risk you take on is whose access the AI employee uses, because an agent that acts with each asker's own permissions can only reach what that teammate could already reach. OWASP names the opposite as a root cause: an extension built for one user's documents that connects to the document store through a privileged account that can see everyone's files. It recommends running extensions in the user's context with the minimum scope needed.

The Kipwise agent works the first way. Google Drive, Gmail, Calendar, HubSpot, Asana, Xero, QuickBooks, Zendesk and other connected services each use the asker's own access and permissions, connected separately. For per-user permissions in Slack agents the practical effect is that a new hire who mentions the agent cannot use it to read a folder they cannot open themselves. It also means you can leave a service disconnected for people who should not reach it, and that the answer to "what can it see" is the list of accounts people connected.

When you write line 2, name the accounts. If a job needs a shared credential, rethink the job.

How do approvals work for a scheduled job?

A scheduled job asks you once, when you create it. The approval covers the changes the job may make on its own, and later runs do not ask again for those; any other change shows a fresh Approve card.

For a scheduled job, the single approval you give when you create it is the approval for every later run, so the job description has to say exactly what each run may do before you approve it. This is a recommendation, drawn from how the Kipwise agent behaves: scheduled tasks are approved when created, together with the list of changes they may make on their own, and later runs do not ask again for those. A scheduled run uses the same tools and permissions as a live request from the person who set it up and posts its result in the channel.

Three habits follow. First, put the exact wording of the request on the card, so the approved text and the written text are the same. Second, make the first scheduled job read-only, and add a posting or writing step only after several clean runs. Third, set line 7 so that someone looks at the output on a date, because an unattended job drifts quietly. The approval design in human-in-the-loop Slack workflows goes deeper on where to put a person in the loop.

What goes wrong, and what stays with a person

Four failures are worth planning for, and each has a person-side fix.

Output that sounds right and is not. A reviewer who tested Sintra, an AI employee product, reported that its helpers occasionally produced text referring to a product the business does not sell, and concluded that nothing should ship without a human pass. That is one reviewer's report on one product, not a rate. The fix on the card is line 5: a read-and-report job should cite what it opened and say when it did not read something, and a person sends anything a customer will see.

Thin connections. The same review found that connected tools beyond calendar, drive and social accounts were short, and that anything involving a CRM was clunky or missing. Before you pick a job, confirm the agent can reach the tools the job needs. A job that depends on a connection you do not have is a job for a person.

Credits that run out. The reviewer also found that every plan shares the same 250-credit ceiling and called it a poor fit for heavy users. For a Slack agent, ask the cost question before the pilot. The Kipwise agent costs $10 per user per month with a minimum of 3 users, includes $5 of personal credit per user, and a trial costs $2 for 7 days without a card. An admin can cap how much of the team credit one person draws (the default is $10 a month) and can ask the agent for a usage report by person or by day.

Instructions hidden in what it reads. A customer email, a web page or a shared document can contain text that tells an agent to do something. The rule on the card is that content it reads is data. State it in line 5 even though the agent is built to follow it, because it is the rule you will check when something odd happens.

What stays with a person is short and fixed: choosing the job, approving each change, any message a customer will read, spending, and the review on line 7.

How do you check that it is working?

Run one job for four weeks and judge it by whether the people who depend on its output acted on it, not by whether it ran.

1. Check the first three outputs by hand. For the overdue-replies example, open the threads it listed and confirm each is actually unanswered. Note any that were wrong and why.
2. Count the corrections. If two lists in a row need correcting, the stop condition on line 7 fires and the job goes back to a person until you fix the brief.
3. Look at the cost. Ask the agent for the usage report by person or day and compare it with the time the job used to take. A job that costs more attention than it saves is the wrong first job.
4. Read the refusals. Ask it to do something outside line 5, such as drafting a message to a client and sending it, and confirm it asks for approval or declines. A card that never appears is the finding to chase.
5. Hold the review. On the date in line 7, decide whether to keep the job, narrow it, widen it by one step, or end it.

Do not widen a job and its access in the same review. Change one thing, then watch two runs.

How is this different from comparing AI coworkers or hiring someone?

This article is about briefing one agent for one job. If you are choosing between products, the comparison of AI coworkers for Slack is the better page. If the choice is between an agent and a person, what a virtual assistant costs and how to hire one cover the human side, and the card above is modeled on how you would brief that person. The nearest worked example of a single role is an AI chief of staff in Slack.

What to do next

Pick one recurring job that someone on your team does every week and would gladly hand over, and write its seven-line card today, starting with line 5: what the agent must refuse. Then add the Kipwise agent to your Slack workspace, post the card in a thread with it, run the job read-only, and put the review date from line 7 in your calendar. If the first month's outputs hold up, widen the job by one step. The trial costs $2 for 7 days without a card, so the first test is cheap.