AI Virtual Team: Five Subagents Built My Growth Plan in Under 90 Minutes

I built MathQuizPrep as a free study tool for my daughter’s math competition prep. Once it existed, one question came up naturally: could this app also earn a little money, without being unfair to the audience, since the users are 10-15 years old? I did not want to research marketing, EU law about minors, SEO, and UI design all by myself. So instead of doing that research alone, I defined a small team of AI specialists and asked them to do it for me, with one of them working as a manager for the other four.

Building the team: by prompting, not by writing the files myself

Each “team member” is a Markdown file inside .claude/agents/ — a persona with a name, a short job description with a fixed list of tools it is allowed to use. Each agent also got information about which model it should use — the more complex ones (like the manager) got more capable models. I did not write any of these files by hand. I described the team in plain English, and Claude wrote and improved them over a short conversation: I started with four specialists, then added a fifth agent to act as manager once it was clear that coordinating four independent specialists by hand would not work.

Here is what each of the five was actually asked to own:

• growth-team-manager (Opus) — coordinates the other four, resolves conflicts between what they propose, and has one job nobody else has: it is the final legal-compliance gate. Every idea has to pass a Poland/EU minors’-law check before it reaches me, and it can drop or rewrite anything that fails, even something from its own team’s original mandate.
• marketing-expert (Sonnet) — reach the target audience: define who the app is actually for (students and, just as important, their parents, who make the decisions), propose channels, positioning, and partnerships. Told to read the competition’s own rulebook PDF first, so its persona is grounded in who that audience really is rather than a generic “Gen Alpha” guess.
• monetization-expert (Opus) — enumerate revenue models, including “free app, user is the product” style ideas and gamification for retention, and run a compliance check on anything that touches money, ads, accounts, or data collected from minors. Given Opus because this is the highest-stakes judgment call in the team.
• seo-expert (Sonnet) — keyword research, technical SEO, and content structure, so the site the other three are shaping actually gets found by parents and teachers searching on Google.
• ui-expert (Sonnet) — design interfaces (landing page, paywall, gamification UI) that both marketing and monetization would sign off on, without resorting to dark patterns aimed at a young audience.

Every specialist was also told clearly what it is not allowed to do. For example: their only place to write files is the growth-team/ folder, kept separate from the real product on purpose — proposals only, nothing applied automatically.

How they actually “communicate”

There is no live chat between the agents — this is worth explaining clearly, because it is usually the part people imagine wrong. It works as an asynchronous handoff through files: I ask the manager for a plan; the manager reads each specialist’s own persona file to know what input it needs; it sends each specialist to work in the background with a written brief; each specialist does its research (some of them ran real web searches against Polish edtech and legal sources) and writes its own findings into its own folder under growth-team/; then the manager reads all these files, resolves the places where the specialists disagree, and writes one final plan.md that can override anyone whose idea did not pass the compliance check. What I read afterward is not a conversation — it is more like a paper trail.

This resolving step turned out to matter more than I expected. marketing-expert proposed targeting Kangur Matematyczny, a national competition with about 400,000 participants a year — a large audience. monetization-expert then found that Kangur’s materials are the copyrighted, trademarked property of a private association, so competing there would mean using a rights-holder’s own content against them. seo-expert closed the question by showing that this format has no real search demand outside that one brand name. The manager dropped this whole direction and redirected the plan toward a different exam with a clean legal position instead. Each specialist was right about its own small part of the picture; the manager’s job was to see the problem that only became visible once all three parts were together.

The manager also overrode one of its own team’s standing instructions. ui-expert’s persona file explicitly allowed a child-facing “ask your parent to buy this” message. The compliance gate flagged this as unlawful under EU rules on commercial practices aimed at minors, and banned it completely, rewriting the monetization surfaces so they only appear on pages a parent would read, never a child.

What came out of it

The final growth-team/ folder holds a real, specific plan, not generic startup advice: a recommended revenue model (institutional licences sold to schools, a paid content pack for a different, legally simple exam, and a donation link — explicitly not behavioral ads, which the compliance section rules out under GDPR’s rules on minors’ consent), a phased roadmap with honest revenue expectations (close to zero for the first months), SEO deliverables (sitemap.xml, robots.txt, a keyword-research document), and six working HTML/CSS UI prototypes for the pages that would actually be needed — a landing page, a quiz-result share screen, a parent-facing checkout mock-up. It also produced a short list of what a real lawyer and a real accountant still need to confirm, which is exactly the kind of honesty I want from a plan like this, instead of false confidence.

Time and tokens

Writing the five persona files took about 20 minutes of conversation. Running the whole team — the coordinator plus five specialist runs — took roughly 90 minutes from start to finish, and most of that time the agents were working in the background while I did other things.

In terms of tokens: the nine agent runs together produced around 400,000 tokens of actual output (plans, specs, code, prototypes), on top of roughly 46 million tokens of input across all of them combined. Most of that huge input number is prompt-cache reads of the project’s own files and each agent’s own context, not freshly billed input, since every specialist re-reads README.md, the persona files, and earlier findings on almost every turn. It is a lot of raw token volume for what looks like one afternoon of work, but that is the trade I am making: paying in tokens and background time for research and cross-checking across four fields I am not an expert in, instead of doing it myself.

What this actually was

Nothing in growth-team/ is live, and that is by design. The whole point of this boundary was to explore a genuinely uncertain, cross-domain decision — should I monetize this app, and how, given who the users are — cheaply, before committing to anything real. The team did not tell me what I wanted to hear. It told me that my first idea (selling the printable worksheets) was probably not legally sound, and that the biggest audience I had in mind was closed off completely. That is a more useful result than a polished pitch deck would have been.

Things I plan to improve

Looking back at how the team actually ran, three things were not efficient, and I am planning to rewrite the persona files to fix them — a separate follow-up, once I have run this enough times to be sure the changes actually help.

It ran sequentially when it did not have to. The manager’s current instructions are a fixed chain: marketing, then monetization, then seo, then ui, one after another. But monetization’s legal read does not actually depend on marketing’s personas, and seo and ui do not depend on each other either — only on what came before them. Running them one by one wastes wall-clock time for no real benefit. The plan is to rewrite the manager’s persona so it works out its own dependency plan for the specific ask, groups whatever has no real dependency into the same “wave,” and dispatches a whole wave as parallel agent calls instead of one at a time — re-checking that plan after every wave, in case the results change what should happen next.

Every specialist re-reads the same source files from scratch. Marketing, SEO, and UI are each separately instructed to read README.md at the start of every run, and SEO is also told to read the competition’s rulebook PDF. Four specialists doing that independently is four times the reading and reasoning cost for information the manager has already digested into its own “shared ground truth” summary. The fix would have the manager hand that summary directly to each specialist in the dispatch prompt, with the specialist trusting it instead of re-reading the source files — falling back to reading the real files only if the summary is missing something, or if a user invokes a specialist directly without going through the manager at all.

There is no clean way for the manager to double-check something. Right now the only way to fix a bad or unclear proposal is to rewrite it in place, which is fine for a straightforward compliance fix but not for a case where the manager genuinely needs a specialist to clarify or defend something. I want to add an explicit mechanism for this: the manager collecting everything it is unsure about, batching it into specific, itemized questions, and sending it back to exactly the specialist that can answer it, in parallel with any other clarifications it needs at the same time — instead of guessing, or quietly dropping an idea just because it was not fully clear.

None of this would need a different tool or a different model — it would just mean rewriting the plain-English instructions in the persona files themselves, the same way I built them in the first place. That follow-up experiment is a separate write-up.

Author: Rafał Tarłowski https://www.linkedin.com/in/rafal-tarlowski/