No General-Purpose AI Teams

The Constraint

Organizations adopting AI at scale need models integrated into every product surface, operational workflow, and customer touchpoint. The default response is to create a dedicated "AI team" that serves as a center of expertise.

The Decision

Do not create general-purpose AI teams. Embed AI capability directly into product engineering teams. Build a small platform team that provides tooling, infrastructure, and judgment, but never owns product AI features end-to-end.

The Tradeoff

You lose the perceived efficiency of centralizing AI talent. You cannot point to a single org chart box labeled "AI." You must hire and upskill product engineers to think about prompts, evals, and model behavior alongside databases and APIs.

You gain deployment velocity, product alignment, and ownership clarity. Product teams ship AI features faster because they control the entire stack. They learn what works in production rather than through specification documents.

The Consequence

AI becomes a capability, not a department. Product engineers who were skeptical of AI six months ago are now prototyping with Claude in staging. The platform team focuses on developer experience: making it trivial to add an AI call, run an eval, or compare model outputs.

Features ship weekly instead of quarterly. The "AI roadmap" disappears because AI work is embedded in every product roadmap. There is no handoff friction, no translation layer, and no waiting for the AI team to prioritize your feature request.

The alternative—a centralized AI team—inevitably becomes a bottleneck. Product teams cannot move fast because they depend on another group's backlog. The AI team cannot move fast because they lack product context. Everyone is frustrated.

If you want AI adoption to feel like database adoption—ubiquitous, boring, integrated—embed it in product teams and give them the tools to succeed.