The Six Roles Inside an AI Engineering Pod and What Each One Owns
What roles are in an AI pod? Six seats, from delivery lead to MLOps, what each one owns, and how the mix shifts across discovery, build and hardening.
The Six Roles Inside an AI Engineering Pod and What Each One Owns
What roles are in an AI pod? Most AI engineering pods cover six: a delivery lead, a technical lead or AI architect, an AI engineer, a data engineer, a product (full-stack) engineer and an MLOps or LLMOps engineer. Each owns a distinct part of the outcome, and the balance between them changes as the work moves from discovery to build to production hardening.
Those are roles, not necessarily six people. On a small scope one person can hold two seats; on a large one a seat can need two people. What matters is that every seat has a named owner. If you want the basic definition of a pod first, start with our explainer on what an AI pod is. This guide assumes you know the model and want to know who does what inside it.
The six roles at a glance
| Role | Owns | Main artifact | What goes wrong when the seat is empty |
|---|---|---|---|
| Delivery lead | Scope, priorities, stakeholder cadence, the "is this still worth building?" call | Problem statement, success criteria, decision log | The pod builds impressive things nobody asked for, and scope drifts week by week |
| Technical lead / AI architect | System design and trade-offs; the eval harness; code quality | Architecture decisions, eval harness, review standards | Every engineer makes local choices that don't add up to one system |
| AI engineer | Model behavior: prompts, retrieval, tool calls, agent control flow | Prompt and tool specs, retrieval pipeline, agent logic | Output quality stalls at "good demo" and nobody can explain why |
| Data engineer | Source data, pipelines, parsing, freshness and permissions | Ingestion pipelines, data contracts, access rules | The system answers from stale or unauthorized data |
| Product engineer | Integration into the real product and workflow; the user-facing experience | Working feature in your app, auth, fallbacks, feedback capture | A capable model that users can't reach, or can't recover from when it's wrong |
| MLOps / LLMOps engineer | Environments, deployment, tracing, monitoring, cost and rollback | CI/CD, dashboards, alerts, runbooks | Launch day works; week six brings a silent quality drop or a cost spike |
What does each role own inside an AI pod?
Delivery lead: owns the outcome and the scope
The delivery lead keeps the pod pointed at the business result. They run the working cadence with your stakeholders, turn a vague goal into written success criteria, maintain the backlog and decide what gets cut when time runs short. Crucially, they also own the uncomfortable question in every AI project: is this use case still worth pursuing, given what the last round of evals showed?
This role is often part-time on a single pod. It is not optional. A pod without a delivery lead tends to optimize what is measurable (latency, benchmark scores) rather than what the business needs.
Technical lead or AI architect: owns the shape of the system
The technical lead makes the design decisions that are expensive to reverse: hosted API or self-hosted model, retrieval or fine-tuning, synchronous or batch, how the system connects to existing platforms and where data may live. They set review standards and act as the pod's senior engineer on the hardest problems.
In most pods the technical lead also owns the evaluation harness, the code that runs test cases and scores outputs. That ownership matters more than it sounds, because every later decision is only as good as the measurement behind it. Whether you need a dedicated architect or a senior engineer can cover it is a separate question; see fractional AI CTO vs AI solution architect.
AI engineer: owns model behavior
The AI engineer makes the model do the job: prompt and context design, retrieval logic, structured outputs, tool definitions and, on agent projects, the control loop that decides what the model can call and when it stops. They run experiments against the eval set and explain why scores moved.
"AI engineer" is deliberately broad here. Depending on the project, this seat is filled by someone who leans toward LLM and agent work or toward retrieval and search. Which specialist you need is covered in our comparison of LLM, RAG and MLOps engineers, so we won't repeat it.
Data engineer: owns what the system is allowed to know
In an AI pod, data is part of the product, not an input handed over by another team. The data engineer finds and connects source systems, parses messy documents, sets up refresh schedules and, most importantly, carries your access rules through to what the model can retrieve. They also help assemble labeled examples for the eval set.
It is tempting to treat this seat as optional because the work looks like plumbing, but it is also where security exposure concentrates. OWASP's Top 10 for LLM Applications (2025) lists sensitive information disclosure (LLM02) and vector and embedding weaknesses (LLM08) as separate risks, and both land largely in this seat.
Product engineer: owns the path from model to user
The product engineer, usually full-stack, puts the AI inside the product people already use. That means the API or UI, authentication, error states, streaming, human-review screens, and the fallback when the model is unsure or wrong. They also build feedback capture (thumbs up, corrections, escalations), which becomes the raw material for the next round of evals.
Pods without this seat tend to ship a separate demo app that never makes it into anyone's daily workflow.
MLOps or LLMOps engineer: owns the system once it's running
The MLOps (or, for language-model systems, LLMOps) engineer owns environments, deployment pipelines, prompt and model versioning, tracing, dashboards, alerts, cost controls and rollback. On API-based projects much of this is lighter than classic MLOps, but it doesn't disappear: someone must notice when a model provider changes behavior, when token spend doubles, or when latency creeps up.
OWASP's 2025 list includes "unbounded consumption" (LLM10), a reminder that runaway cost and resource use count as operational risks, not just finance problems.
Who owns evaluation in an AI pod?
Evaluation is the one responsibility that doesn't belong to a single seat, and pods that assign it to "QA" alone usually regret it.
A workable split:
- Technical lead owns the harness and the rules for what counts as a regression.
- AI engineer runs evals on every meaningful change and investigates failures.
- Data engineer keeps test data representative as sources change.
- Your domain experts write and review the cases that define "good."
That last point has support from practice. In its January 2026 guide to agent evals, Anthropic reports that what worked best internally was dedicated teams owning core eval infrastructure "while domain experts and product teams contribute most eval tasks and run the evaluations themselves," because "the people closest to product requirements and users are best positioned to define success." The same guide says 20 to 50 simple tasks drawn from real failures is a good start.
The NIST AI Risk Management Framework makes a related point about independence: it describes test, evaluation, verification and validation (TEVV) as work performed throughout the AI lifecycle, and notes that, ideally, the actors carrying out verification and validation "are distinct from those who perform test and evaluation actions." In pod terms: the pod tests its own work continuously, but someone on your side should validate it before launch.
How does the role mix change by project phase?
A pod's composition isn't static. The same six seats carry very different loads in each phase, which is why a well-run pod adjusts effort rather than keeping everyone at full tilt from day one.
| Role | Discovery | Build | Hardening |
|---|---|---|---|
| Delivery lead | Heavy: success criteria, stakeholder interviews, scope | Medium: priorities, demos, cut decisions | Medium: launch plan, handover sign-off |
| Technical lead / architect | Heavy: design options, feasibility spikes, eval harness | Medium: reviews, hard problems | Medium: security review, architecture handover |
| AI engineer | Medium: baseline prototype against first eval set | Heavy: iterate on prompts, retrieval, tools | Medium: guardrails, regression fixes |
| Data engineer | Medium: data audit, access requests | Heavy: pipelines, parsing, permissions | Light to medium: freshness checks, access audits |
| Product engineer | Light: integration points, user journey | Heavy: feature in the product, feedback capture | Medium: fallbacks, error states, UX polish |
| MLOps / LLMOps | Light: environments and access | Medium: CI, tracing, versioning | Heavy: monitoring, alerts, cost limits, rollback, runbooks |
Discovery: the leads and the data audit
Discovery is about whether the use case is real and measurable. The delivery lead and technical lead carry most of the weight, but the data engineer's audit is often where the biggest surprises come from: documents that turn out to be scanned images, permissions nobody has mapped, or data that can't leave a region.
Martin Zinkevich's Rules of Machine Learning for Google are a useful discovery-phase check. Rule #1 is "Don't be afraid to launch a product without machine learning," and Rule #2 is "First, design and implement metrics." A good discovery phase ends with a metric, a baseline and an honest view of whether simpler approaches would do.
Build: the makers take over
During build, the AI engineer, data engineer and product engineer do most of the work, in short cycles of change, evaluate, ship to a small group. The technical lead shifts from designing to reviewing. MLOps work starts here rather than at the end: tracing and prompt versioning are far cheaper to add while the system is small.
Hardening: operations and safety lead
Hardening turns a working system into one your team can support. The MLOps engineer leads, with the AI engineer adding guardrails against issues such as prompt injection (LLM01 in the OWASP list) and excessive agency (LLM06) for agents. The product engineer finishes fallbacks and error handling. The delivery lead and technical lead focus on handover: runbooks, the eval suite, and who on your side will own the system. Moving from pilot to production has its own guide: AI POC to production.
Do six roles mean six people?
No. Roles describe accountability; headcount depends on scope. Some combinations work well on smaller projects:
- Technical lead + AI engineer, when there is one well-scoped feature and a senior engineer can design and build it.
- Data engineer + MLOps engineer, when a platform-minded engineer handles both pipelines and deployment.
- Delivery lead across pods, part-time on each, when stakeholders and scope are stable.
Two combinations cause trouble. The person who builds the model shouldn't be the only one who judges it, for the independence reason NIST describes. And on larger scopes, the delivery lead shouldn't also be the technical lead, because scope and design pressures pull in opposite directions. For headcount by project type, see how many AI engineers you need for your project.
What seats does the client fill?
A pod can't own an outcome in a vacuum. Four seats should sit on your side:
- Product owner. One person with authority to set priorities. The 2020 Scrum Guide describes the Product Owner as "accountable for maximizing the value of the product" and as "one person, not a committee," and that holds for AI pods too.
- Domain expert. The person who knows what a correct answer looks like. NIST's framework lists domain experts as distinct AI actors who bring knowledge of the sector or application area.
- Data and security approver. Someone who can grant access and sign off on data handling without a multi-week queue.
- Receiving engineer. An internal engineer who works alongside the pod and will own the system afterward.
If any of these is missing, expect delays that no amount of pod skill can fix. How pods fit into a wider AI organization (platform teams, centers of excellence, reporting lines) is a different question, covered in our guide to AI team structure and roles.
How fwdpod approaches this
Fwdpod builds dedicated AI engineering pods for startups and enterprises, covering LLM development, RAG systems, AI agents and product delivery, with engineering delivery from India for buyers in the US, UK, EU and the Gulf. Pod composition is shaped around the outcome and the phase rather than a fixed roster. [FWDPOD TO CONFIRM: that pod composition is adjusted by outcome and phase.] The standard pod size and default role mix are [FWDPOD TO CONFIRM: typical pod headcount, which of the six roles are standard vs added by phase, and whether delivery lead and MLOps capacity are included]. To see how a pod is scoped for your project, visit the AI engineering pods page.
Key takeaways
- Most AI pods cover six roles: delivery lead, technical lead or architect, AI engineer, data engineer, product engineer and MLOps/LLMOps engineer.
- Each seat owns a distinct outcome; the empty-seat symptoms in the table are a quick way to audit any pod.
- Evaluation is shared: the tech lead owns the harness, engineers run it, your domain experts define "good."
- The load shifts by phase: leads and data audit in discovery, makers in build, operations and safety in hardening.
- Roles are not headcount, and four seats (product owner, domain expert, approver, receiving engineer) belong on the client side.
Frequently Asked Questions
1. Does an AI pod need a dedicated QA engineer?
Not usually as a separate seat. Traditional QA still matters for the product surface, but judging AI output quality depends on eval sets and domain knowledge, so it works better as a shared responsibility. A dedicated QA or eval specialist makes sense on high-volume or regulated systems where test coverage is large.
2. Is a data scientist one of the roles in an AI pod?
Sometimes. Pods building on hosted language models rarely need one full time. A data scientist becomes useful when the project trains or fine-tunes its own models, needs statistical analysis of experiments, or involves classic prediction tasks such as forecasting or scoring.
3. Who is accountable if the AI pod misses its goal?
The delivery lead is accountable for the pod's delivery against agreed success criteria, and the technical lead for the quality of the system. The client product owner is accountable for whether the goal itself was the right one. Put this split in writing at kickoff.
4. Can one of our engineers join the pod?
Yes, and it is usually the best way to keep knowledge in-house. An internal engineer embedded in the pod learns the system as it is built and can take ownership after handover. Treat them as a full member of the pod, not an observer.
5. Which role should be added first if a pod is struggling?
Look at the symptoms. Answers from stale or wrong documents point to data engineering. Good eval scores but low adoption point to the product engineer. Quality that drifts after launch points to MLOps. Unclear direction or constant rework points to the delivery lead.
6. Does a pod need a security specialist?
Most pods don't need one full time, but security review should be scheduled, not improvised. A security specialist, from your side or the provider's, should review the design during build and test the system before launch, especially for agents that can take actions.
