How I Structure Cross-Functional Teams for AI Project Delivery

Every AI project I've watched fail didn't fail because the model was bad. It failed because the team around the model was shaped for a different kind of work. Someone owned "build the feature," nobody owned "decide when the feature is wrong," and by the time that gap surfaced, it was in front of a customer instead of in a review meeting. After leading enough of these projects to production, I've settled on a team structure that looks different from a standard product engineering squad — and the difference is the whole point.

Why the Standard Team Shape Doesn't Map

A normal feature team works because the definition of "done" is mostly binary. The checkout flow either processes the payment or it doesn't. You write tests, you catch regressions, you ship. AI features don't behave like that. A model that's 94% accurate isn't "almost done" — it's a system that will confidently produce a wrong answer for one out of every seventeen requests, forever, unless something changes that. The team has to be built around that reality from day one, not discover it in a postmortem.

The pattern I see most often: a product manager writes a spec that describes the happy path, a couple of engineers wire up a model or an API, it works beautifully in the demo, and then it ships. Three weeks later, support tickets start piling up with edge cases nobody tested because nobody was assigned to look for them. The team wasn't badly staffed — it was staffed for the wrong problem. Demos are a solved problem. Production trust is the actual project.

The Roles That Actually Need to Exist

I don't mean four new hires. On most of my projects, two or three people cover these roles between them. But if nobody is explicitly responsible for each of the following, the responsibility doesn't disappear — it just becomes implicit, and implicit ownership is how quality problems slip through.

1. A product owner who defines tolerable failure, not just success

Most product specs describe what the feature should do when it works. For AI features, I need the product owner to also write down what happens when it's wrong — because it will be, regularly. Is a wrong answer embarrassing but harmless, like a bad restaurant recommendation? Or is it costly, like a wrong number in a financial summary? Those two cases need completely different amounts of guardrail engineering, and if the product owner doesn't decide this up front, the engineering team ends up guessing, usually by over-building safety for a low-stakes feature or under-building it for a high-stakes one.

2. Someone who owns the model or prompt behavior

This person's job isn't "write the prompt" — it's understanding why the system behaves the way it does across a wide range of inputs, and being the one who changes it deliberately rather than by trial and error. On smaller teams this is often a senior engineer who's spent enough time with the failure log to develop real intuition for the model's blind spots. It's a specific skill, closer to debugging a probabilistic system than writing deterministic code, and it needs to be someone's named responsibility, not a shared task that everyone touches occasionally.

3. A platform engineer responsible for evals, guardrails, and observability

This is the role most teams skip, and it's the one I refuse to skip anymore. Someone has to build and maintain the harness that measures whether changes make the system better or worse, the logging that captures what the system actually did in production (not just what it was supposed to do), and the guardrails that catch the failure modes the product owner flagged as unacceptable. Without this role, every improvement is a guess, and every regression is invisible until a customer reports it.

4. A human-in-the-loop reviewer, at least early on

For the first weeks after any AI feature ships, I want a real person looking at a sample of real outputs every single day. Not a dashboard of aggregate metrics — actual transcripts, actual edge cases. This is usually a rotating responsibility rather than a dedicated hire, but someone has to be assigned to it, or it quietly stops happening the moment the team gets busy with the next thing.

Sequencing the Work

The order matters as much as the roles. My default sequence:

• Prototype with one or two people, not a full team. The goal at this stage is learning what the model can and can't do reliably, not building production infrastructure. Committing a five-person team before you understand the failure surface is how budgets get burned on the wrong architecture.
• Build the evaluation harness before you scale the team. If you can't measure whether a change made the system better, adding more engineers just means more people making changes you can't verify. I've delayed hiring onto AI projects specifically because the eval harness wasn't ready — it felt slow at the time and saved months later.
• Only then bring in the platform and guardrail work at full strength. Once you know what "better" looks like and what failure modes actually show up, the observability and safety work has a real target instead of being built against guesses.

The Rituals That Actually Matter

Most of the standard agile ceremonies still apply, but I add two that I consider non-negotiable for AI work:

Mistakes I've Made and Seen

• Treating an AI feature like a normal sprint-planned deliverable with a fixed scope and a ship date set before anyone had touched real failure data.
• Leaving evaluation criteria undefined and unowned, so "good enough" ended up being decided by whoever argued most confidently in the launch meeting.
• Scaling the engineering team before the eval harness existed, which multiplied the number of unverifiable changes going into the system rather than the amount of real progress.
• Assuming the human-in-the-loop review would "naturally" keep happening once the team got busy. It doesn't, unless it's someone's explicit job for a defined period.