Different tools
If the work needs a different set of connected apps, it is a different job. Tools are enabled or disabled per employee, so mixing two toolsets into one employee widens its reach beyond what any single job requires.
How Many AI Employees Do I Actually Need to Hire?
Question — — by Mahmoud Zalt
One employee per genuinely separate job, not one per busy week. How to tell a distinct job from a bigger version of the same one.
The honest answer, and why nobody can give you a number
Start with one. Add a second only when you can name a job that the first one is not doing and should not be doing. That is the whole rule, and everything below is just how to apply it without fooling yourself.
You will find articles that answer this question with a number, usually three to five, usually with a chart. There is no published dataset behind any of them. Nobody has run a study of how many automated workers a company of your size and shape needs, because the unit is not standardised and the workloads are not comparable. Any number you are given is a guess dressed up as research.
So this article does something less satisfying and more useful. Instead of a number, it gives you a test you can run against your own week, and a set of signals that tell you when you have crossed from one job into two.
The instinct most people arrive with is that headcount should track workload. That is how human teams grow, and it is the wrong model here. An AI employee is not a fixed number of hours, so more work does not automatically mean another hire.
The difference between more work and a different job
More work means the same job happening more often: forty support emails instead of ten, three listings instead of one, a weekly report that becomes daily. That is answered by running the same employee more frequently, not by hiring a second one.
A different job means the definition of a good outcome changes. Answering a customer question well and writing a marketing post well are not the same skill, they are not judged the same way, and they do not fail the same way. When the standard for done changes, you have crossed into a second job.
Benefits
Different data
Customer conversations and financial records are different bodies of context. An employee keeps memory across runs, and that memory is far more useful when it is about one subject.
Different definition of done
If you would review the output against a different standard, you are supervising two jobs. Split them and each one gets a clean pass or fail.
Different approval risk
Work that only reads and reports can run unattended. Work that changes something a customer sees deserves an approval gate. Keeping those in one employee drags the safe work into the slow lane.
Different rhythm
A daily inbox sweep and a monthly reconciliation want different schedules. One employee with two rhythms ends up serving neither well.
Different owner
If two different people on your team would review the output, that is two jobs, because it is two people holding two standards.
Score your candidate work against those six. Zero or one match means you are describing more of an existing job. Three or more means you have found a genuinely separate one, and giving it its own employee will make both employees easier to trust. The signals are practical rather than theoretical because tools, schedules and approval gates are set per employee at Sistava, so a split you make on paper turns into a real difference in what each one can reach and when it runs.
Why splitting by job beats splitting by volume
Two employees doing the same job split the context between them. Each one keeps memory of its own runs, so neither has the full picture, and you end up reconciling two partial histories of one workflow. That is worse than one employee running twice as often with a single continuous thread.
There is a review cost too. Every employee you add is another activity feed to read, another set of tool permissions to keep tight, another set of Tool Rules to keep current. That overhead is worth paying for a genuinely separate job and pure waste for a duplicate one.
The practical version of all this is that your team grows in response to scope, not to pressure. When you feel overloaded, the useful question is not how many more employees to hire. It is which distinct job inside the overload has a countable output and a clear definition of done, because that is the one that can be handed over cleanly. Overload made of ten half-defined jobs does not get better by adding workers to it, in software or anywhere else. If the cost side is part of your decision, read the Sistava pricing page before you assume anything about what a second employee changes.
A sequence that works for most small teams
Growing from one to several without the mess
- Start with the noisiest well-specified job — Not the most valuable one. The one you could write down in five bullet points and hand to a new starter without a meeting. Well-specified beats important for a first hire.
- Run it for a full month before adding anything — You need real output to review, real edge cases, and a real sense of what the employee gets wrong. A month of evidence is worth more than a month of planning.
- Tighten the first one before you widen the team — Adjust its tools, write Tool Rules for the constraints you keep repeating, and put approval gates on the actions you would not want happening unwatched. A tuned first employee sets the pattern for every one after it.
- Add the second only against the six signals — Run the new work through the list above. If it is really the first job getting busier, increase the schedule instead and save yourself a review surface.
- Keep a human owner for each one — Every employee should have a person who reads its activity feed and owns its output. If you cannot name that person, you are not ready for that employee yet.
- Stop when the next job is mostly judgment — Once the remaining work is prioritising, chasing people, or deciding what should happen next, more employees will not help. That is a different kind of work.
Teams that follow that sequence usually settle somewhere small and stay there for a long time, because the number of genuinely separate, well-specified jobs in a small business is genuinely small. Growth shows up as each employee doing its one job more often and more reliably, which is a much quieter kind of progress than a bigger org chart. It is also the shape hiring is built around at Sistava: one role you brief properly, then a second when a genuinely different job appears, rather than a roster you assemble on the first afternoon.
The jobs that should not go on the list at all
Some work will keep showing up on your candidate list and should keep getting rejected. The published task list for an assistant is full of it: prioritising a messy inbox, following up with a real person until they respond, re-coordinating travel when a flight is cancelled, preparing for a meeting where the point is reading the room, and writing an SOP for how this particular company actually works.
There is a measured reason those resist automation. In the OSWorld 2.0 benchmark of authentic professional tasks, one of the three named failure patterns is that agents struggle to maintain hidden state across steps, repeating work or acting on a plan that went stale several steps earlier. Holding the thread of a week-long piece of work, and noticing when the premise quietly changed, is exactly the skill that half of assistant work is made of.
Two more categories never belong on the list: anything physical, and anything that needs a legally accountable person to sign it. Those are not gaps that close with a better setup. They are the outline of where the software ends, and knowing that outline is what keeps your team design honest.
If you take one thing from this, take the reframing. The question is not how many AI employees you need. It is how many genuinely separate, well-specified jobs you have, because that count is the answer and it is usually smaller than the feeling of being busy suggests.
FAQ
How many AI employees should a small business start with?
One. Pick the noisiest job you could describe in five bullet points, run it for a full month, and review the real output before adding anything. Starting with several at once means you cannot tell which setup decisions worked, and you inherit several activity feeds to review before you have learned how to review one. Most small teams stay under a handful for a long time.
Do I need more AI employees as my volume grows?
Usually not. Growing volume means the same job happening more often, which is answered by running the same employee more frequently rather than hiring another one. A second employee doing the same job splits context between two memories, so neither holds the full history of the workflow. Add an employee when the job changes, not when it gets bigger.
How do I know if two tasks are really one job?
Check six signals: do they need different tools, different data, a different definition of done, a different approval risk, a different rhythm, or a different human reviewer. Zero or one match means it is one job. Three or more means it is two, and splitting them will make each easier to trust because each gets a clean pass or fail on review.
Is there a recommended ratio of AI employees to people?
No credible one exists. There is no published dataset on the right number of automated workers for a company of a given size, because the unit is not standardised and workloads are not comparable across businesses. Any ratio you are quoted is a guess presented as research. Count your genuinely separate, well-specified jobs instead and let that be your number.
What happens if I hire too many AI employees at once?
You get review overhead without matching output. Every employee adds an activity feed to read, tool permissions to keep tight, and constraints to keep current, and that cost is only worth paying for a genuinely distinct job. You also lose the ability to tell which configuration choice produced which result, which is the main thing a first month is for.
Which jobs should stay with a person?
Prioritising a messy inbox, following up with a real human until they respond, re-coordinating plans when something falls through, preparing for a meeting where reading the room is the point, and documenting how your specific company works. Benchmarks show agents struggle to hold hidden state across a long task, which is exactly what that work requires. Anything physical or needing an accountable signature also stays.
The temptation with any new capability is to scale it before you understand it. Resist that here. One employee running a job you can describe precisely will teach you more in four weeks than five employees running jobs you defined vaguely will teach you in six months.
When you do add the second, add it because you can name the job, name the tools, name the standard for done, and name the person who will read the output. If any of those four is missing, the honest answer to how many you need is still the one you already have.