How I Structured 34 AI Agents for AgenticKit

A pile of agent files is not a team. A team has reporting lines and things each role is forbidden to do. I learned that by writing 34 of them for AgenticKit and watching the wrong one reach for the database.

This is the org design, not the roster. Why 22 engineering agents and 12 marketing agents, how they get routed, why /ship does not fork 34 processes, and what I would not split again.

The takeaway

Specialize by decision type, not by every job title you can name. Route through a planner that does not write production code. Keep marketing out of the TypeScript context window. If two agents would make the same edit, you have one agent too many.

The constraint that forced the design

A solo founder shipping SaaS wears hats that do not fit in one prompt: schema, API, UI, tests, security, CI, then positioning, landing copy, and a launch thread. One "senior full-stack" agent will do all of that in the style of whichever file it read last. That is how you get Stripe trivia in a CSS turn and a punchy tweet in a migration.

I wanted files on disk that a future-me could open and say: this role plans, this role writes SQL, this role is not allowed to approve its own work. The engineering org map and the marketing org map are that document.

Two workforces, on purpose

Engineering (22): tech-lead, backend-architect, api-engineer, postgres-pro, react-specialist, design-engineer, test-automator, code-reviewer, security-auditor, debugger, devops-engineer, cloud-architect, sre-engineer, ai-engineer, ml-engineer, data-engineer, analytics-engineer, integration-engineer, realtime-engineer, mobile-engineer, compliance-engineer, technical-writer.

Marketing (12): growth-strategist, launch-coordinator, positioning-strategist, market-researcher, competitive-analyst, brand-voice, copywriter, seo-specialist, content-marketer, email-marketer, reddit-strategist, social-media-strategist.

The split is not branding. A marketing turn that is allowed to see your Drizzle schema will "helpfully" rewrite a headline and a column name. An engineering turn that is allowed to see brand-voice rules will pad a commit message. Kits install separately (--kit engineering, --kit marketing, --kit both) so the context window matches the hat.

If you only ship code this month, you do not need the twelve. The Kit Picker exists because that question is the first one that matters.

The org chart

Think in desks, not a flat list.

Leadership. tech-lead plans, estimates S/M/L, and delegates. It does not write production code. That sentence is in the playbook on purpose. A planner that also implements will skip the plan.

Backend. backend-architect owns contracts and layers. api-engineer owns routes and Zod. postgres-pro owns schema and indexes. integration-engineer owns third-party APIs and webhooks. Three writers, three failure modes. They should not be one file.

Frontend. react-specialist owns App Router pages. design-engineer owns the design system and the leaf components. If you only have one UI person in a tiny app, that is fine. The split exists so a "make it pretty" turn does not invent a new data-fetch pattern.

Data and AI. ai-engineer, ml-engineer, data-engineer, analytics-engineer, realtime-engineer. Optional. /ship only pulls them in when the feature names the trigger (LLM, ETL, websocket).

Quality. test-automator writes tests. code-reviewer reviews. security-auditor returns PASS or FAIL. debugger is for a stack trace, not a greenfield feature. Writer, reviewer, and security are three desks. Combining them is how the first workflow failed.

Operate. devops-engineer, cloud-architect, sre-engineer, compliance-engineer, technical-writer.

Growth. Positioning before copy. Copy before launch. SEO and community have their own desks so a Product Hunt draft does not sound like a Reddit reply.

Routing rules

The tech-lead playbook is the routing document. A short version:

Invoke tech-lead when the request is a feature without a shape, spans three or more surfaces, or is complexity L.

Do not invoke tech-lead when there is a stack trace (debugger or /fix), the user already named the file and the change, or the work is a complexity S with an obvious path.

Do not send schema work to api-engineer. Do not send a copy pass to react-specialist. Do not let code-reviewer write the fix it just requested. The reviewer asks. A new turn implements.

Optional specialists stay optional:

If the trigger is absent, that playbook is not in the prompt. That is the whole point of 34 files instead of one giant agent.

One session, many roles

Cursor 2.0 can run parallel agents in git worktrees. That is runtime isolation. It is not role design. People conflate the two.

/ship does not spawn 34 processes. It tells one session to adopt each specialist role in order, emit a phase header, read that agent's required skills, and stop on a failed gate. You can see the same chain in the Agent Chain tool.

Why one session? Because the contract has to be in context when the schema is written, and the schema has to be in context when the route is written. Parallel agents on the same slice will invent two invites tables.

Parallel is for independent slices: tests on yesterday's API while you write today's page, in separate worktrees. Do not parallelize a single feature's schema and its API.

What every agent must read

Before acting, the core rule says: read CURSOR.md, read AGENTS.md for the workflow, read the Required skills listed in the agent file, read the Skills to read listed in the command. Then copy the nearest existing file.

That wiring is the product. An agent without required skills is a personality. An agent with required skills is a role.

What I would not do again

• Agents that overlap ("platform engineer" and "devops" that both write Dockerfiles)
• Agents with no command and no invoke rule (they never run, they only decorate the marketing site)
• Agents that write and then approve
• Always-on agents (there is no such thing; there are always-on rules)
• Putting growth and SQL in the same kit "for convenience"

I would rather have 20 agents that each have a verb than 40 that each have a job title.

When 34 is too many

A script, a one-page site, a weekend spike, a language you are learning. Install nothing. Write a 30-line AGENTS.md and a test.

A single-product SaaS with no marketing motion this quarter: engineering kit only.

A founder who will not read diffs: no amount of agents will help. The team assumes a human at the gate.

If you want the files, they live under Cursor Agents. If you want the routing without memorizing names, use /ship for a slice and /launch for a launch. Agents vs commands is the short version. The before and after of rebuilding the workflow around this team is the companion to this piece.