You would not hire a person to add up a column of numbers. A calculator does it faster, never gets tired and never rounds the wrong way. You would not hire a person to collect the same five fields from every visitor either. A form does that, and a form never forgets to ask for the postcode.
People are worth hiring for the work a calculator and a form cannot do: reading what someone actually meant, answering in plain language, deciding which of several things to do next. The same is true of an AI employee. It is good at the language part of a job. Put it on work that has no language in it, or on work where nobody has decided what “good” looks like, and you pay for judgement you did not need, or for judgement you cannot check.
We build AI employees, so it is fair to ask why we would write this. The answer is simple: a project that should never have started is the most expensive kind. If you can rule your idea out in ten minutes with this list, that is better for both of us than finding out in month three.
When a form or a plain automation is better
If the job has fixed steps, no free-form language and exact numbers, you probably do not need an AI employee at all. A form, a spreadsheet rule or a short script will be cheaper and more predictable, and it will give the same answer every time.
A good test: could you write the whole job as “if this field says X, do Y”, with no step that needs to understand a sentence? Then write it that way.
Even inside Wetel, our own docs push exact work out of the model. A workflow’s condition step evaluates an expression directly, with no model involved. Matching a name someone typed to a record’s internal id is done by a lookup helper, not a model, because the docs record a model confusing one field’s digits for another’s id even after repeated prompt fixes. The pattern is: let the model handle the language, and let plain, deterministic steps handle the rules and the numbers. If your job is all rules and numbers, skip the model.
When the work is high-stakes, irreversible and nobody will check it
If a wrong action cannot be undone and you have no person ready to check it first, do not hand it to an AI employee yet. That covers refunds, payments, changes to someone’s record, and anything sent in your name to a new audience.
Wetel has a way to put a person in front of those actions: an approval step you add to a workflow. The workflow pauses, a workspace owner approves or rejects, and if nobody answers in time the workflow follows an “expired” path you defined. But be clear about its limits today:
- It is a step you add. Wetel does not pause risky actions automatically, and approval is not on by default.
- Only workspace owners can decide. Approvers beyond owners are not built.
- Owners are told in the app. Email notice for approvals is not available yet.
So the approval step solves the problem only if a real owner will actually read the requests. If the honest answer is “nobody has time to look”, the safer choice is to keep that action with a person and let the AI employee prepare it. Our post on supervised versus autonomous work has a simple ladder for deciding which actions belong where.
When you need a channel we do not have
If the work arrives somewhere we do not connect to today, an AI employee from us is not the right fit for that channel. Today a Wetel AI employee is reachable through:
- a web embed on your site, or your own app built against the API
- one messaging app with a ready-made connector (see Channels: what’s live today)
Other messaging apps are listed in the API but return an error until they ship. You can bridge a channel yourself using the headless pattern, but that is your engineering work, not ours.
Phone calls are not built. An AI employee cannot receive or place a real phone call today; telephony is on the roadmap as direction, not a date. There is also no ready-made connector for chat inside online marketplaces. If your customers mostly phone you, or mostly message you through a marketplace, start elsewhere.
When you need features we have not built
Two capabilities people often assume are not there yet: memory across conversations and starting on events.
- Memory across conversations. Within one conversation, an AI employee reads the transcript so far, and a workflow re-reads it every turn (how continuity actually works). Remembering a person from one separate conversation to the next is not built. If the job depends on “it should know what this customer told us last month”, plan for that to come from your own system, or wait.
- Event-based triggers. A workflow can start when a message arrives, when your own system calls the API (headless runs), or on a schedule (scheduled work). Starting because something changed in another system (“when a record changes, run this”) is on the roadmap, not built.
If either of these is the heart of the job, say so early. It changes the answer.
When nobody can write the process down
An AI employee will not fix a process nobody can describe. In Wetel, the persona sets who the AI employee is; what it does, step by step, lives in a workflow: a graph of steps someone writes and publishes. An agent with no published workflow does not improvise. It gives a generic fallback reply to everything (core concepts).
That is deliberate. “Handle customer complaints the way Sarah does” is not a process; it is Sarah. Before an AI employee can do the work, someone has to answer plain questions: what are the cases, what does each one need, when do we say no, who decides the exceptions. If your team cannot agree on those answers, the first project is writing them down, and it does not need us. Often that exercise alone shows the job is a form.
When you need certifications or a dedicated database
If your purchase requires a formal security certification or a database used by your company alone, we cannot meet that today.
- Certifications. We hold no independent security certification today. If your procurement process requires one before any trial, we are not the right choice yet.
- A dedicated database. Every workspace’s data is kept separate on every request, but workspaces share one database. A dedicated database per workspace is designed and not currently offered. Our post on data separation explains what is in place.
We would rather lose a deal on these two lines than win it on a misunderstanding.
When it is a good fit
The work tends to fit when most of these are true:
- People ask in their own words, and the answers come from your own documents or your own systems.
- You can write the steps down, including what happens when information is missing or wrong.
- The consequential actions have a named person who will approve them or keep them, and the rest is low-risk and reversible.
- The work arrives where we connect today: your website, your app, or the messaging app we support.
If you are not sure which side of the line your idea falls on, tell us which work you’d hand over first and we will tell you honestly if it is a fit.
Related reference docs
- Core concepts: agent, workflow and session, and why behaviour lives in the workflow
- Workflow overview: the step types, publishing, and how continuity between turns works
- Workflow best practices: keeping exact lookups out of the model
- Approval node: adding a workspace owner’s sign-off, and its current limits
- Channels: which messaging connector is live today
- Headless agents: bridging a channel yourself
- Pricing and plans: plan limits, and what is not offered
- Roadmap: telephony, event triggers and other direction, not dates