AI agent vs chatbot for a small team: a four question test for each recurring job

If you run a Slack-first firm of 15 to 50 people, every vendor now calls its product an agent, so the AI agent vs chatbot choice often gets made by label. That goes wrong in two directions. A chatbot gets a job that ends in a change somewhere else, so the bot answers and a person still does the work. Or an agent gets a job with fixed steps, which adds cost, delay and a chance of a wrong action. Slack's own comparison warns about both mistakes. Below are four questions to ask of each recurring job, a table that sorts five jobs in about ten minutes, and the third option most definitions leave out.

The short answer

Take one recurring internal job at a time and ask:

1. Does the job end with an answer, or with a change in another tool or a message sent?
2. Are the steps the same every time?
3. What is the worst thing a wrong run does, and can anyone undo it?
4. Who approves it?

Then apply four rules:

• Ends with an answer only: a chatbot, or an agent that searches, is enough.
• Ends with a change, same steps every time: a fixed workflow.
• Ends with a change, different context every time: an agent, with the job's owner approving anything that changes a tool or sends a message.
• A wrong run is costly, cannot be undone and nobody can approve it: it stays with a person.

Why the label does not help

The vendor definitions agree on the core difference. A chatbot responds within a defined scope, and an agent chooses tools and acts across systems to reach a goal, as Make's comparison puts it. Anthropic draws the same line with a useful third term: workflows are systems where the steps follow a predefined path, while agents decide their own steps and tool use. Slack's developer documentation describes agents as autonomous, goal-oriented apps that can reason, use tools and plan actions, and it lists workflow automations as a separate way to bring AI into Slack.

Two things follow. First, "chatbot or agent" leaves out a category. Anthropic and Make both treat fixed-step automation separately, and Make places it on a spectrum from deterministic automation through AI inside a fixed scenario to fully agentic behavior. Second, the labels describe architecture and say nothing about intelligence. Make notes that putting a strong language model behind a chat widget does not turn it into an agent, and that many agents have a chat front end, so the interface you talk to tells you little.

Most of the pages written for small businesses use website chat, order status and lead capture as their examples. That is a customer-facing frame. Your problem is the recurring work inside the firm: the rate card nobody can find, the Monday reminder, the overdue invoice, the weekly client update. The four questions are built for that.

The four questions, one at a time

Question 1: does the job end with an answer or with a change?

A chatbot works best when the interaction ends with information: it explains a policy, finds a document or points to the right page. Make says the line is crossed when the request needs access, decision logic and execution, for example updating a shipment rather than describing shipping policy.

Count the handoff after the answer: if a person still has to open another tool and make a change once the bot has replied, the job needed more than a chatbot. Small Business Expo makes the same point in a customer setting, where the customer gets an answer and an employee then updates the CRM or processes the refund by hand. Inside a firm the handoff is just as easy to miss because it is quiet: nobody logs the moment they read the bot's answer and retyped it into the accounting tool. Count those retypings for a week and you have your list of jobs that are not chatbot jobs.

Question 2: are the steps the same every time?

If you can write the steps on a card and they never change, you do not need a model deciding what to do next. Anthropic recommends finding the simplest solution possible and adding complexity only when needed, and notes that agentic systems often trade latency and cost for better task performance. Workflows, in its words, offer predictability and consistency for well-defined tasks.

Most recurring internal jobs have the same steps every time, so the right tool is often a fixed workflow rather than either a chatbot or an agent. A Monday reminder to the same channel, a weekly summary pulled from the same sources and a form that always lands in the same place all have fixed steps. A model can still write the summary sentence inside the workflow. What matters is that the sequence is not the model's decision.

The reverse also holds. If the inputs vary, if the right next step depends on what the last tool returned, or if each case needs a judgment a person would make, a fixed workflow breaks at the first unusual case. Make describes the strong agent cases as the ones where a person reads an input, opens a second application, looks up a record and acts in a third. If that is your coordinator's day, that is agent territory.

Question 3: what does a wrong run cost?

Make describes the failure modes as different in kind. A chatbot usually fails by not knowing enough, while an agent may have enough context to act without enough certainty to act correctly. A wrong chatbot answer wastes a minute. A wrong agent action might send an email, change a record or post to a client channel. Small Business Expo gives examples such as an incorrect refund or a wrong CRM update.

So decide how much freedom a job gets by what a wrong run costs and whether anyone can undo it, not by how capable the tool sounds. Put it on a simple scale:

• Cheap and reversible (a wrong lookup, a draft nobody has sent): let it run and spot check.
• Costly but reversible (a wrong status in a project board, a record you can restore): allow it with approval, and check the first runs closely.
• Costly and not reversible (money moved, a message sent to a client, something deleted): a person decides every time, whatever the tool.

Question 4: who approves?

Make recommends approval checkpoints, narrow tool permissions and observability for agents, and Small Business Expo recommends human-in-the-loop checkpoints for high stakes actions. For a small firm the practical version is shorter: name one person per job, and make it the person who owns the outcome, not whoever happens to be in the thread. The agent must never approve its own action.

In a Slack thread that approval has to be quick or it will be skipped. A co-founder of an agent product that runs in Slack reported on Hacker News that approvals there end up as button clicks and progress shows up as emoji reactions, because Slack limits what you can build. That is a vendor's account of one product and no general rule, but it matches what makes approval usable: one tap by the right person, in the same thread as the request.

Sort five jobs: a worked example

The table below is made up for illustration, for a 25 person consulting firm. Swap in your own five jobs.

Three of the five jobs go to a workflow or a person, one is an answer and only one is clearly an agent job. That ratio is typical for internal work, and it is why starting with "which kind of job is this" saves money.

Three threads in Slack

The agent in the next two examples is the Kipwise agent. What it does here comes from Kipwise's own documentation, not from the vendor pages above.

The rate card (answer only). Someone asks in a channel where the latest rate card is. The agent is mentioned once, and plain replies in that thread continue the conversation. It finds the document using the asker's own access to the connected file tool and replies with the link. No approval is needed because nothing changes. The check is whether the person then had to do anything else. If not, a chatbot-grade job was done by the right tool.

The Monday reminder (fixed steps). The text and the channel are the same every week. The Kipwise agent can run a request on a schedule in plain language, and creating a scheduled task needs approval once. Later runs do not ask again, which is exactly why this belongs to a job with fixed steps: you approve the sequence once and it repeats. If the content of the reminder starts to depend on judgment, retire the schedule and treat it as a different job.

The overdue invoice (variable context, a change elsewhere). The account owner asks the agent what a client still owes. With Xero or QuickBooks connected, the agent reads the outstanding balance and the invoice using the owner's own access. With Gmail connected, it then writes a draft reminder in the owner's Drafts. Before anything is sent, the agent shows an Approve or Deny card with the recipient, subject and message preview, and only the person who asked can use it. The card expires after 30 minutes, and if it is denied or expires the action does not run. Say the owner spots that the client paid yesterday (a made-up case) and denies the card. That is the approval step doing its job.

On the same invoice job, a chatbot would have told the owner the balance and stopped, leaving the retyping to a person. A fixed workflow would have sent the same reminder to every client, including the one who paid yesterday.

What a wrong choice costs in each direction

A chatbot where an agent was needed. You pay for a tool that answers and a person who acts. The cost is hidden in the handoff, so it never shows up as a line item. The signal is repeated retyping of the bot's answers into other tools.

An agent where a workflow was enough. You pay more per run and accept variation you did not need. Small Business Expo notes that an agent's single request can trigger far more model calls than a chatbot reply, with a higher cost per task and more delay. That claim comes from a vendor article on small business, so treat the exact ratio as indicative. The direction is consistent with Anthropic's warning about latency and cost. The worse cost is a plausible wrong action on a job that never needed judgment.

A workflow where an agent was needed. The workflow breaks, or worse, runs on the wrong input. Someone then fixes the edge cases by hand and the saving disappears.

An agent with no approval where a wrong run is costly. This is the expensive one. If you are unsure, use the approval gate first and loosen it later. Our guide to adding human approval to AI agent workflows in Slack covers where the gate goes.

Handle failure and edge cases

• The job changes shape. A reminder starts needing judgment, or an agent job becomes routine. Re-run the four questions whenever the job's owner says the job has changed, because fixed steps need checking each time.
• The approver is away. Decide in advance who covers. An approval card that expires means the action did not run, which is the safe default, but a job that always expires is not a working job.
• The tool you need is not connected. An agent can only use the tools it is connected to and permitted to use. If your system of record is not available to it, the job falls back to a person or a workflow that you build elsewhere. Our comparison of Slack Workflow Builder and an AI agent goes through that connector question in more detail.
• Everyone approves without reading. If approvals feel like noise, your gate is on too many low-risk actions. Move cheap reversible jobs out from behind it so that the cards left are the ones that need a look.
• Scheduled runs after a one-time approval. A schedule keeps running on the original approval. Review your scheduled jobs on a set day each month and cancel the ones whose steps or recipients have drifted.

Verify it works

Run a two week pilot on one job per kind, not all five at once. For each, measure:

• Handoffs per run. How many times a person still had to retype, forward or fix something after the tool finished. For a chatbot job this should be zero; if it is not, the job is mis-sorted.
• Approval outcomes. Approved, denied and expired, counted per job. A high denial rate means the agent lacks context; a high expiry rate means the wrong approver or too many cards.
• Reruns and corrections. Jobs where someone redid the work. For a fixed workflow this should approach zero.
• Time from request to done, compared with how long the coordinator or you took.

If an agent job passes with few denials and no corrections after two weeks, leave it. If it keeps getting denied for the same reason, the cause is usually a missing connection or an unclear rule, so fix that before concluding that agents do not work for you. For ideas on what to hand over next, see which jobs to hand off to an AI agent first, and for setting up the first one, how to build an AI agent for a small team.

What to do next

Write down five recurring jobs your team does by hand this month and run each through the four questions in a Slack thread, with the person who owns each job answering question 3 and question 4. Pick only the one that came out as an agent job with a clear approver, and try it first. The Kipwise agent costs $10 per user per month with a minimum of 3 users, and a trial is available when you install it; the pricing page has the current terms. Ask the agent about that one job in a thread, and read the Approve card before you approve.