How to structure an AI engineering team: chief of staff, PMs, engineering managers and agents

Lots of founders working with AI feel like they have a tooling problem. They keep hunting for a new tool, or get excited about a new model. Tomi's view is that this is a mindset and structure problem. If you are talking to ten agents about ten small things, you are the bottleneck. The fix is an org chart.

The structure in one picture

Work flows top to bottom. Priorities flow from you, to a chief of staff, to the people doing the work. Reports flow back up.

1. You. Define the input and review the output.
2. Chief of staff. One personal agent that knows your priorities and business goals and passes context down.
3. PMs. One per project or client. Each owns a task board and priorities and tells the chief of staff what matters most today.
4. Engineering managers. One next to each PM. They watch the coding agents and assign work.
5. Sub agents. The coding agents that implement, open pull requests and get archived when done.
6. Reviewers and testers. Separate agents that check the work. See AI code review and testing agents.

What each role does

Chief of staff. You talk to this one. It delegates tasks, issues, priorities and sprints. Do not skip it and prompt the workers directly, or you are back to context switching.

PM. Owns the board. Turns your requirements into tasks. It can also coordinate content, growth and sales agents when the project needs it. If you are one founder with one product, start with one PM.

Engineering manager. Directs the coding agents. It is a long-lived agent that starts threads for the work, reads their reports and flags what needs you. Claude Code has its own options too, including agent teams with a lead and a shared task list.

Sub agents. Short-lived and specific. One ticket, one outcome, one pull request.

Rules that make it hold together

• Clear ownership. Each role has defined responsibilities and deliverables, like an actual tech company.
• Check-ins on a timer. PMs and engineering managers wake up on a fixed interval, look at the board and move work.
• Small, verifiable tasks. Devin's docs suggest splitting big projects into isolated pieces and giving clear instructions, what to test and context. That applies to any worker.
• Independent review. The agent that checks is never the agent that built.

How we do it at SupaKid Studios

This is Tomi's own structure. At the top is J.A.R.V.I.S., his personal agent and what he calls his AI co-founder. Under it are PMs: for each business concept he is working on, or each client he is helping, there is a PM for that vertical. Each PM has its own Linear board for tasks and roadmaps and works beside an engineering manager.

The engineering managers hand out the work. Under them, Tomi says, sits an effectively unlimited number of sub agents. They write the code and put up a pull request, then Devin does QA on it using its own computer. Every PM and engineering manager wakes up every 30 minutes. They check the board, send sub agents down with defined tasks, and update Linear so Tomi can see which pull requests are open, which are in review and which have actually rolled out.

Tomi personally talks mostly to J.A.R.V.I.S., not to the engineering managers. The engineering manager merges pull requests after they pass the review pipeline, and then the code ships.

This is also how we work with clients. For SkipHold, a white-label AI communications platform, we plugged their team into AI development and software factories. For 0G, the trust layer for AI, we run engineering with agents. The same structure carries over to game work: Tomi has described a game studio with J.A.R.V.I.S. on top, a dedicated game PM, and coding and design agents with access to Unreal Engine and Blender.

Where you stay in the loop

Review the actual result, especially content, design and creative work. This reduces babysitting. It does not make every digital company automatically hands-off. For the full workflow, see how to stop babysitting your coding agents.

Start small

1. Write down one project goal and ten tickets.
2. Create a PM prompt that owns the board.
3. Create an engineering manager prompt that assigns and merges.
4. Run two sub agents on separate tickets, as in running agents in parallel.
5. Add a reviewer. Check in every 30 minutes for a week, then change what is not working.

What goes wrong

• Too many layers for one project. Start with one PM and one manager.
• Skipping the top. If you talk to everyone, you have no structure.
• Vague handoffs. Each layer needs a clear deliverable.
• No review. Speed without checks produces fast mistakes.

Want this built and run for you?

SupaKid Studios sets up and runs structures like this as a managed AI agent team. Our studio team runs the agents and you approve what goes out. Book a 30-minute call and we will map the roles to your product.