A chatbot answers. An agent acts. It reads a request, plans the steps, calls tools, changes records and reports back. That difference changes who you need on the team.
Interest is high. In McKinsey's 2025 State of AI survey, 62% of organizations said they are at least experimenting with AI agents, but only 23% are scaling them in at least one business function. Job postings that mention agentic AI grew 280% in a year, according to the Stanford AI Index 2026 with Lightcast data.
The gap between experimenting and scaling is where team composition matters most.
Why agents fail
Before choosing roles, it helps to know what goes wrong. Gartner projects that over 40% of agentic AI projects will be canceled by the end of 2027, and names three causes: rising costs, unclear business value and inadequate risk controls.
None of these is a model problem. They are problems of design, permissions, measurement and integration. Each one points to a role.
The core: two required roles
AI Agent Engineer
The AI Agent Engineer designs how the agent thinks and acts. That includes:
- Workflows and, when needed, several agents working together.
- Tool calling and connections to APIs and data, including the Model Context Protocol (MCP).
- Memory, planning and the points where a human approves or corrects.
- Evaluation and tracing, so you can see why the agent did what it did.
An agent that works once in a demo is easy. An agent that behaves the same way across thousands of requests is this role's job.
AI Architect
The AI Architect owns the decisions that cause cancellations when nobody owns them: permissions, risk and cost.
- What can the agent touch, and with whose identity?
- What happens when it is wrong?
- Which model runs each step, and what does a task cost?
- How does it fit with the security and compliance rules you already have?
These choices are hard to change late. They belong at the start.
The recommended roles
Backend Engineer
An agent is only as useful as the actions it can take. Those actions are APIs. Often they do not exist yet, or they were built for people clicking screens, not for software calling them in a loop.
The Backend Engineer exposes the APIs the agent calls, with authentication, rate limits and clear errors. This work is easy to underestimate. Integration is a known pain point: 77% of engineering leaders told Gartner that integrating AI into applications is a major challenge.
ML Engineer
Once the agent runs for real, someone has to watch it. The ML Engineer brings the production discipline:
- Observability across every step and tool call.
- Continuous evaluation, so quality does not drift silently.
- Cost per task, tracked like any other operating metric.
- Versioning and rollback when a change makes things worse.
This is what turns "it worked last week" into a system you can operate.
The optional roles
Some agents need more. Two roles join when the project calls for them.
AI Product Designer, when the agent talks to end users. People need to understand what the agent is doing, trust it at the right level and recover when it fails. That is a design problem.
Data Engineer, when the agent depends on a knowledge base. If documents are scattered or outdated, the agent will act on bad information. Preparing that base for search and retrieval is its own job.
What about the AI Engineer?
The AI Engineer and the AI Agent Engineer share a lot: prompts, retrieval, evaluation. Many agent projects benefit from both. The difference is focus. The AI Engineer makes model outputs good inside a product. The Agent Engineer makes a system that takes actions safely across many steps.
If your "agent" only answers questions from documents, an AI Engineer may be enough. Once it starts changing things in other systems, you are in agent territory.
Putting it together
A typical team for a production agent looks like this:
- Required: AI Agent Engineer, AI Architect.
- Recommended: Backend Engineer, ML Engineer.
- Optional: AI Product Designer, Data Engineer.
That is the composition of the AI Agent Pod. It is a starting point, not a fixed template. A pilot running in one team needs less. An agent touching financial records needs more control, not more people.
Three staffing mistakes
Staffing only prompt work. A strong prompt engineer can make an agent look brilliant in a demo. Without someone owning permissions and APIs, it never touches a real system.
Adding operations at the end. Monitoring and evaluation feel optional until the first incident. By then, nobody can explain why the agent did what it did, and trust is hard to win back.
Treating the agent as a side project. Agents act on core systems. They need the same review, security and ownership as any other software that writes to production.
Start small, on purpose
The safest first agent has a narrow job, a short list of actions and a human approving the risky ones. That scope is not a lack of ambition. It is how the team learns what the agent does with real requests, before it gets more freedom.
Questions to ask before you start
- What will the agent be allowed to do? List the actions, not the intentions.
- Who approves what? Define where a human stays in the loop.
- How will you know it works? Agree on the evaluation before the first prompt.
- What does one task cost? Estimate it early and track it from day one.
- Who operates it after launch? An agent without an owner degrades.
If these questions have clear answers, you are ready to staff the team. If they do not, that is the first thing the team should help you answer.