Do you need another AI employee? The four-part test I use, built on Anthropic's guidance

The Incuv8or AI Framework - step 4 of 6: Add employees only when they pass the test. Before this: build your COO. Next: hand out the work from your task manager.

Every time I found a new job I wanted AI to do, my first thought used to be that I needed another agent. A blog agent. A captions agent. A legals agent. A compliance agent. Each one felt like progress, and each one was one more thing to remember, brief and look after.

Most freelancers won't need a lot of employees. I structure my AI team around one COO with departments underneath it. I have eight, because I run more than one business, but if you're a freelancer starting out you'll probably need fewer. Under each department I decide whether I need another employee or just a new set of skills.

The way I decide is a four-part test. Even Anthropic's own guidance goes against the way most of us have been building agents. It says to start with one, and only add more when you have a reason. My test is built on the reasons they give.

The test

This is the whole thing. Run it every time you're about to create a new AI employee.

DO I NEED ANOTHER AI EMPLOYEE?

1. OWN CONTEXT
   Does it need a big, focused area of knowledge that would crowd
   out everything else?

2. DIFFERENT PERMISSIONS OR TOOLS
   Does it need to connect to or touch something the others
   shouldn't?

3. A DIFFERENT MODEL
   Does it need a cheaper model for simple work, or a stronger one
   for hard work?

4. RUNS IN PARALLEL
   Does it need to work at the same time as the others?

Yes to any one → it can be its own employee.
No to all four → it's a skill, held by an employee you already have.

What Anthropic actually says

I want to be accurate here, because you might hear this called "Anthropic's four-part test" and that isn't quite right. Anthropic gives three reasons, and the other two points come from their own documentation. This is what they say.

In When to use multi-agent systems (and when not to), published in January 2026, Anthropic says to start with one agent. In their words: "A well-designed single agent with appropriate tools can accomplish far more than many developers expect." They also say multi-agent setups "typically use 3-10x more tokens than single-agent approaches" for the same task, and often take longer overall.

They give three reasons it's worth adding agents:

• Context protection - when everything one agent has to hold starts making it worse at the next job.
• Parallelisation - when independent pieces of work can run at the same time.
• Specialisation - when a separate agent picks the right tools more reliably, stays focused, or needs instructions that would clash with another agent's.

Their Claude Code docs on subagents add two more. A separate agent lets you limit which tools it can use, and it lets you control costs by sending work to faster, cheaper models.

So my test is Anthropic's three reasons plus those two points from their docs. Their closing advice is the line I'd stick on the wall: "Start with the simplest approach that works, and add complexity only when evidence supports it."

The four parts, with my own team

1. Does it need its own context?

This is Anthropic's context protection and specialisation. An employee earns its place when the knowledge it needs would crowd out everything else.

My Blog Manager only thinks about my blog. It reads my writing spec, my published posts and my briefs, and none of that would help my COO sort a client task. In products, each product gets its own employee, because each one has its own world of knowledge.

2. Does it need different permissions or tools?

This comes from the Claude Code docs on limiting what an agent can use, and from Anthropic's point that an agent with too many tools starts picking the wrong one.

My ManyChat Manager works in my logged-in ManyChat account. My Inbox Assistant works in my mailboxes. Neither of those is something I want every employee to be able to touch.

3. Does it need a different model?

This comes from the Claude Code docs on controlling costs with faster, cheaper models.

My COO runs on Opus. My Ops Manager runs on Sonnet, which is faster and lighter, so the gritty admin doesn't use up Opus.

4. Does it need to run at the same time as the others?

This is Anthropic's parallelisation.

My Meeting Notes can file a client call while my Blog Manager is writing a post. If they were one employee, one would have to wait for the other.

What doesn't count

Needing a different process isn't a reason on its own. Different processes are skills. My Scriptwriter writes talking heads, B-roll captions and carousels, and each of those is a skill in its index, not a separate employee.

Anthropic also says to split by context, not by type of work, and not to split one piece of work into stages with a different agent for each stage. A researcher, a writer and a reviewer working on the same blog post don't need to be three employees.

My website legals check, my compliance check and my security audit used to be three employees. None of them passes the test on its own, so now they're skills.

What you need before you start

• The Claude desktop app on a paid plan, with the Claude Code tab.
• Your AI org chart saved in your AI brain. If you haven't made one, the free AI Org Mapper makes it with you: How to map your AI org chart before you build any AI employees.
• A COO, or one main AI employee, to hold the skills that don't pass. If you haven't built one, start with The First AI Employee I'd Build as a Non-Techie Founder: An AI COO.

You don't need to code.

Step 1 - Run the test on the job you're thinking about

Open the Claude desktop app, click the Claude Code tab and start a new chat. Click the + at the bottom of the chat and choose your AI brain folder. Then paste this.

Read my AI org chart & the agent files for my COO & my employees.

I'm thinking about creating a new AI employee for [THE JOB]. Run it
through my four-part test, one at a time:
1. Does it need its own context?
2. Does it need different permissions or tools?
3. Does it need a different model?
4. Does it need to run at the same time as the others?

Answer each with yes or no & one line on why, using what's in my AI
brain. Then tell me: its own employee, or a skill for an employee I
already have? Don't create anything yet.

What you'll see: four answers, each with a reason, and a recommendation. If every answer is no, it names the employee that should hold the job as a skill.

Step 2 - If it's a skill, add it to an employee you already have

Most of the time, this is where you'll land. In the same chat, paste this.

Add [THE JOB] as a skill for [EMPLOYEE NAME]. Interview me about how I
actually do it, one question at a time, like you're writing an SOP for a
new hire. Save it in my skill library & add it to [EMPLOYEE NAME]'s
skills index with what it does, when to use it & what it's not for.
Show me before you save.

What you'll see: a new skill in your library and one new line in that employee's index. Test it with a real job before you rely on it.

Step 3 - If it passes, have your COO draft the employee

If the job said yes to at least one part, your COO drafts the new employee with you. Start a new chat, attach your AI brain folder and paste this.

You're my COO. [THE JOB] passed the four-part test because [WHICH PART].

Draft the new employee: create its folder in the right department &
write its agent file with who it is, its job, which model it runs on,
what it can connect to & touch, & the index of skills it uses. Put the
reason it passed the test at the top. Show me before you save, & don't
give it any work until I've tested it.

What you'll see: a draft agent file with the reason it exists written at the top. Test it with a real job, and approve it when it does the job the way you would.

Step 4 - Run the test on the team you already have

If you've already built a lot of agents, run the test backwards. Start a new chat, attach your AI brain folder and paste this.

Read every agent file in my AI brain. Run each of my AI employees
through my four-part test: own context, different permissions or tools,
a different model, or running at the same time as the others.

Give me a table: employee, which parts it passes, & keep or turn into a
skill. For each one to turn into a skill, tell me which employee should
hold it. Don't change anything.

What you'll see: a table of your team with a keep or merge recommendation for each one. Merge them one at a time, and test after each.

The catch, and the fix

The catch is that "its own context" is easy to say yes to. Almost any job can sound like it needs its own knowledge if you want it to, and that's how you end up back at twenty agents.

The fix is to ask what that employee would need to know that your existing employee doesn't, and whether holding it would actually make the existing one worse at its job. If the answer is a single process, it's a skill. If it's a whole area of your business, like a product with its own customers, content and history, it's context. When you're not sure, make it a skill first. It's much easier to turn a skill into an employee later than to untangle an employee you didn't need.

What this looks like as a business

Every business owner you support has been told they need an agent for everything. Mapping their jobs, running this test and cutting their setup down to a COO and a few employees is the part they can't do for themselves. You're paid for knowing what to build and in what order.

Start with one

Next time you're on a mission to create a different agent, think about your structure first, because the foundation is the most important thing. Run the Step 1 prompt on the job before you build anything.

If you haven't mapped your org chart yet, that's the foundation for all of this: start here.