Look at the agentic software testing life cycle. One agent analyzes the requirement document and gives feedback. One writes the test cases. One reviews them. One writes the test scripts. One executes them, and one analyzes the result.
Once you have skills, a shortcut is tempting. Build one agent and give it all of that as skills: requirement analysis, test cases, review, scripts, execution, results. One agent, one launch, one bill.
Your team wants one agent that carries every stage of testing as a skill. What is preventing you from building it?
Technically, nothing stops you. I would not do it myself, because my agents are already confused. My experience with agents is, if you give a specific niche task, it does a better job.
Carrying fifty skills costs fifty lines. Doing six jobs in one session costs six jobs' worth of reading and writing. Every requirement it read, every test case it wrote, every script and every result piles onto the same desk, and the later stages run in the stupid tail. And the agent that reviews the test cases would be reviewing its own work.
Humans worked this out a long time ago. We do not just have lawyers. We have in-house lawyers, divorce lawyers, litigation lawyers. Everybody is super niche, because we do a better job when we focus on one area really well. Agents are the same. An agent given one responsibility, instead of the whole life cycle, tends to outperform an agent given twenty different tasks.
So I separate them by functional area. Each agent does one task, standalone, with clean context, and carries only the skills that task needs.