Who owns what on an AI team, agents included

Key takeaways

• An AI engineering team has five seats: a technical lead who owns the system design, AI engineers who build the components, a data engineer, an eval owner, and a product owner who sits on your side. Job-post titles blur them, so work from the seats.
• Small teams double up. One person can hold two seats. Nobody should hold the eval seat for their own component without someone else reading the results.
• Agents are not a seat. A coding agent authors pull requests that a human reviews and merges. An agent you ship is a component with a named owner who gets paged when it's wrong.
• Review capacity is the easiest gap to miss when agents arrive. In the 2025 DORA report, 90% of respondents use AI at work, and the same research links AI adoption to lower delivery stability.
• Hire role by role, add contractors per seat, or bring in a pre-assembled team.

Why this question matters

You have an AI roadmap and no team to run it. The job posts you've seen say "AI engineer," "ML engineer" and "LLM engineer" for what looks like the same person, and the vendor pages sell an AI development team without saying who's in it or who answers for it. Before you open a single req, you need to know which seats you're filling, because an AI engineering team with four builders and nobody owning evals ships fast, and its failures go unnoticed until users find them.

This guide covers who sits where, who leads, and where agents fit. It doesn't cover agent-to-engineer ratios, which live in team composition with agents, or how to interview any one role, which the role guides handle.

The frame: Five seats to fill

Titles in this market are inconsistent and shift every few months. A seat is a job that has to be done on the team whether or not anyone's title says so. There are five on an AI engineering team, and each one has to have a name next to it.

1. System design. Someone decides what the agents do, what the humans do, how the parts connect and how the thing fails safely.
2. Component building. Someone builds retrieval, tool use, orchestration and the integration into your product.
3. Data. Someone owns the pipelines and the quality of what goes into the system.
4. Evaluation. Someone owns the test sets, the regression checks and the call on whether a change is good enough to ship.
5. Product direction. Someone decides what the system is for and what error rate a user will tolerate.

Everything else in this guide runs through those five. If a candidate pool, a vendor quote or a team diagram doesn't tell you who holds each one, you've found the gap.

What roles does an AI engineering team need?

An AI engineering team needs one person accountable for each of the five seats, though not five people. The table below maps each seat to the titles you'll see in postings, what to test in the interview, and what it can safely share a person with. This is the section to take into a hiring plan.

A few notes the table can't carry.

The architect seat can be shared. At a govtech client, A.Team staffed two parallel teams with one shared AI architect, so both teams took their design calls from the same person. A seat that spans two teams works when the architect isn't also the sprint lead for either. The AI architect guide covers what to look for.

ML engineers are a separate hire, and you may not need one. Teams that train or fine-tune their own models need people at the model layer. Teams that build on hosted models mostly need the component builder and the data seat. The AI engineer vs ML engineer guide draws the line, and it's the quickest way to decide whether your "AI/ML development team" is really one team or two.

Don't hire a data scientist to fill the component seat. Google's MLOps guidance says only a small fraction of a real-world ML system is ML code, with the rest being data collection and verification, serving, monitoring and the machinery around the model. It also describes a handoff problem: data scientists build the model and engineers deploy it. A team that staffs only the model-building end has a hole where the production system goes.

How do you structure an AI engineering team, and who leads it?

Structure an AI engineering team as one small team with all five seats inside it, led by the system-design seat, with the product seat sitting beside it on your side of the line. The Scrum Guide's rule of thumb is a team of 10 or fewer, and most AI teams that work are well under that. The four to six person composition is worked through in team composition with agents.

Who leads depends on who you already have. If you have an engineering manager with room, they run the team and the architect leads the design. If you don't, the architect or a senior AI engineer leads from inside the team, in a builder seat, and your product owner supplies direction. That's the same lead-seat question as for any outside team, and the dedicated development team guide lays out the three ways it gets answered. The AI-specific part is that the lead needs to be able to read an eval result and say what it means, which rules out a pure project manager above the team unless you also have the architect.

zoom_in

Where do AI agents sit on the team?

Agents aren't a seat. They're contributors that need an owner, and the owner depends on which kind of agent you mean.

Coding agents the team uses. These sit below the engineers, as authors of changes. GitHub's documentation for its coding agent describes it working in a cloud environment, handing changes back, and leaving teammates to review the pull request. The documentation is explicit that its logs don't replace your own review. The seat that matters here is the reviewer. The 2025 DORA report found that AI adoption tracks with higher delivery throughput and lower delivery stability, which it attributes to more changes exposing weaknesses downstream. More changes arrive faster, and someone has to read them. Teams that add agents without adding review capacity move the bottleneck into production.

Agents the team ships. An agent inside your product is a component, and the question is who owns it. It needs a name: the person who gets paged when it misbehaves, who knows its current failure rate, and who can say what changed last week. In practice that's the component builder for the agent itself and the eval owner for its measured quality. The Google MLOps point about surrounding machinery applies with more force to agents, because an agent adds tools, permissions, orchestration and a longer chain of places to fail.

Three rules. They're our editorial position; no industry standard covers this yet.

1. Every agent has a named human owner. If you can't write the name down, the agent doesn't ship.
2. Agent output goes through the same review gate as human output. No separate lane for work an agent authored.
3. Whoever builds an agent doesn't sign off on its evals alone. Doubling up is fine as long as someone else reads the eval results.

DORA's reading is that AI amplifies the team it lands in, with strong teams improving and struggling ones seeing their problems grow. About 30% of respondents reported little or no trust in AI-generated code. That's a reasonable level of suspicion and a reasonable hiring criterion: you want people who are fast with agents and unembarrassed about reading what they produce. Hiring for agent-enabled teams covers how to test for it.

Should you hire a dedicated AI development team or build the seats yourself?

Hire role by role when you have the recruiting runway and an engineering manager with room. Add contractors per seat when one or two seats are missing. Bring in a pre-assembled AI development team when the roadmap is moving faster than the hiring plan and you want the seats filled together. The structure above holds in all three, and so do the interview questions.

A bought team still has five seats, and the vendor fills them. Vendors do bundle this. BairesDev's dedicated AI teams page, for example, says its teams handle both model work and the production engineering around it. The test is the one from the seat table: for each of the five, ask for a name and the interview you'd run.

A.Team's team engagements come with a senior lead inside the team, in a builder seat, under one MSA with each builder on their own service order, and there's no managing-partner fee on a standard team engagement. The product seat stays with you. For a view of who leads outside teams generally, the dedicated development team guide puts the three models side by side.

What to do next

Write the five seats on a page and put a name or a gap next to each. Where a seat holds two jobs, check that the eval seat isn't grading its own work. Then decide for each gap whether it's a hire, a contractor or a reason to bring in a team, and write the owner's name against every agent you plan to ship.

If most of the seats are gaps and the roadmap can't wait, A.Team's AI development team puts a matched team in your standups within 48 hours of sign-off.