Build an AI Team That Works Together For You

In my last article, I shared how to build one custom AI that writes your tasks for you. You set up the five-field brief once, you paste your messy notes in, and a clean task comes back out.

That works. It has been working every day. But it only works up to a point, and that point arrives faster than most people expect.

The moment you stop working in one domain, one assistant starts to struggle.

Where One Assistant Hits Its Ceiling

Most agencies are not doing one thing. In a single week, there is front end, back end, SEO, content writing, and ongoing maintenance. Every one of those has its own vocabulary, its own workflow, and its own idea of what "done" looks like.

The natural response is to keep adding to the one task creator. More context, more rules, more exceptions. And the output gets worse instead of better.

Here is what actually goes wrong:

• Customization stops being efficient. Every new domain means rewriting instructions that already exist, then checking you have not broken the ones that were working.
• Integrity gets hard to hold. A rule written for content work starts bleeding into back-end tasks. You fix one thing and quietly break another.
• It pulls in things nobody asked for. A simple front-end request comes back with SEO checks and reporting steps attached, because the assistant has all of that loaded and cannot tell what is relevant.

That third one is not just a personal complaint. Anthropic's own guidance on building skills says the same thing. Overloaded instruction files with heavy branching logic are harder to maintain and more likely to confuse the model, and a vague scope causes a skill to fire in situations where it does not belong. Their recommendation is to keep the main instruction file under 500 lines, give each skill one job, and move background knowledge into separate reference files.

The lesson is simple. One assistant that knows everything is worse than several that each know one thing.

Build a Team Instead

So stop trying to make one perfect assistant. Split it into a small team, and give each member one job.

• The task creator. The main one. It owns the five-field brief and nothing else. It writes the task.
• The domain assistants. One per area of work. Front end, back end, SEO, content writing.
• The policy assistant. The rules. What you do, what you refuse, what needs review, who gets tagged.
• The team map. Who does what, and who a task should go to.

The task creator does not need to know how SEO works. It needs to know that an SEO assistant exists, and to pull it in when a request smells like search work.

That is the whole idea. Separate what the AI does from what the AI knows.

What Actually Goes Inside Each One

The domain assistant holds the shape of the work itself. For web development, that covers:

• Which types of work this domain includes, such as new builds, customizations, or maintenance
• What each of those actually involves. If you do maintenance, does that mean front end, back end, or both
• The stack you work in
• What a normal job in this domain looks like from start to finish

You do not have to write this like documentation. Open the mic, talk through how that part of the business runs, and let the AI map it into a skill. That is the fastest way to get the first version down.

The policy assistant holds the rules. Things like:

• Which types of tasks need a mandatory review before they can be closed, and which are small enough to go straight to done
• Who reviews what. Front-end work goes to this person, back-end goes to that one
• Anything that falls outside the agreed scope does not get written as a task; it goes back to whoever handles the client
• If this error shows up, tag this person
• Keep activity messages short, no long explanations

The team map is the smallest and the most useful. It is a list of people, what each one owns, and when they need to be looped in.

One Client Request, Three Different Tasks

Here is a real shape of message that lands in the inbox. A client with an ecommerce store asks for three things at once:

1. A sales report for the month
2. Some updates to the storefront
3. Inventory topped up, and a few orders created

That is one message and three completely different jobs. A single assistant flattens this into one bloated task, which is exactly the failure I wrote about last time.

With the team, it splits properly:

• The storefront work goes to the front-end developer. Clean task, no tags needed; it stands on its own.
• The inventory work goes to the inventory person.
• The report goes to the salesperson, and this is where the policy layer earns its keep.

Because the report is not just a report, the rule says the salesperson also has to watch the ratio between stock and daily sales. Selling ten units a day with hundred units left is ten days of cover, so the inventory person gets tagged immediately. Selling five a day with five hundred units sitting there means nobody gets tagged, because there is nothing to act on.

The task creator does not know any of that on its own. It knows to check the policy assistant, and the rule comes from there.

That is the difference between a task that is structurally correct and a task that is actually useful.

Why Claude Skills Suits This Best

Of the three big tools, Claude Skills is currently the only one where the team model works without you building the wiring yourself.

• Claude Skills stack. Claude reads only the short name and description of each skill first, works out which ones the request needs, then loads the full contents of just those. You do not summon them. It picks. The same skill also works across the Claude apps, Claude Code, and the API without changes.
• Custom GPTs can be pulled into a chat by typing @, so this is closer than people think. But you are the one summoning each one, and only one at a time. A GPT cannot decide it needs another GPT. The instructions field also caps at 8,000 characters, which is the exact wall you hit when you try to cram several domains into one.
• Gemini Gems have no version of this. You open one Gem from the sidebar, and that is the conversation you are in. Knowledge files are capped at ten per Gem, so the workaround has a ceiling too.

You can absolutely build something like this on GPTs or Gems using knowledge files and a bit of glue. It takes development time, and it takes maintenance. That time is usually better spent on client work.

One more thing makes Claude easier here. You do not need to write these skills by hand. Open a chat, describe the workflow out loud, and it builds the skill file for you. Editing one later is the same process.

How Many Is Too Many

There is no hard limit, so the honest answer is that the right number is the number you can actually maintain.

A rough rule:

• One skill per domain you genuinely work in. Three domains, three skills.
• One policy skill.
• One team map, which can sit inside the policy skill if the team is small.
• One task creator.

If you are adding a skill for something you touch twice a year, you are building maintenance work, not leverage.

I am still early with this setup and have not hit a hard failure yet. No conflicting skills, no wrong one loading. If you are running something similar and you have run into that, I would like to hear it, because that is the kind of thing that only shows up at scale.

The full versions of these skills, the actual instruction text inside each layer, and how they hand off to each other are what is going into my first book. This article is the map.

Next time, I will get into where all of this lands, which is the task management system itself, and how the setup runs inside ClickUp.