When leadership decides to "do AI," the first instinct is often to open a requisition for machine-learning engineers or data scientists. For a company consuming Claude through Bedrock, Vertex AI, Foundry, or Claude Platform on AWS, that instinct is usually wrong. You are not training models, tuning neural networks, or managing GPU clusters — the platform does all of that. You are building software that calls a very capable API, which means the skills you need are mostly skills you already have, applied with some new judgment.
Roles you probably do not need
ML engineers and researchers. These roles exist to build and train models. Consuming a hosted model requires neither. Hiring them for an API-integration effort tends to produce frustration on both sides: the work does not use their skills, and their instinct to build custom models pulls the project toward complexity it does not need.
A dedicated "AI team" as a permanent org unit. A small enabling group can be useful early (more below), but a standing department that owns all AI work becomes a bottleneck and an excuse — every other team learns to wait rather than build. The goal is AI capability spread through existing product teams, not concentrated in a silo.
"Prompt engineer" as a standalone job title. Writing good prompts matters, but it is a skill your existing engineers and domain experts pick up in weeks, not a career specialty to recruit for. The people who know the workflow write the best prompts for it.
Roles you actually need
A strong product owner. This is the single highest-leverage role. LLM projects fail far more often from fuzzy problem selection than from technical shortfalls. You need someone who can pick a use case with measurable value, define what a good output looks like, decide where a human stays in the loop, and kill the project if the numbers do not appear. That is classic product management pointed at a new kind of feature.
Ordinary software engineers, plus API literacy. Your existing backend and platform engineers are the build team. The new material — the Messages API, tool use, prompt caching, streaming — is learnable from documentation in days; a first working call is genuinely a fifteen-minute exercise. The deeper new skill is designing for a component that is probabilistic rather than deterministic: retries, output validation, and fallbacks. That is engineering judgment, not a new profession.
Domain experts with real hours allocated. The people who do the work today — claims handlers, support leads, paralegals, analysts — define quality, write and review evaluation cases, and catch the failure modes engineers cannot see. Treat their time as a budgeted project resource, not a favor squeezed between their day jobs.
Someone accountable for evaluation. Not necessarily a hire — often the product owner or a senior engineer — but a named person who owns the eval set, runs it before every prompt or model change, and reports quality honestly. Without this role, quality becomes vibes.
Part-time security and cloud-platform involvement. Your existing cloud team handles IAM or service accounts, quotas, network controls, and cost monitoring on whichever platform you chose — familiar work with a new service name attached. Security review is likewise the standard process, applied early rather than at the end.
How to grow the skills you have
Start by having engineers build something small and real — a proof of concept against actual work, not a toy demo — because API skills stick when attached to a live problem. Run internal show-and-tells so lessons travel between teams. Consider a temporary enablement group whose explicit charter is to make product teams self-sufficient and then dissolve: shared gateway, shared eval tooling, prompt-writing guidance, office hours. Its success measure is how many teams no longer need it. And write down what you learn — prompt patterns that work, failure modes to check for — so the second and third projects start ahead of the first.
Where to go next
Staffing is half the adoption story; change management covers getting the wider workforce to actually use what you build, and the one-week proof of concept plan is a good first assignment for the team described here. The quickstart is where your engineers should spend their first hour.