Structuring an AI Team: The Functions That Must Be Owned
4 min read · updated August 3, 2026
“What roles do we need” is the wrong question, because it produces an org chart before anyone knows what work exists. The question that survives every team size is which functions must be owned by somebody, and which of them currently are not.
Eight functions
These are not job titles. At five people one person holds six of them; at a hundred, several have teams. What does not change is that if one of them is unowned, a specific and predictable thing goes wrong.
| Function | Description |
|---|---|
| Product framing | Deciding what the system should do, what a wrong answer costs, and what quality bar is acceptable. Unowned: the team optimises a number nobody asked for, or ships something with no agreed definition of good. |
| Application engineering | Building the thing: prompts, retrieval, tools, schemas, the service around them. Unowned: nothing exists. Rarely the missing one. |
| Evaluation | Owning the frozen sets, the failure definitions, the harness and the regression gate. Unowned: every change is argued rather than measured, and quality drifts invisibly. This is the most commonly unowned function on the list. |
| Data | Where the corpus comes from, how it is kept fresh, how it is labelled, who may see it. Unowned: retrieval quality plateaus and nobody can say why, and the index quietly goes stale. |
| Operations | Latency, availability, incidents, provider failures, rollout and rollback. Unowned: the first provider outage is discovered by a customer. |
| Cost | Unit economics, attribution, budgets and the decision about which lever is worth an engineer's week. Unowned: cost is discovered at the invoice and addressed in a panic. |
| Safety and security | Untrusted content, tool permissions, guardrails, abuse, data handling. Unowned: the trust boundary is wherever the last person happened to draw it. |
| Policy and compliance | What you may do with which data, disclosure, retention, contractual and regulatory constraints. Unowned: a launch is blocked late by a question someone could have asked in week one. |
Two of these — evaluation and cost — are the ones that go unowned most often, and for the same reason: they are nobody’s obvious job, they produce no visible artefact when done well, and they only announce themselves when the damage is already accumulated.
At five people
One engineer holds application, evaluation, operations and cost. A founder or product person holds framing and, informally, policy. Data is held by whoever knows where the content lives. Safety is held by nobody, which is survivable only while the system has no tools and no untrusted input — and stops being survivable the moment it does.
The failure mode at this size is not missing skills; it is that evaluation is deferred because there is always something more urgent. The specific defence is to make the very first version of the feature include a frozen set of twenty examples and a script that scores them. Twenty is not enough to be statistically satisfying and is enormously better than nothing, because it establishes the habit while the cost of establishing it is an afternoon.
The other thing worth doing early is naming the cost owner explicitly, even if it is the same person as everyone else. An owner who has agreed to look at cost per unit of work weekly will catch the change that multiplied it; a diffuse responsibility will not.
At twenty
Now the functions start to separate, and the interesting question becomes structural rather than individual: does the AI capability sit in one team that serves the others, or is it distributed into the product teams?
- The case for a central team is that evaluation infrastructure, cost visibility, provider management and security review are all shared concerns with real economies of scale. Building four evaluation harnesses is waste.
- The case for distribution is that quality decisions are product decisions, and a central team is structurally distant from the thing being judged. Teams that own their own quality bar move faster and care more.
- The shape that usually works is a small central group owning the shared substrate — evaluation tooling, tracing, cost attribution, provider and key management, the security review — with the application engineering distributed into product teams who own their own frozen sets and their own numbers.
Whichever you choose, the failure mode at this size is that quality becomes a shared responsibility, which means nobody’s. Name a person per surface, not per organisation.
Twenty is also the size at which two functions stop being survivable as side jobs. Safety becomes real the moment anything the system reads comes from outside the company or anything it does has an effect — at which point somebody has to own the question of what a piece of retrieved text is allowed to cause. And policy becomes real the moment a second country, a regulated customer or a procurement questionnaire appears, because the answers take weeks to assemble and are always wanted immediately. Both are cheap to own early and expensive to retrofit, which is the usual shape of a function that goes unowned.
At a hundred
At this size the functions have institutional homes and the risk inverts: the danger is no longer that a function is unowned but that owning it becomes a gate. A safety review that takes three weeks is not a safety function; it is a queue, and teams will route around it.
Three things distinguish organisations at this size that still move:
- Self-service defaults. The safe path is the easy path — a shared client with retries, timeouts, logging, redaction and spend caps already configured, so that doing the right thing requires no decision.
- Review proportional to risk. A read-only summarisation feature and an agent that can move money do not need the same process, and pretending they do teaches everyone to disrespect the process.
- Evaluation as infrastructure. Frozen sets, judges, harnesses and dashboards provided centrally, owned by product teams. The central group builds the road; it does not drive.
Finding the unowned function
A diagnostic that takes twenty minutes and is uncomfortable in a useful way. For each of the eight functions, ask the team to name the person. Not the team — the person. Then check the answers against three tests:
- Do two people give different names? Then it is unowned, whatever the org chart says.
- Does the named person know? Ask them. A surprising number of ownership assignments exist only in the mind of the person who made them.
- Can they show you something from the last month? An owner of evaluation should be able to show a number and its trend; an owner of cost should be able to show cost per unit of work. Ownership without an artefact is a job title.
Do this quarterly. Functions do not stay owned — people change teams, the system grows a new surface, and the function that was safely implicit at five people is the one that fails at thirty.